Subject: Re: [lamps] Proposed re-charter text for hybrid and dual crypto modes

From: Russ Housley <[email-masked]>
Date: Mon, 1 Feb 2021 11:18:05 -0500

> On Jan 30, 2021, at 5:38 PM, Michael Richardson <[email-masked]> wrote:
> 
> 
> Russ Housley <[email-masked]> wrote:
>> 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.
> 
> To be clear for me, such a system would get a unique algorithm OID,
> and would count as a single signature outside of the crypto function.

That is my understanding as well.

> 
>> 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.
> 
> Such as system would be visible as having two algorithmOIDs, and this would
> be visible outside of the crypt function.  The length discussion about
> matching the two identities, etc. deals with this side of things.

That is not the proposal in draft-ounsworth-pq-composite-sigs-04.

> 
> My understanding is that we might have situations where we have dual
> signatures, and the second signature might be a hybrid signature.
> 
> RFC5280 only provides for one algorithmIdentifier (signatureAlgorithm) at the
> top-level sequence, which is not contained under the signature.
> We had some document a few years ago that dealt with coordinating this with
> the section 4.1.2.3 Signature which *is* the signature. (I think Russ wrote that)
> 
> I know that some of the proposals (maybe all) put the second algorithm into
> various extensions, and that is really the only way to do the dual-signatures
> in a backwards compatible way.
> 
> I note that RFC5280 is only at Proposed Standard.
> It was suggested it was more mature, but I can't find any evidence of that:
> not in the DT nor on the rfc-editor page.
> 
> I believe that write a few "Updates" (Amends) RFC5280 documents is
> appropriate, but I think that given that this is going to be a long
> transition, that I think the charter should include text that would allow
> RFC5280bis to be produced.  That might not be a near-term priority, but I
> think that it needs to get done for a number of technical and marketing reasons.

The RFC index does shoe RFC 5280 as PROPOSED STANDARD.  It seems like we should figure out the minimum work needed to advance it.  Clearly there are more that two interoperable implementations.

Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 10 Feb 2021 15:22:02 -0500

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.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 10 Feb 2021 23:43:59 +0000

The charter looks good to me; one question.

    Standard status.

What does this mean?

---

From: Russ Housley <[email-masked]>
Date: Thu, 11 Feb 2021 10:54:39 -0500

> On Feb 10, 2021, at 6:43 PM, Salz, Rich <rsalz=[email-masked]> wrote:
> 

RFC 6410 says:

      An Internet Standard is characterized by a high degree of
      technical maturity and by a generally held belief that the
      specified protocol or service provides significant benefit to the
      Internet community.

And:

   The IESG, in an IETF-wide Last Call of at least four weeks, confirms
   that a document advances from Proposed Standard to Internet Standard.
   The request for reclassification is sent to the IESG along with an
   explanation of how the criteria have been met.  The criteria are:

   (1) There are at least two independent interoperating implementations
       with widespread deployment and successful operational experience.

   (2) There are no errata against the specification that would cause a
       new implementation to fail to interoperate with deployed ones.

   (3) There are no unused features in the specification that greatly
       increase implementation complexity.

   (4) If the technology required to implement the specification
       requires patented or otherwise controlled technology, then the
       set of implementations must demonstrate at least two independent,
       separate and successful uses of the licensing process.

   After review and consideration of significant errata, the IESG will
   perform an IETF-wide Last Call of at least four weeks on the
   requested reclassification.  If there is consensus for
   reclassification, the RFC will be reclassified without publication of
   a new RFC.

So, I think the LAMPS WG would gather the information regarding these four criteria.

Russ

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 11 Feb 2021 15:59:54 +0000

Thanks for that detail.  This makes sense.  The charter looks good to me.  I am interested in helping move 5280 forward.

No unused features?  Do they realize this is X.509? :)

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 11 Feb 2021 11:05:59 -0500

Are there even two interoperable implementations of 5280?

I do mean that in full seriousness - and it seems practically unlikely that
(2) or (3) can be satisfied...

On Thu, Feb 11, 2021 at 11:00 AM Salz, Rich <rsalz=
[email-masked]> wrote:

> Thanks for that detail.  This makes sense.  The charter looks good to me.
> I am interested in helping move 5280 forward.
>
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 11 Feb 2021 16:09:14 +0000

*   Are there even two interoperable implementations of 5280?

No, I think things will need to be stripped out.

  *   I do mean that in full seriousness - and it seems practically unlikely that (2) or (3) can be satisfied...

On the other hand, it seems silly to not make 5280 a standard, seems de facto anyway.

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Thu, 11 Feb 2021 17:13:12 +0000

> Von: Spasm <[email-masked]> Im Auftrag von Salz, Rich
> 
> Thanks for that detail.  This makes sense.  The charter looks good to me.  I
> am interested in helping move 5280 forward.
> 

X.509 further developed. Just for curiosity, is it planned to align RFC 5280 with the current version of ITU-T X.509 regarding, e.g., multiple cryptographic algorithms  public-key certificate and authorization and validation list extensions?
Or is it planned to reduce the functionality of RFC 5280?

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 11 Feb 2021 14:03:15 -0500

On Thu, Feb 11, 2021 at 11:09 AM Salz, Rich <[email-masked]> wrote:

>
>    - Are there even two interoperable implementations of 5280?
>
>
>

I agree, but I also worry it will open re-litigation of things that are
de-facto, but not standardized, despite efforts to the contrary.

As a concrete example, the handling of extendedKeyUsage within
intermediates is one of those issues that comes up every few years, but to
not much progress. This debate goes back (as far as I can tell) to even the
RFC 2459 work, where rough consensus and running code (at the time, and at
the present) implemented something different. This is something that
affects (2) with respect to the process of determining validity.

As an example of (3), consider the use of StringPrep with regards to DN
handling/comparison, which itself was a concession to the failed flag-days
of UTFString that earlier drafts had. Few implementations support it, even
fewer support it as specified (due to the evolution of StringPrep and the
Unicode tables). However, removing the normalization of DNs prior to
comparison creates backwards compat issues that previous drafts prioritized
avoiding, hence the complexity in the first place.

>
>    - I do mean that in full seriousness - and it seems practically
>    unlikely that (2) or (3) can be satisfied...
>

In the abstract, yes. However, I worry that the necessity of trying to
address (2) and (3) will limit a lot of practical progress.

I think one of the most challenging aspects is that, for better or for
worse, we didn't end up with The Directory, nor did we end up with an
IETF-anchored, protocol-agnostic PKI, nor did work like NADF's work on RFC
1255 lead to region-specific authorities. The consequence is that we have
many PKIs - for different applications, protocols, and use cases - and so
answering the questions for (2) and (3) requires defining the scope of the
problem. When 5280 first began (~2005), there was still a widespread belief
in the federated directory model, as shown by the contemporary efforts like
OASIS PKIA TC. Do we still pretend that is the case - that folks will be
using LDAP to discover certificates ala the Public File - in order to avoid
upsetting the 5280 applecart? Or do we have to also revisit the scope and
context of 5280, so that we can have some basis to measure against (2) and
(3)?

Am I suggesting these are things I want to do, or suggesting we should do
them? Not at all. Yet I also don't see how we might make progress in
assessing (2) and (3), and thus, progress on 5280-et-al to Standards track,
without having to touch on the very scope of 5280, which we know emerged
from a time in which several of the technical assumptions and concessions
predicted did not, in actuality, pan out.

Again, to offer a concrete example of this challenge: policyConstraints and
their handling are an example of something that can be useful, but not
widely supported (and even less widely used, save in "private" PKIs), and
less-widely still interoperable. They were and are a product of assumptions
about how "The PKI" would be administered and federated, which we know in
practice did not manifest. Are they relics to be excised, ala (3)? Are they
things to revisit to add clarity ala (2)? Do we have good criteria to
quantify (1)? The answer is very much "it depends".

---

From: Russ Housley <[email-masked]>
Date: Thu, 11 Feb 2021 14:08:45 -0500

> X.509 further developed. Just for curiosity, is it planned to align RFC 5280 with the current version of ITU-T X.509 regarding, e.g., multiple cryptographic algorithms  public-key certificate and a…

I think that would reduce the ability to find interoperable implementations.  RFC 5280 is aligned with X.509v3.

> Or is it planned to reduce the functionality of RFC 5280?

That is the discussion that the proposed charter text will facilitate.

Russ

---

From: Russ Housley <[email-masked]>
Date: Thu, 11 Feb 2021 14:20:03 -0500

Ryan:

> I agree, but I also worry it will open re-litigation of things that are de-facto, but not standardized, despite efforts to the contrary.
> 
> As a concrete example, the handling of extendedKeyUsage within intermediates is one of those issues that comes up every few years, but to not much progress. This debate goes back (as far as I can tell) to even the RFC 2459 work, where rough consensus and running code (at the time, and at the present) implemented something different. This is something that affects (2) with respect to the process of determining validity.
> 
> As an example of (3), consider the use of StringPrep with regards to DN handling/comparison, which itself was a concession to the failed flag-days of UTFString that earlier drafts had. Few implementations support it, even fewer support it as specified (due to the evolution of StringPrep and the Unicode tables). However, removing the normalization of DNs prior to comparison creates backwards compat issues that previous drafts prioritized avoiding, hence the complexity in the first place.

I do not agree with your characterization of the extendedKeyUsage concern, but I do agree that implementation in CA certificates does not match RFC 5280.  I proposed a solution to this situation some years ago, but implementers did not want to change.  In addition, RFC 5280 is a profile of X.509, so RFC 5280 should not specify a different behavior than X.509.  I continue to believe that a different OID should be used if a different behavior is desired.

Internationalization is hard. This was the outcome of many very long discussions. This is an area where RFC 5280 could be improved but stringPrep was the advice from the ART Area folks at the time.  

Russ

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 11 Feb 2021 14:52:53 -0500

On Thu, Feb 11, 2021 at 2:20 PM Russ Housley <[email-masked]> wrote:

> I do not agree with your characterization of the extendedKeyUsage concern,
> but I do agree that implementation in CA certificates does not match RFC
> 5280.  I proposed a solution to this situation some years ago, but
> implementers did not want to change.  In addition, RFC 5280 is a profile of
> X.509, so RFC 5280 should not specify a different behavior than X.509.  I
> continue to believe that a different OID should be used if a different
> behavior is desired.
>

Russ,

Thanks for helping emphasize the points I'm making, on both points.
2459/3280/5280 emerged in parallel to existing implementations of "PKI
things", whether it be SSLeay, 'the code that would become" Mozilla NSS,
the "IE code that became CryptoAPI", etc. Rich can speak better to/for
OpenSSL, but I would suggest that, for a number of implementations of
"certificate things", the goal was not "implement X.509v3", nor "implement
5280", but "implement enough for TLS". While it's true that there used to
be more diversity of implementations that purely targeted 5280 (and the
abstract goals), and certainly Microsoft's efforts on CryptoAPI and
Sun-Oracle's on Java eventually circled to "implement everything spec'd in
5280", the reality is that much of the running code does not and has not
had 5280 as the target for interoperability.

This is to the point (2). Efforts during the 2459/3280/5280 work each tried
to bring this issue re: EKUs, and resolve, and the reaction you raise now
was much the same then: "If you want this, you should do something
different" - yet the implementers had already implemented their logic, and
it was the immovable object of objections like you raise here that
ultimately lead these behaviors not to appear in the specs, yet still lead
to all sorts of surprising interactions and potential risks (e.g. Flame,
which was both in part possible and mitigated due to this EKU chaining
behaviour).

> Internationalization is hard. This was the outcome of many very long
> discussions. This is an area where RFC 5280 could be improved but
> stringPrep was the advice from the ART Area folks at the time.
>

This isn't strictly about internationalization, though. This was about
trying to bend over backwards with existing certificates/PKIs, while trying
to get stuff to use the internationalization-capable "new" features. This
is readily clear through RFC 2459's language, which 3280 inherited, which
set that migration date of December 31, 2003 - but tried to maintain
backwards compat.

5280 significantly altered this with the StringPrep, but still, my point
was that this "feature" is ***only*** relevant if you're:
a) Trying to use The Directory to look up certificates, and thus needing to
use DAP/LDAP
b) Trying to ensure all (new) certificates conform to a particular profile,
without requiring the replacement of existing root/intermediate
certificates.

My point in highlighting this was that twenty years later, we know (a) is
largely not true in a "PKIX" sense, even if it remains true for a number of
enterprise PKIs. Equally, we know that (b) was a giant own-goal to the goal
it was trying to achieve, because rather than encouraging transition,
implementations just kept the non-UTF8String approaches around.

So when revisiting 5280, and asking in the context of (3), it's reasonable
to ask "Is this feature a product of design assumptions re: The Directory,
and thus suitable to cut, or is this feature essential simply because it's
used in a non-Internet-wide-PKI-sense". And, in the context of (1), where
this varies greatly, "Does this feature prevent us from progressing to
Internet Standard". Concretely, an alternative would be to simply do what
other PKI communities have done (including the CA/B Forum), and which
reflect the algorithm of 2459/3280, which is to say "memcmp() is the only
comparison function", which works as equally fine for UTF8String as it does
for PrintableString.

Again, I'm not particularly excited to revisit all of this, precisely
because this is a tremendous amount of effort. As it relates, however, to
the discussion relevant to the charter, I'm suggesting that if folks aren't
looking for multiple years of debate and relitigation, then the draft
charter should provide better guidance for what is in scope and out of
scope, so that we can resolve such discussions as early as possible, before
they suck up years of effort and energy.

The last time the IETF touched these docs, PKI was the old-Blockchain, and
the excitement led to everything and the kitchen sink being included. Do we
still pretend that's the case, in order to progress far enough to make the
"minor" adjustments may not (and may never) reflect implementations, or do
we accept the Internet has changed since 2005, and try to adjust how
implementations have evolved, even if that will take us years?

---

From: Michael Richardson <[email-masked]>
Date: Thu, 11 Feb 2021 16:55:07 -0500

Salz, Rich <rsalz=[email-masked]> wrote:
    > Thanks for that detail.  This makes sense.  The charter looks good to
    > me.  I am interested in helping move 5280 forward.

    > No unused features?  Do they realize this is X.509? :)

My opinion is that there is a lot of confusing legacy text in RFC5280 which
could be removed, and that we ought to spin the document.
I'm not really happy about that though, and if we can just do a IESG process,
then I'll happily be in the rough here.

I don't think we need to do this in 2021, but by March 2022, I think we
should either have started with spinning the draft, or have determined that
we don't need to.

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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 11 Feb 2021 16:57:00 -0500

Russ Housley <[email-masked]> wrote:
    > ago, but implementers did not want to change.  In addition, RFC 5280 is
    > a profile of X.509, so RFC 5280 should not specify a different behavior
    > than X.509.  I continue to believe that a different OID should be used
    > if a different behavior is desired.

I disagree. "X.509" is dead as a document/protocol/process.
RFC5280 rules, and we should no longer consider it a profile, but a complete specification.
That's why I call them *PKIX* certificates.

---

From: Mike Ounsworth <[email-masked]>
Date: Tue, 16 Feb 2021 20:16:42 +0000

Russ, your 5 a&b look good to me.

I am eager to see the discussions around scoping the PQC effort. For example, I recently received a question about whether draft-ounsworth-pq-composite-sigs-04 is compatible with RFC 5914. The answer is Yes, but the point is that we're probably in for an n x m amount of work where n is the number of hybrid / dual mechanisms we standardize, and m is the number of RFCs to check for compatibility. 

I wonder if it's worth an I-D to keep track of which RFCs will need updating for PQC, and who's leading each one?

---
Mike Ounsworth

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Russ Housley
Sent: February 10, 2021 2:22 PM
To: LAMPS <[email-masked]>
Subject: [EXTERNAL] [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.

______________________________________________________________________
I propose the attached recharter text.

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.

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

---

From: Russ Housley <[email-masked]>
Date: Tue, 16 Feb 2021 15:26:47 -0500

Mike:

We need to be driven by contributions.  I do not think an I-D is the right thing here.  We could used a CodiMD document or the LAMPS WG wiki (which has not seen any use to date).

Russ

> On Feb 16, 2021, at 3:16 PM, Mike Ounsworth <[email-masked]> wrote:
>

---

From: Mike Ounsworth <[email-masked]>
Date: Tue, 16 Feb 2021 23:10:43 +0000

TL;DR: KEMTLS is premature for this round of LAMPS re-chartering, but would warrant a 5c if it gains traction in the TLS WG.

Another thing to consider is the KEMTLS proposal (see [1]) which makes the observation that PQ KEMs (ie key transport using PQ public key encryption) use much less bandwidth than PQ signatures. KEMTLS is a re-work of the TLS handshake to provide perfect forward secrecy using only KEM primitives. Notable for LAMPS because it would mean that keyEncipherment certificates without a matching signing cert would be back in the mainstream and things like EST RFC 7030 and the Lightweight CMP draft don't currently support encryption PoPs.

There isn't a TLS WG draft for KEMTLS yet, but I have it on good authority that it's coming. If it gains traction, then the LAMPS charter will likely need a 5c to add KEM PoPs for enrollment, update, and revocation where they are missing (EST RFC 7030 and the Lightweight CMP draft come to mind).

[1] Schwabe, Stebila, Wiggers, "Post-Quantum TLS Without Handshake Signatures", 2020

---
Mike Ounsworth

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Russ Housley
Sent: February 10, 2021 2:22 PM
To: LAMPS <[email-masked]>
Subject: [EXTERNAL] [lamps] Proposed recharter text

Russ

= = = = = = = =

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 17 Feb 2021 04:01:05 +0000

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

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.

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.

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 17 Feb 2021 06:51:43 +0000

> Von: Spasm <[email-masked]> Im Auftrag von Mike Ounsworth
> 
> There isn't a TLS WG draft for KEMTLS yet, but I have it on good authority
> that it's coming. If it gains traction, then the LAMPS charter will likely need a
> 5c to add KEM PoPs for enrollment, update, and revocation where they are
> missing (EST RFC 7030 and the Lightweight CMP draft come to mind).
> 

CMP is open for other PoPs than signature based as it uses CRMF. With current algorithms RSA and ECDSA/EdDSA signature based PoP is sufficient. As soon as there is a need to extend to PQ public key encryption based PoPs, this could be done. To authenticate revocation requests a public key encryption based message protection is required. Both could be handled in a PQ CMP Profile.

- Hendrik

---

From: Russ Housley <[email-masked]>
Date: Wed, 17 Feb 2021 08:48:34 -0500

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

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Thu, 18 Feb 2021 16:54:50 +0000

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 <[email-masked]> 
Sent: Wednesday, February 17, 2021 8:49 AM
To: Panos Kampanakis (pkampana) <[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:
> 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.
> 
> 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.
> 
> specified in a separate document.  This work will be coordinated with the
LWIG WG.
> promote interoperability of end-to-end cryptographic protection of 
> email messages.  This may include guidance about the generation, 
> 
> 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.
> will enable PKIX and S/MIME protocols to support hybrid key establishment
and dual signature mechanisms.
> clarifications where needed, but the LAMPS WG shall not adopt anything 
> beyond clarifications without rechartering.
>

---

From: Mike Ounsworth <[email-masked]>
Date: Thu, 18 Feb 2021 17:08:25 +0000

Hey Panos,

I started another chain off this thread about KEMTLS. Since it doesn't even have an I-D yet, I agree that it's waaaay premature to start chartering LAMPS for it.

I read 5a as "Assign PKIX OIDs to the stuff that falls out of the NIST competition" and nothing more. Is that the correct interpretation Russ?

---
Mike Ounsworth

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Panos Kampanakis (pkampana)
Sent: February 18, 2021 10:55 AM
To: Russ Housley <[email-masked]>
Cc: LAMPS <[email-masked]>
Subject: [EXTERNAL] Re: [lamps] Proposed recharter text

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 <[email-masked]>
Sent: Wednesday, February 17, 2021 8:49 AM
To: Panos Kampanakis (pkampana) <[email-masked]>
Cc: LAMPS <[email-masked]>
Subject: Re: [lamps] Proposed recharter text

Panos:

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

<pkampana=[email-masked]> wrote:
> the
LWIG WG.

---

From: Russ Housley <[email-masked]>
Date: Thu, 18 Feb 2021 12:37:13 -0500

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 ([email-masked]) 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) <[email-masked]> wrote:
>

---

From: Russ Housley <[email-masked]>
Date: Thu, 18 Feb 2021 12:40:40 -0500

Mike:

> On Feb 18, 2021, at 12:08 PM, Mike Ounsworth <Mike.Ounsworth=[email-masked]> wrote:
> 
> Hey Panos,
> 

Yes, that was the intent.  We may also have to say something about the conventions for various fields for the "winner" algorithms as well.

Russ