Re: [lamps] Proposed recharter text

[Mike Ounsworth <[e-mail]>]

Thanks Roman.

Sounds like your preference is to re-charter around specific drafts rather than the catch-all language that 5b currently is? Sounds like I should get all my drafts up as the next step, then come back to the re-chartering question armed with specific drafts? 

I guess this come back to a process question to Russ and Tim about how to figure out which problems and drafts to re-charter for in the short-term?

---
Mike Ounsworth

-----Original Message-----
From: Roman Danyliw <[e-mail]> 
Sent: March 9, 2021 4:28 PM
To: Mike Ounsworth <[e-mail]>; 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 Mike!

> -----Original Message-----
> From: Mike Ounsworth <[e-mail]>
> Sent: Monday, March 8, 2021 6:54 PM
> To: Roman Danyliw <[e-mail]>; LAMPS <[e-mail]>
> Subject: RE: [lamps] Proposed recharter text
> 
> 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.

Thanks for the back brief on the discussion.

I can appreciate the challenge of figuring out the scope of the work.  I'm looking for a middle ground in charter specificity to allow some of this exploration but not repurpose LAMPS to be the catch-all PQ migration WG.  Nothing prevents the IETF for pursuing such a thing, but that's not LAMPS.  In my review, the only potential scope we have given ourselves is the following sentence, "The specifications developed will enable PKIX and S/MIME protocols to support hybrid key establishment and dual signature mechanisms", which seems like a restatement of a very general objective.  To be fair, we've said equally vague things like this in the past in charter language, but (as I recollect) in those cases there was a specific draft which was guiding that charter bullet. 

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

If we honestly know so little about the solution space that the continuum runs from something as wide as identifier management to X.509v4 (I appreciate there some hyperbole in the scope) then I think we need keep talking to explore the scope before we update the charter on work items.  The current charter seems to guide us in situations like this:

==[ snip
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.
==[ snip

IMO, this is a weighty topic.  In partnership with NIST and CFRG, these PQ challenges are definitely things we as the IETF should be working on.  It may be the case that parts of what we want to get done can be captured in a this charter update; and might also learn that there is more too do that can't be fit easily into the maintenance-style character of LAMPS.  As I noted in my original inquiry, we likely need to find and document straightforward answers to the bounding questions I suggested (I'm open if there are others), so we can at least get started.

I won't speak to the management of agenda time by the chairs, but I see no reason why we can't (continue to?) talk about unadopted documents in this thematic vein until we're closer to understanding the solutions space.  I appreciate this comes with the potential for a "re-charter penalty."

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

Great!  Having these proposals would help us scope the work per the existing LAMPS charter work.

Roman

 
> ---
> 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/sp
> > as
> > 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$