Subject: Re: [lamps] Proposed recharter text

From: Roman Danyliw <[email-masked]>
Date: Mon, 8 Mar 2021 23:05:41 +0000

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://datatracker.ietf.org/doc/minutes-106-secdispatch/).  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 <[email-masked]> On Behalf Of Russ Housley
> Sent: Wednesday, February 17, 2021 8:49 AM
> To: Panos Kampanakis <[email-masked]>
> Cc: LAMPS <[email-masked]>
> 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=[email-masked]> 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 <[email-masked]> On Behalf Of Russ Housley
> > Sent: Wednesday, February 10, 2021 3:22 PM
> > To: LAMPS <[email-masked]>
> > 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/spasm
> > _______________________________________________
> > Spasm mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/spasm
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Mike Ounsworth <[email-masked]>
Date: Mon, 8 Mar 2021 23:54:09 +0000

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 <[email-masked]> On Behalf Of Roman Danyliw
Sent: March 8, 2021 5:06 PM
To: LAMPS <[email-masked]>
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!

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?

Regards,
Roman

> 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
> 
> > Task 4 is a slightly edited version of the text proposed by DKG 
> > after IETF 109.
> >
> > 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
> >
> > = = = = = = = =
> >
> > 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.
> >
> > 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
> > Diffie-Hellman, ECDSA, ECDH, and EdDSA cannot be depended upon.  As 
> > a result, there are efforts to develop standards for post-quantum 
> > 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
> > clarifications where needed, but the LAMPS WG shall not adopt 
> > anything beyond clarifications without rechartering.
> >
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/sp
> > asm__;!!FJ-Y8qCqXTj2!P1klq0lPS4leBZqYLrnZLsQxT1WWp5lakxXgsd-WgBKYoyt
> > fSawSF-VEU_Byp00Yc3FnDv8GXA$ 
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/sp
> > asm__;!!FJ-Y8qCqXTj2!P1klq0lPS4leBZqYLrnZLsQxT1WWp5lakxXgsd-WgBKYoyt
> > fSawSF-VEU_Byp00Yc3FnDv8GXA$
> 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spas
> m__;!!FJ-Y8qCqXTj2!P1klq0lPS4leBZqYLrnZLsQxT1WWp5lakxXgsd-WgBKYoytfSaw
> SF-VEU_Byp00Yc3FnDv8GXA$

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

---

From: Roman Danyliw <[email-masked]>
Date: Tue, 9 Mar 2021 22:28:11 +0000

Hi Mike!

> From: Mike Ounsworth <[email-masked]>
> Sent: Monday, March 8, 2021 6:54 PM
> To: Roman Danyliw <[email-masked]>; LAMPS <[email-masked]>
> Subject: RE: [lamps] Proposed recharter text
> 
> Hi Roman,
> 
> 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
==[ 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

> 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
> 
> 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!
> !FJ-Y8qCqXTj2!P1klq0lPS4leBZqYLrnZLsQxT1WWp5lakxXgsd-WgBKYoytfSawSF-
> VEU_Byp00Yc3FnDv8GXA$

---

From: Mike Ounsworth <[email-masked]>
Date: Wed, 10 Mar 2021 00:02:01 +0000

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 <[email-masked]> 
Sent: March 9, 2021 4:28 PM
To: Mike Ounsworth <[email-masked]>; LAMPS <[email-masked]>
Subject: [EXTERNAL] RE: [lamps] Proposed recharter text

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

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

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

Roman

> 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
> [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
> 
> 
> > a. After the NIST Post-Quantum Cryptography (PQC) effort produces 
> > one or more quantum-resistant public-key cryptographic algorithm 
> > algorithms with the PKIX certificates and the Cryptographic Message 
> > Syntax
> (CMS).
> >
> > Russ
> >
> > > 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.
> > >
> > >
> > > Task 5 is the text that came out of the discussion that followed 
> > > the virtual interim at the end of last month.
> > >
> > > 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
> > >
> > > = = = = = = = =
> > >
> > > 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 
> > > information.  As a result, revoking short-lived certificates is 
> > > unnecessary and
> pointless.
> > >
> > > 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.
> > > 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
> > > 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
> > > 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
> > > 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.
> > >
> > as

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 10 Mar 2021 14:26:36 +0000

I am concerned about having to decide the hybrid/multi-signature issue NOW during the rechartering.  It's way too soon.  I think we need to discuss the approaches in a technical context (i.e., as part of WG discussions).  What's the best way to do that other than put vague words into a charter?

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 10 Mar 2021 06:54:10 -0800

> I am concerned about having to decide the hybrid/multi-signature issue NOW during the rechartering.  It's way too soon.  I think we need to discuss the approaches in a technical context (i.e., as p…

I think we've seen (other) WG charters that include discussion of a topic
to decide on an approach, with need to recharter to actually produce spec
documents on that topic.  Just one option of many, of course...

-Ben

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Mar 2021 17:12:15 -0500

rs> I am concerned about having to decide the hybrid/multi-signature issue
    rs> NOW during the rechartering.  It's way too soon.  I think we need to
    rs> discuss the approaches in a technical context (i.e., as part of WG
    rs> discussions).  What's the best way to do that other than put vague
    rs> words into a charter?

I agree with Rich, btw.

Benjamin Kaduk <[email-masked]> wrote:
    > I think we've seen (other) WG charters that include discussion of a
    > topic to decide on an approach, with need to recharter to actually
    > produce spec documents on that topic.  Just one option of many, of
    > course...

I would be okay with that if rechartering could take less time.
I feel that this part should be just an exchange between chairs and
AD. i.e. adjustment or creation of some milestones.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 10 Mar 2021 22:31:51 +0000

Hi!

> From: Benjamin Kaduk <[email-masked]>
> Sent: Wednesday, March 10, 2021 9:54 AM
> To: Salz, Rich <rsalz=[email-masked]>
> Cc: Roman Danyliw <[email-masked]>; LAMPS <[email-masked]>
> > I am concerned about having to decide the hybrid/multi-signature issue NOW
> during the rechartering.  It's way too soon.  I think we need to discuss the
> approaches in a technical context (i.e., as part of WG discussions).  What's the
> best way to do that other than put vague words into a charter?
> 
> I think we've seen (other) WG charters that include discussion of a topic to
> decide on an approach, with need to recharter to actually produce spec

+1.  We don't need to have approved charter language to discuss a topic.  We can even discuss and work on drafts that might shape the plan or approach.  We just can't adopt them without a charter change.  I noted in an earlier email [2], we may actually find that as we decompose this problem, not all of it is appropriate to tackle in LAMPS.  Given some of the expressed uncertainty, we may also need to charter "this scope" (whatever it might be) in iterative "chunks".  Certainly, this creates some administrative overhead, but this shouldn't be too high.

In rereading the discussion and trying to answer my own questions [1] on what a tighter scope would be, let me test it with some replacement text:

OLD 5(b)
The specifications developed will enable PKIX and S/MIME protocols to support hybrid key establishment and dual signature mechanisms

TIGHTER SCOPE:
5.b.1 = Specification(s) for identifiers, formats and operational practices to enable dual signature operations using algorithm(s) vetted by the NIST PQ effort

5.b.2 = Specification(s) for identifiers, formats and operational practices to enable hybrid key establishment using the algorithms vetted by the NIST PQ effort and hybrid key establishment constructions defined in a revised SP 800-56C

For me "operational practices" could potentially cover generation, validation, verification, etc.  As written, what it would exclude is updating PKI-related protocols and getting into any work that modifies other protocols that might leverage this work.

How confident are we that draft-ounsworth-pq-composite-sigs is the starting point we want (for just 5.b.1)?  Not pointing to this document specifically, but if we had one we could point to as a starting point this would also help create the bounding box on the new work and satisfy the other LAMPS constraint of "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"

Regards,
Roman

[1] https://mailarchive.ietf.org/arch/msg/spasm/rbcufPA13VfSRLBw41Sbb5bO-J0/
[2] https://mailarchive.ietf.org/arch/msg/spasm/jxmWz7MxaShMEopwE-ZJfzsIbYY/

---

From: Mike Ounsworth <[email-masked]>
Date: Wed, 10 Mar 2021 23:03:26 +0000

Hi Roman,

That tightened scope works for me as it covers what I have already submitted (draft-ounsworth-pq-composite-sigs) as well as the drafts I'm currently working on a -00 of.

A couple nits:

1. Worth a 5.b.0 about the format of public keys that can be used with the 5.b.1 and 5.b.2 mechanisms? 

One of the feedbacks I've received recently is to split composite public keys into its own draft and remove any keyUsage restrictions so that the composite public key format is separate from their usage in sigs, key exchange, public key encryption, etc (other than the restriction that a keyUsage applying to a composite key needs to apply to all component keys. No jamming a keyex and sig key into the same cert á la jumbo certs). This is currently in github here:

https://github.com/EntrustCorporation/draft-ounsworth-pq-composite-keys/blob/master/draft-ounsworth-pq-composite-keys.txt

2.
> using algorithm(s) vetted by the NIST PQ effort

Hybrid and dual mechanisms will likely be used for {RSA, PQ}, or {RSA, PQ1, PQ2}, or even {PQ1, PQ2}. In theory you could also do {RSA2048, RSA4096} or {RSA, ECC}, though I don't know why you would. Point is that they are not only for NIST PQ algs, but to combine traditional + PQ together.

3. 
> How confident are we that draft-ounsworth-pq-composite-sigs is the starting point we want (for just 5.b.1)?  

I am also curious about this :P

---
Mike Ounsworth

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Roman Danyliw
Sent: March 10, 2021 4:32 PM
To: Benjamin Kaduk <[email-masked]>; Salz, Rich <rsalz=[email-masked]>
Cc: LAMPS <[email-masked]>
Subject: [EXTERNAL] Re: [lamps] Proposed recharter text

> during the rechartering.  It's way too soon.  I think we need to 
> discuss the approaches in a technical context (i.e., as part of WG 
> discussions).  What's the best way to do that other than put vague words into a charter?
> 
> produce spec documents on that topic.  Just one option of many, of course...

OLD 5(b)

TIGHTER SCOPE:

Regards,
Roman

[1] https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spasm/rbcufPA13VfSRLBw41Sbb5bO-J0/__;!!FJ-Y8qCqXTj2!Nn4lhE32xGtdDKZPmTkG7WHMu1RrVn765f53RX6p7P1T1MUCGhF8qb-IOM5GHb5nHQ5baDe_rQ$
[2] https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spasm/jxmWz7MxaShMEopwE-ZJfzsIbYY/__;!!FJ-Y8qCqXTj2!Nn4lhE32xGtdDKZPmTkG7WHMu1RrVn765f53RX6p7P1T1MUCGhF8qb-IOM5GHb5nHQ5xgZqFUg$ 

_______________________________________________
Spasm mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!Nn4lhE32xGtdDKZPmTkG7WHMu1RrVn765f53RX6p7P1T1MUCGhF8qb-IOM5GHb5nHQ7jXlJoVg$

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 10 Mar 2021 23:17:05 +0000

Hi Mike!

> Sent: Wednesday, March 10, 2021 6:03 PM
> To: Roman Danyliw <[email-masked]>; Benjamin Kaduk <[email-masked]>; Salz,
> Rich <rsalz=[email-masked]>
> That tightened scope works for me as it covers what I have already submitted
> (draft-ounsworth-pq-composite-sigs) as well as the drafts I'm currently working
> on a -00 of.
> 
> A couple nits:
> 

I can see that.  Others?  Perhaps that work is better framed with the current 5.a work which was (as currently written) about just identifiers (which we could expand to be formats too).

We will likely need to wordsmith all of the things in 5.x when we have it lined up side by side for consistency.

> One of the feedbacks I've received recently is to split composite public keys into
> its own draft and remove any keyUsage restrictions so that the composite
> public key format is separate from their usage in sigs, key exchange, public key
> encryption, etc (other than the restriction that a keyUsage applying to a
> composite key needs to apply to all component keys. No jamming a keyex and
> sig key into the same cert á la jumbo certs). This is currently in github here:
> 
> https://github.com/EntrustCorporation/draft-ounsworth-pq-composite-
> keys/blob/master/draft-ounsworth-pq-composite-keys.txt
> 
> 
> 2.
> Hybrid and dual mechanisms will likely be used for {RSA, PQ}, or {RSA, PQ1,
> PQ2}, or even {PQ1, PQ2}. In theory you could also do {RSA2048, RSA4096} or
> {RSA, ECC}, though I don't know why you would. Point is that they are not only
> for NIST PQ algs, but to combine traditional + PQ together.

Exactly. I was being sloppy trying to emphasize the "new" input (PQ algs) would be and what the specs would focus on.  All of those combinations involving PQ makes sense.  Restated:

5.b.1 = Specification(s) for identifiers, formats and operational practices to enable dual signature operations using traditional algorithm(s) and those vetted by the NIST PQ effort

> I am also curious about this :P

I leave it to be discuss in the WG.

Regards,
Roman

> +1.  We don't need to have approved charter language to discuss a topic.  We
> can even discuss and work on drafts that might shape the plan or approach.
> We just can't adopt them without a charter change.  I noted in an earlier email
> [2], we may actually find that as we decompose this problem, not all of it is
> appropriate to tackle in LAMPS.  Given some of the expressed uncertainty, we
> may also need to charter "this scope" (whatever it might be) in iterative
> "chunks".  Certainly, this creates some administrative overhead, but this
> shouldn't be too high.
> 
> In rereading the discussion and trying to answer my own questions [1] on what
> a tighter scope would be, let me test it with some replacement text:
> 
> OLD 5(b)
> The specifications developed will enable PKIX and S/MIME protocols to support
> hybrid key establishment and dual signature mechanisms
> 
> TIGHTER SCOPE:
> 5.b.1 = Specification(s) for identifiers, formats and operational practices to
> enable dual signature operations using algorithm(s) vetted by the NIST PQ
> effort
> 
> 5.b.2 = Specification(s) for identifiers, formats and operational practices to
> enable hybrid key establishment using the algorithms vetted by the NIST PQ
> effort and hybrid key establishment constructions defined in a revised SP 800-
> 56C
> 
> For me "operational practices" could potentially cover generation, validation,
> verification, etc.  As written, what it would exclude is updating PKI-related
> protocols and getting into any work that modifies other protocols that might
> leverage this work.
> 
> How confident are we that draft-ounsworth-pq-composite-sigs is the starting
> point we want (for just 5.b.1)?  Not pointing to this document specifically, but
> if we had one we could point to as a starting point this would also help create
> the bounding box on the new work and satisfy the other LAMPS constraint of
> "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"
> 
> Regards,
> Roman
> 
> [1]
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spasm/rbcu
> fPA13VfSRLBw41Sbb5bO-J0/__;!!FJ-
> Y8qCqXTj2!Nn4lhE32xGtdDKZPmTkG7WHMu1RrVn765f53RX6p7P1T1MUCGhF
> 8qb-IOM5GHb5nHQ5baDe_rQ$
> [2]
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spasm/jxm
> Wz7MxaShMEopwE-ZJfzsIbYY/__;!!FJ-
> Y8qCqXTj2!Nn4lhE32xGtdDKZPmTkG7WHMu1RrVn765f53RX6p7P1T1MUCGhF
> 8qb-IOM5GHb5nHQ5xgZqFUg$
> 
> !FJ-
> Y8qCqXTj2!Nn4lhE32xGtdDKZPmTkG7WHMu1RrVn765f53RX6p7P1T1MUCGhF
> 8qb-IOM5GHb5nHQ7jXlJoVg$