Re: [lamps] Proposed re-charter text for hybrid and dual crypto modes

[Russ Housley <[e-mail]>]

> On Jan 30, 2021, at 5:38 PM, Michael Richardson <[e-mail]> wrote:
> 
> 
> Russ Housley <[e-mail]> wrote:
>> full confidence in the PQC public key algorithms.  Therefore,
>> transition mechanisms that combine traditional algorithms with PQC
>> algorithms will be needed for "hybrid key establishment" and "dual
>> signatures".
> 
>> NIST defines "hybrid key establishment" as any key
>> establishment scheme that is a combination of two or more components
>> that are themselves cryptographic key-establishment schemes.
> 
> To be clear for me, such a system would get a unique algorithm OID,
> and would count as a single signature outside of the crypto function.

That is my understanding as well.

> 
>> NIST
>> defines "dual signatures" as any signature scheme that consists of two
>> or more signatures on a common message.  The specifications developed
>> will enable PKIX and S/MIME protocols to support hybrid key
>> establishment and dual signature mechanisms.
> 
> Such as system would be visible as having two algorithmOIDs, and this would
> be visible outside of the crypt function.  The length discussion about
> matching the two identities, etc. deals with this side of things.

That is not the proposal in draft-ounsworth-pq-composite-sigs-04.

> 
> My understanding is that we might have situations where we have dual
> signatures, and the second signature might be a hybrid signature.
> 
> RFC5280 only provides for one algorithmIdentifier (signatureAlgorithm) at the
> top-level sequence, which is not contained under the signature.
> We had some document a few years ago that dealt with coordinating this with
> the section 4.1.2.3 Signature which *is* the signature. (I think Russ wrote that)
> 
> I know that some of the proposals (maybe all) put the second algorithm into
> various extensions, and that is really the only way to do the dual-signatures
> in a backwards compatible way.
> 
> I note that RFC5280 is only at Proposed Standard.
> It was suggested it was more mature, but I can't find any evidence of that:
> not in the DT nor on the rfc-editor page.
> 
> I believe that write a few "Updates" (Amends) RFC5280 documents is
> appropriate, but I think that given that this is going to be a long
> transition, that I think the charter should include text that would allow
> RFC5280bis to be produced.  That might not be a near-term priority, but I
> think that it needs to get done for a number of technical and marketing reasons.

The RFC index does shoe RFC 5280 as PROPOSED STANDARD.  It seems like we should figure out the minimum work needed to advance it.  Clearly there are more that two interoperable implementations.

Russ