[openpgp] Proposed update to draft-replacementkey

Hi, all.

It has been brought to my attention that the specification of the digest 
algorithm in the "Target Key Imprint" field of the Replacement Key 
subpacket is problematic.

The draft currently states:

 > When used in a Replacement Key subpacket, an imprint MUST use the 
same digest algorithm as the enclosing signature.

This matching of digest algorithms is intentionally similar to the one 
specified in 1pa3pc[1]. It avoids adding an unnecessary degree of 
freedom, and the security properties are easy to reason over.

Unfortunately, it also makes life much more complex for implementers. If 
the keyholder wants to create a new self-signature, their implementation 
cannot blindly copy across the replacement key subpackets from the older 
self-signature like it can for any other subpacket type, unless a) the 
digest algorithms are the same for both self-sigs or b) all of the 
target keys are locally available to be re-imprinted using the new 
self-sig's digest algorithm. This exposes otherwise unnecessary amounts 
of low level detail to higher-level layers in the application stack, 
with potential UX consequences.

(This issue does not arise in 1pa3pc, because it is reasonable to assume 
that all approved signatures are present in the local copy of the 
certificate when generating a fresh 1pa3pc signature)

I therefore propose that we restrict the imprint digest algorithm to be 
SHA3-256 in all cases, regardless of what the enclosing signature packet 
uses. This has several advantages:

* Replacement Key subpackets are context-independent
* Target Records are both context-independent AND immutable
* The imprint field is no longer redundant in any scenario
* Imprint and fingerprint algorithms always come from distinct families

The last point in particular significantly improves the security 
properties of the subpacket, because it mitigates against not just known 
weaknesses in older fingerprint algorithms, but also future attacks 
against current fingerprint algorithms.

SHA3-256 is not MTI, however any implementation that supports the PQC 
draft already has a dependency on it. IMO it is therefore reasonable to 
require it here.

No wire format changes are required. I have opened an MR to update the 
algorithm selection rules and security considerations[2].

I believe this is a win-win modification. Any objections?

Thanks,
A

[1] https://datatracker.ietf.org/doc/html/draft-dkg-openpgp-1pa3pc
[2] 
https://gitlab.com/andrewgdotcom/openpgp-replacementkey/-/merge_requests/25

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]