Re: [lamps] Proposed recharter text

["Panos Kampanakis (pkampana)" <[e-mail]>]

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