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

From: Mike Ounsworth <[email-masked]>
Date: Thu, 28 Jan 2021 19:27:36 +0000

Proposed charter text:

Post-quantum cryptography (PQC) will require a transition period in some ways similar to previous crypto migrations, but unique in that timelines require deployment of PQC before cryptographers have full confidence in the replacement algorithms. NIST has called for transition mechanisms that "layer" traditional and PQ crypto together, referred to as "hybrid key establishment" and "dual signatures". The LAMPS working group will update documents produced by the PKIX and S/MIME WG to support hybrid key establishment, encryption, and dual signature mechanisms.

---
Mike Ounsworth
Software Security Architect, Entrust

---

From: Sean Turner <[email-masked]>
Date: Thu, 28 Jan 2021 15:04:44 -0500

I think if we are going to do this then I think these are the words I’d use.

Get ready to explain the quoted text to the IESG :)

spt

> On Jan 28, 2021, at 14:27, Mike Ounsworth <Mike.Ounsworth=[email-masked]> wrote:
> 
> Proposed charter text:
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Mike Ounsworth <[email-masked]>
Date: Thu, 28 Jan 2021 20:22:01 +0000

From discussion at the interim meeting, perhaps "... will update documents produced by the PKIX and S/MIME WG.." maybe is not broad enough and maybe needs to allow for new documents? The idea here is to make sure existing standards have sufficient hybrid and dual support, not to go inventing totally new protocols. 

... that said, I wonder whether draft-ounsworth-pq-composite-sigs actually falls inside this wording or not; as a standalone definition of a new signature algorithm, it's not technically updating any existing documents...

---
Mike Ounsworth

-----Original Message-----
From: Sean Turner <[email-masked]> 
Sent: January 28, 2021 2:05 PM
To: Mike Ounsworth <[email-masked]>
Cc: LAMPS <[email-masked]>
Subject: [EXTERNAL] Re: [lamps] Proposed re-charter text for hybrid and dual crypto modes

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

spt

> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!Jm1C-jM0OWxeWC2pfaUPxUrtNIduGAR2D2ki58AztVqNiHwWMrn1kfswxRZ8GadHIQEL$

---

From: Russ Housley <[email-masked]>
Date: Sat, 30 Jan 2021 16:13:56 -0500

Building on the text proposed by Mike, I want to address a point raised by Max and a point raised by Sean.

First, Max observed that PQC algorithms will be used in both the one certificate and the two certificate models.  So, I propose charter text that has a place for each of them.

Second, Sean observed that the charter will need some background text to explain what we are doing to the IESG.  So, I propose some charter text for additional context.

Third, the charter is structured as a list of deliverables for the LAMPS WG.  So, I structured the proposed charter text as a new numbered item "X".

~~~

X. Recent progress in the development of quantum computers pose a threat
to widely deployed public key algorithms.  As a result, there is a need
to prepare for a day when cryptosystems such as RSA, Diffie-Hellman,
ECDSA, ECDH, and EdDSA cannot be depended upon.  As a result, there are
efforts to develop standards for post-quantum cryptosystem (PQC)
algorithms that that will be secure if large-scale quantum computers
are ever developed.

a. Specify the use of PQC public key algorithms with the PKIX
certificates and the Cryptographic Message Syntax (CMS).

b. Develop specifications to facilitate a lengthy transition from
today's public key algorithms to PQC public key algorithms.  Unlike
previous algorithm transitions, time will be needed before there is
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.  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.

~~~

Review and comments welcome.

Russ

> On Jan 28, 2021, at 2:27 PM, Mike Ounsworth <Mike.Ounsworth=[email-masked]> wrote:
> 
> Proposed charter text:
>

---

From: Michael Richardson <[email-masked]>
Date: Sat, 30 Jan 2021 17:38:53 -0500

Russ Housley <[email-masked]> wrote:
    > signatures".

    > NIST defines "hybrid key establishment" as any key
    > 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

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 <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Michael Jenkins <[email-masked]>
Date: Sun, 31 Jan 2021 11:20:00 -0500

Not that I object to any of the work being proposed, but we seem to have
put paid to the notion of "limited". This is looking like PKIXme.

On Sat, Jan 30, 2021 at 4:14 PM Russ Housley <[email-masked]> wrote:

> First, Max observed that PQC algorithms will be used in both the one
> certificate and the two certificate models.  So, I propose charter text
> that has a place for each of them.
>
> Second, Sean observed that the charter will need some background text to
> explain what we are doing to the IESG.  So, I propose some charter text for
> additional context.
>
> Third, the charter is structured as a list of deliverables for the LAMPS
> WG.  So, I structured the proposed charter text as a new numbered item "X".
>
> ~~~
>
> > Post-quantum cryptography (PQC) will require a transition period in some
> ways similar to previous crypto migrations, but unique in that timelines
> require deployment of PQC before cryptographers have full confidence in the
> replacement algorithms. NIST has called for transition mechanisms that
> "layer" traditional and PQ crypto together, referred to as "hybrid key
> establishment" and "dual signatures". The LAMPS working group will update
> documents produced by the PKIX and S/MIME WG to support hybrid key
> establishment, encryption, and dual signature mechanisms.
> >
> > ---
> > Mike Ounsworth

-- 
Mike Jenkins
[email-masked] <[email-masked]> - if you want me to read it only
at my desk
[email-masked] - to read everywhere
443-634-3951

---

From: Michael Richardson <[email-masked]>
Date: Sun, 31 Jan 2021 16:36:19 -0500

Michael Jenkins <[email-masked]> wrote:
    > Not that I object to any of the work being proposed, but we seem to
    > have put paid to the notion of "limited". This is looking like PKIXme.

I hear what you are saying.
I think that things would be best if we assumed we have to open 5280.
This work is much needed PKIX-maintenance.
Spinning another WG won't change the effort involved, though.