Re: [lamps] Proposed recharter text

[Russ Housley <[e-mail]>]

Panos:

I am also interested in PQ KEM support in CMS and the subject public key of certificates once NIST selects some "winner" algorithms.

I am expecting NIST to select some PQ signature algorithms at some point.  The discussion on the NIST mail list ([e-mail]) makes me think that the signature "winner" algorithms may be selected after the KEMs.

I think the proposed language says that our efforts cannot begin until NIST selects the "winner" algorithms.

Russ

> On Feb 18, 2021, at 11:54 AM, Panos Kampanakis (pkampana) <[e-mail]> wrote:
> 
> Sorry to be pedantic Russ. 
> 
> If 5a was trying to introduce KEMs for content encryption in CMS, then I am
> all for that.  My objection was for using KEMs for singing. I am not sure we
> will end up needing to use KEMs for PKIX or CMS signing yet. Especially for
> PKIX, I expect this to be discussed in the TLS WG. What I am trying to avoid
> here is embarking on a KEMTLS journey (which will be long if it happens)
> with the argument being that it is already included in the LAMPS charter. 
> 
> 
> 
> 
> -----Original Message-----
> From: Russ Housley <[e-mail]> 
> Sent: Wednesday, February 17, 2021 8:49 AM
> To: Panos Kampanakis (pkampana) <[e-mail]>
> Cc: LAMPS <[e-mail]>
> Subject: Re: [lamps] Proposed recharter text
> 
> Panos:
> 
> I agree that 5a ought to wait for the NIST completion to complete.  I'll add
> that to the text...
> 
> a. After the NIST Post-Quantum Cryptography (PQC) effort produces one or
> more quantum-resistant public-key cryptographic algorithm standards, the
> LAMPS WG will specify the use of PQC public key algorithms with the PKIX
> certificates and the Cryptographic Message Syntax (CMS).
> 
> Russ
> 
>> On Feb 16, 2021, at 11:01 PM, Panos Kampanakis (pkampana)
> <pkampana=[e-mail]> wrote:
>> 
>> I don't think 5a should be added in the LAMPS charter at this time. 
>> It is too early. And besides, draft-ietf-tls-semistatic-dh does the 
>> same thing with classical (EC)DH keys in the leaf cert and it is 
>> worked in the TLS WG.
>> 
>> 
>> -----Original Message-----
>> From: Spasm <[e-mail]> On Behalf Of Russ Housley
>> Sent: Wednesday, February 10, 2021 3:22 PM
>> To: LAMPS <[e-mail]>
>> Subject: [lamps] Proposed recharter text
>> 
>> I propose the attached recharter text.
>> 
>> Tasks 1-3 are unchanged from the current charter,
>> 
>> Task 4 is a slightly edited version of the text proposed by DKG after 
>> IETF 109.
>> 
>> Task 5 is the text that came out of the discussion that followed the 
>> virtual interim at the end of last month.
>> 
>> Task 6 was raised in the discussion that followed the virtual interim 
>> at the end of last month.  In my view, it is too early to work on 
>> advancement of RFC 8550 and RFC 8551, but putting it in the charter 
>> now will allow us to tackle them when they are well deployed.
>> 
>> Russ
>> 
>> = = = = = = = =
>> 
>> The PKIX and S/MIME Working Groups have been closed for some time. 
>> Some updates have been proposed to the X.509 certificate documents 
>> produced by the PKIX Working Group and the electronic mail security 
>> documents produced by the S/MIME Working Group.
>> 
>> The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working 
>> Group is chartered to make updates where there is a known constituency 
>> interested in real deployment and there is at least one sufficiently 
>> well specified approach to the update so that the working group can 
>> sensibly evaluate whether to adopt a proposal.
>> 
>> The LAMPS WG is now tackling these topics:
>> 
>> 1. Specify the use of short-lived X.509 certificates for which no 
>> revocation information is made available by the Certification Authority.
>> Short-lived certificates have a lifespan that is shorter than the time 
>> needed to detect, report, and distribute revocation information.  As a 
>> result, revoking short-lived certificates is unnecessary and pointless.
>> 
>> 2. Update the specification for the cryptographic protection of email 
>> headers -- both for signatures and encryption -- to improve the 
>> implementation situation with respect to privacy, security, usability 
>> and interoperability in cryptographically-protected electronic mail.
>> Most current implementations of cryptographically-protected electronic 
>> mail protect only the body of the message, which leaves significant 
>> room for attacks against otherwise-protected messages.
>> 
>> 3. The Certificate Management Protocol (CMP) is specified in RFC 4210, 
>> and it offers a vast range of certificate management options.  CMP is 
>> currently being used in many different industrial environments, but it 
>> needs to be tailored to the specific needs of such machine-to-machine 
>> scenarios and communication among PKI management entities.  The LAMPS 
>> WG will develop a "lightweight" profile of CMP to more efficiently 
>> support of these environments and better facilitate interoperable 
>> implementation, while preserving cryptographic algorithm agility.  In 
>> addition, necessary updates and clarifications to CMP will be 
>> specified in a separate document.  This work will be coordinated with the
> LWIG WG.
>> 
>> 4. Provide concrete guidance for implementers of email user agents to 
>> promote interoperability of end-to-end cryptographic protection of 
>> email messages.  This may include guidance about the generation, 
>> interpretation, and handling of protected messages; management of the 
>> relevant certificates; documentation of how to avoid common failure 
>> modes; strategies for deployment in a mixed environment; as well as 
>> test vectors and examples that can be used by implementers and 
>> interoperability testing.  The resulting robust consensus among email 
>> user agent implementers is expected to provide more usable and useful
> cryptographic security for email users.
>> 
>> 5. 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.
>> 
>> 6. Progress RFC 5280, RFC 6960, RFC 8550, and RFC 8551 to Internet 
>> Standard status.
>> 
>> In addition, the LAMPS WG may investigate other updates to documents 
>> produced by the PKIX and S/MIME WG. The LAMPS WG may produce 
>> clarifications where needed, but the LAMPS WG shall not adopt anything 
>> beyond clarifications without rechartering.
>> 
>> _______________________________________________
>> Spasm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spasm
>> _______________________________________________
>> Spasm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spasm
>