Key generation strategies forbids reuse of ECC keys

[teythoon]

8.2. Key generation strategies

It is REQUIRED to generate fresh secrets when generating PQ(/T) keys. Reusing key material from existing ECC keys in PQ(/T) keys does not provide backwards compatibility, and the fingerprint will differ.

Forbidding this seems strong and doesn't seem to be motivated in the section. And, I can actually imagine a use case for reusing existing ECC key material: Imagine I have a smart card that holds my ECC keys for my existing v6 cert, and I want to create a PQ cert in addition to that. Reusing the ECC key material seems convenient and adds security over having the ECC keys being softkeys, as in the mid term there won't be PQ-capable smart cards. If I'm not allowed to reuse the ECC key, I'd have to use a second smart card, which is more expensive and unwieldy, hindering adoption of composite algorithms.

[falko-strenzke]

The background here is that as soon as we allow the reuse of existing standalone keys, that an attacker could strip out the PQC signature from a composite signed document. Our concern here is that these notions are taken rather seriously with respect to CMS signatures. Just now at IETF 118 this aspect was discussed for the LAMPS composite signatures draft. In order to reach the strongest non-separability notion given in the signature specturms draft, forbidding key reuse is the only realistic way. I think OpenPGP already achieves the weaker notion, since the signature algorithm ID is part of the hashed data (I couldn't find that in the crypto-refresh, wold be nice if someone could confirm or refute this). Thus, when stripping one of the component signatures of a component scheme, the hash value that is signed wouldn't fit to the message any more.

In any case your concern is valid in my opinion. From my point of view this decision would be something for the WG to vote on after they understand the two approaches and advantages and disadvantages.

[teythoon]

See 5.2.4. Computing Signatures: https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#section-5.2.4-9.2.2.3.1

Once the data body is hashed, then a trailer is hashed. This trailer depends on the version of the signature.

[...]

A v4 or v6 signature hashes the packet body starting from its first field, the version number, through the end of the hashed subpacket data and a final extra trailer. Thus, the hashed fields are:

• An octet indicating the signature version (0x04 for v4, 0x06 for v6),
• The signature type,
• The public-key algorithm,
• The hash algorithm, [...]

Another concern with this MUST NOT is that it doesn't seem actionable. How is an implementation that is asked to generate a PQ/T key to know whether or not the key has been used before?

[falko-strenzke]

Thanks for confirming the hashing of the signature algorithm.

Another concern with this MUST NOT is that it doesn't seem actionable. How is an implementation that is asked to generate a PQ/T key to know whether or not the key has been used before?

Well, if the implementation generates new component keys whenever a composite key is generated, then the requirement is clearly fulfilled. The MUST NOT makes it clear for the implementor that they shouldn't give the user the option to reuse existing keys for incoroporation into a composite key. There might be some corner cases where there are keys used on external crypto devices and the implementation cannot trigger the key generation on that device. But I am not sure if that is practically relevant.

[teythoon]

Seems to me that it should rather be a SHOULD NOT as you have already identified an exception to the rule.

[falko-strenzke]

@TJ-91 @fluppe2 @wussler Considering the points above it seems reasonable to weaken or remove the prohibition of reuse of the EC keys. The hashing of the algorithm ID ensures that stripping a s signature is impossible. Thus I cannot really see any danger in this. And @teythoon points out a convincing use case for key reuse. I there are no further arguments against this step I will make PR for the change.

[wussler]

Another concern with this MUST NOT is that it doesn't seem actionable. How is an implementation that is asked to generate a PQ/T key to know whether or not the key has been used before?

I think this is actionable on the key generation level, and it boils down to "make fresh keys". If an implementation just takes the components and assembles them into an OpenPGP key, then it could argue this check is not in scope.

Generally I would be okay with lowering this to a SHOULD NOT, even though in this thread we had a look only at signatures. For KEM the domain separation is the context when deriving the shared secret.

[falko-strenzke]

Now covered in https://github.com/openpgp-pqc/draft-openpgp-pqc/pull/88

[falko-strenzke]

Merged #88