Re: [lamps] Proposed recharter text

[Mike Ounsworth <[e-mail]>]

Hi Roman,

I can fill you in on how (5b) got to be worded the way it is.

Speaking as the author of the (currently only?) dual / hybrid draft at LAMPS and presenter at LAMPS interim, I think the nebulousness of (5b) is because there was consensus that LAMPS should start working on Dual/Hybrid mechanisms, but we're still figuring out the scope of that work. For example: Can we get by with defining a new algorithmID, and therefore avoid doing something that feels like X.509v4? Are we going to need separate mechanisms for public PKI (simple and restrictive) and private PKI (complete flexibility to do complex staged migration of long-lived devices)? Can CMS get by with existing multiple SignerInfo functionality, or does it need something new? Do we need some sort of CRL / OCSP mechanism to signal algorithm deprecation for devices that can't receive firmware patches? (the term "Online Algorithm Status Protocol" was jokingly floated) The latter is probably already outside the scope of 5, so would need another re-charter anyway.

So (5b) is broadly worded on purpose because we want to get moving, but are still feeling out the scope of work. How do you balance the "L" in "LAMPS" against narrowing the scope too soon and missing good solutions or valuable use-cases for this unprecedented migration problem?

On a personal note: I have a small pile of drafts that I hope to get up after 110 on composite keys, signatures (two competing proposals; maybe we need both?), and encryption (yes, I agree that 800-56Cr2 is the way to go). It would be nice if these were in-scope so they can be discussed officially at LAMPS 111.

---
Mike Ounsworth

-----Original Message-----
From: Spasm <[e-mail]> On Behalf Of Roman Danyliw
Sent: March 8, 2021 5:06 PM
To: LAMPS <[e-mail]>
Subject: [EXTERNAL] Re: [lamps] Proposed recharter text

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

______________________________________________________________________
Hi!

I'm not necessarily responding directly this message but wanted to comment on the proposed charter text.

On (1) - (4), no issues with proposed text.  I would just ask that we have milestones, even if the dates are notional.  Perhaps this can be covered at the meeting later this week.

Per (5a), we should definitely use the refined text below which times the effort around the output of the NIST PQC effort.  No milestone required for that.  No issues otherwise.

I would like to chat about the scope of (5b).  Sadly, I missed the conversation at the last interim.  There seem to be two loosely related thrusts -- one around "dual or composite signatures" and another on "hybrid key establishment".  

Per "dual signatures", we chatted about this at IETF 106's SecDispatch too and the result was to take it to LAMPS (https://urldefense.com/v3/__https://datatracker.ietf.org/doc/minutes-106-secdispatch/__;!!FJ-Y8qCqXTj2!P1klq0lPS4leBZqYLrnZLsQxT1WWp5lakxXgsd-WgBKYoytfSawSF-VEU_Byp00Yc3FFTUYMZQ$ ).  No issues with this top level intent.  What would be helpful to sharpen are the bounds a "specification  ... [that] will enable PKIX and S/MIME protocols to support ... a dual signature mechanisms".  Are we restricting ourselves to just format (seems fine)? verification practices (seems fine)? recommended signature combinations (is there a dependence on NIST activities?)? Something else?

Per "hybrid key establishment", this is a slightly different focus which we previously haven't discussed outside of LAMPS.  What would this specification work entail -- again, is it just format work or also explicitly defining or recommending constructs which mix multiple key types?  What would be relationship between this work and an updated 800-56C promised out of the NIST PQC effort?

Regards,
Roman


> -----Original Message-----
> From: Spasm <[e-mail]> On Behalf Of Russ Housley
> Sent: Wednesday, February 17, 2021 8:49 AM
> To: Panos Kampanakis <[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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/sp
> > asm__;!!FJ-Y8qCqXTj2!P1klq0lPS4leBZqYLrnZLsQxT1WWp5lakxXgsd-WgBKYoyt
> > fSawSF-VEU_Byp00Yc3FnDv8GXA$ 
> > _______________________________________________
> > Spasm mailing list
> > [e-mail]
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/sp
> > asm__;!!FJ-Y8qCqXTj2!P1klq0lPS4leBZqYLrnZLsQxT1WWp5lakxXgsd-WgBKYoyt
> > fSawSF-VEU_Byp00Yc3FnDv8GXA$
> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spas
> m__;!!FJ-Y8qCqXTj2!P1klq0lPS4leBZqYLrnZLsQxT1WWp5lakxXgsd-WgBKYoytfSaw
> SF-VEU_Byp00Yc3FnDv8GXA$

_______________________________________________
Spasm mailing list
[e-mail]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!P1klq0lPS4leBZqYLrnZLsQxT1WWp5lakxXgsd-WgBKYoytfSawSF-VEU_Byp00Yc3FnDv8GXA$