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

[Michael Richardson <[e-mail]>]

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.

    > 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.

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.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide