Subject: Re: [lamps] LAMPS Re-charter

From: Russ Housley <[email-masked]>
Date: Wed, 17 Mar 2021 18:26:44 -0400

After listening to the LAMPS re-charter comments, I think this captures a way forward.  The PQC milestones do not have a "send to the IESG" part.  The idea is that we would add those when NIST winners get announced.

Thoughts?

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 in the PKIX and S/MIME
protocols.

5.a. NIST has a Post-Quantum Cryptography (PQC) effort to produce one
or more quantum-resistant public-key cryptographic algorithm standards.
The LAMPS WG will specify the use of these new PQC public key algorithms
with the PKIX certificates and the Cryptographic Message Syntax (CMS).
These specifications will use object identifiers for the new algorithms
that are assigned by NIST.

5.b. NIST and other organizations are developing standards for
post-quantum cryptographic (PQC) algorithms that that will be secure
even if large-scale quantum computers are ever developed.  However, a
lengthy transition from today's public key algorithms to PQC public key
algorithms is expected; time will be needed to gain full confidence in
the new PQC public key algorithms.

5.b.i. The LAMPS WG will specify formats, identifiers, and operational
practices for "hybrid key establishment" that combines the shared
secret values one or more traditional key-establishment algorithm and
one or more NIST PQC key-establishment algorithm or a PQC
key-establishment algorithm vetted by the CFRG.  The shared secret
values will be combined using HKDF (see RFC 5869) or a key derivation
function vetted by the CFRG.

5.b.ii. The LAMPS WG will specify formats, identifiers, and operational
practices for "dual signature" that combine one or more traditional
signature algorithm with one or more NIST PQC signature algorithm or
a PQC algorithm vetted by the CFRG.
 
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.

MILESTONES

Task 1:
Jul 2021 	Adopt a draft for short-lived certificate conventions 
Mar 2022 	Short-lived certificate conventions sent to IESG for BCP publication

Task 2:
DONE     	Adopt a draft for header protection conventions
Nov 2021 	Header protection conventions sent to IESG for standards track publication

Task 3:
DONE     	Adopt a draft for CMP updates
DONE     	Adopt a draft for CMP algorithm
DONE     	Adopt a draft for Lightweight CMP profile
Dec 2021 	CMP updates sent to IESG for standards track publication
Dec 2021 	CMP algorithms sent to IESG for standards track publication
Dec 2021 	Lightweight CMP profile sent to IESG for informational publication

Task 4:
May 2021    Adopt a draft for end-to-end email user agent guidance
Jul 2022    End-to-end email user agent guidance sent to IESG for informational publication

Task 5.a:
Aug 2021    Adopt draft for PQC KEM public keys in PKIX certificates
Aug 2021    Adopt draft for PQC KEM algorithms in CMS
Sep 2021    Adopt draft for PQC signatures in PKIX certificates
Sep 2021    Adopt draft for PQC signatures in CMS

Task 5.b.i:
Sep 2021    Adopt draft for public keys for hybrid key establishment in PKIX certificates
Sep 2021    Adopt draft for hybrid key establishment in CMS

Task 5.b.ii:
Sep 2021    Adopt draft for dual signatures in PKIX certificates
Sep 2021    Adopt draft for dual signature in CMS

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 18 Mar 2021 14:48:36 +0000

Maybe put 2&4 adjacent, but this looks like a nice charter.  I’ve never seen 5.b.ii levels  before.  Long live the Harvard Outline. :)

I don’t recall discussion of short-lived certs but I’m sure that flitted by when I was’t looking.

---

From: Mike Ounsworth <[email-masked]>
Date: Thu, 18 Mar 2021 16:36:53 +0000

5.* look great to me.

Musing out loud about 5.b.i) “hybrid key establishment that combines shared secret values”. I'm wondering if there's anything weird PKIX does with encryption primitives that would need to get hybridized but isn't strictly a "shared secret"? DH-style interactive keyEx and contentEncryption-style non-interactive keyEx are definitely good. Decrypting a challenge nonce as a PoP, probably also good to do that as multiple independent shared secrets that you combine at the other end. Any other weird use of encryption primitives?

---
Mike Ounsworth

From: Spasm <[email-masked]> On Behalf Of Salz, Rich
Sent: March 18, 2021 9:49 AM
To: Russ Housley <[email-masked]>; LAMPS <[email-masked]>
Subject: [EXTERNAL] Re: [lamps] LAMPS Re-charter

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________________
Maybe put 2&4 adjacent, but this looks like a nice charter.  I’ve never seen 5.b.ii levels  before.  Long live the Harvard Outline. :)

---

From: Russ Housley <[email-masked]>
Date: Thu, 18 Mar 2021 14:28:47 -0400

Better words welcome.  I was trying to use words that would allow a mix of KEM, key transport, and key agreement.

Russ

> On Mar 18, 2021, at 12:36 PM, Mike Ounsworth <Mike.Ounsworth=[email-masked]> wrote:
> 
> 5.* look great to me.
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Russ Housley <[email-masked]>
Date: Thu, 18 Mar 2021 17:39:05 -0400

Rich:

> Maybe put 2&4 adjacent, but this looks like a nice charter.

FYI, we can easily change the order.  I added 4 and 5 to the end of the existing charter text so that it would be easier to diff.

Russ

---

From: Rene Struik <[email-masked]>
Date: Mon, 22 Mar 2021 11:03:25 -0400

Hi Russ, colleagues:

Please find below my comments/reflections on the draft charter text.

Best regards, Rene

On 2021-03-17 6:26 p.m., Russ Housley wrote:
> After listening to the LAMPS re-charter comments, I think this 
> captures a way forward.  The PQC milestones do not have a "send to the 
> IESG" part.  The idea is that we would add those when NIST winners get 
> announced.
>
> Thoughts?
>
> Russ
>
> = = = = = = = = =
>
RS>> (E) In the first sentence, I suggest to change the wording "pose" 
to "may pose" to better reflect the current state (this does not change 
the intent of this work item otherwise). In the second sentence, I 
suggest to change "cryptosystems" to "public key algorithms", so as to 
align with verbiage in 5b below. <<RS
> function vetted by the CFRG.

RS>> (discussion) In hybrid key establishment scenarios, it is quite 
likely that for a long time one of the parties may be able to compute 
only one of the shared keys used as input to the key derivation 
function, (e.g., k:=kdf(K1, K2), where K1 is ECDH that both devices 
implemen and where K2 is another algorithm [PQC or not]). In this case, 
one should define default drop-in values for K2, so that authenticated 
key agreement does not fail automatically. I am not sure how to exactly 
word this in charter text, but think this is not just an operational 
practice (since changes calculation of values involved in the hybrid 
scheme). While the primary focus should be on PQC, essentially this is 
about crypto agility (PQC or not), where one wants to have the 
cryptographic assurances a nonempty set of algorithms can provide. <<RS

RS>> (discussion) The current text seems to rule out use of, e.g., KMAC. 
Shouldn't one be somewhat more flexible with where one draws kdfs from 
(and doesn't one expect too much of cfrg)? <<RS

> anything beyond clarifications without rechartering.

RS>> During IETF-110, it was suggested to issue a potential call for 
adoption for various drafts, where, e.g., 
https://datatracker.ietf.org/doc/draft-struik-lamps-verification-friendly-ecdsa/ 
is hard to categorize as a clarification. Shouldn't we add another work 
item, so as to make sure this can be tackled? Or, should we simply scrap 
all but the first sentence of this paragraph (where the preamble of the 
recharter text already suggests a sufficiently high bar for taking this 
on, since it states "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". <<RS

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867

---

From: Russ Housley <[email-masked]>
Date: Mon, 22 Mar 2021 12:17:33 -0400

Rene:

Comments below.  I dropped the milestone proposals since you did not comment on them.

> RS>> (E) In the first sentence, I suggest to change the wording "pose" to "may pose" to better reflect the current state (this does not change the intent of this work item otherwise). In the second sentence, I suggest to change "cryptosystems" to "public key algorithms", so as to align with verbiage in 5b below. <<RS

These make sense to me.  Symmetric ciphers and hash functions are not concerns here.

> RS>> (discussion) In hybrid key establishment scenarios, it is quite likely that for a long time one of the parties may be able to compute only one of the shared keys used as input to the key derivation function, (e.g., k:=kdf(K1, K2), where K1 is ECDH that both devices implemen and where K2 is another algorithm [PQC or not]). In this case, one should define default drop-in values for K2, so that authenticated key agreement does not fail automatically. I am not sure how to exactly word this in charter text, but think this is not just an operational practice (since changes calculation of values involved in the hybrid scheme). While the primary focus should be on PQC, essentially this is about crypto agility (PQC or not), where one wants to have the cryptographic assurances a nonempty set of algorithms can provide. <<RS 
> 
I do not agree with this characterization.  If one of the parties cannot use the PQC key-establishment algorithm, then they are not using a hybrid.  In this case, the party that is capable of using the PQC key-establishment algorithm will have to settle for a traditional only mechanism, or refuse the connection.

During the LAMPS WG interim session, Max Pala talked about the possibility of certificates that contained public keys for traditional and PQC algorithms.  Since that session, draft-ounsworth-pq-composite-sigs has been revised to capture some suggestions for signature algorithms.  Something like this will be needed for key-establishment algorithms as well.

> RS>> (discussion) The current text seems to rule out use of, e.g., KMAC. Shouldn't one be somewhat more flexible with where one draws kdfs from (and doesn't one expect too much of cfrg)? <<RS
> 
The LAMPS WG does not have many cryptographers in the group.  We do have a few, but not as many as CFRG, so we need to depend on the CFRG to get as many cryptographers involved as possible.

> RS>> During IETF-110, it was suggested to issue a potential call for adoption for various drafts, where, e.g., https://datatracker.ietf.org/doc/draft-struik-lamps-verification-friendly-ecdsa/ <https://datatracker.ietf.org/doc/draft-struik-lamps-verification-friendly-ecdsa/> is hard to categorize as a clarification. Shouldn't we add another work item, so as to make sure this can be tackled? Or, should we simply scrap all but the first sentence of this paragraph (where the preamble of the recharter text already suggests a sufficiently high bar for taking this on, since it states "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". <<RS
> 
Three options for a way forward were suggested.  I think the discussion of the options needs to continue.  Once a way forward is agreed, then we can recharter again if needed.

This part is unchanged from the current charter, and there was a fair amount of discussion about it previously.  I'd reather not reopen that discussion.

Russ

---

From: Rene Struik <[email-masked]>
Date: Mon, 22 Mar 2021 13:30:39 -0400

Brief further discussion below...

On 2021-03-22 12:17 p.m., Russ Housley wrote:
>>> captures a way forward.  The PQC milestones do not have a "send to 
>>> the IESG" part.  The idea is that we would add those when NIST 
>>> winners get announced.
>>>
>>> Thoughts?
>>>
>>> Russ
>>>
>>> = = = = = = = = =
>>>
>> RS>> (E) In the first sentence, I suggest to change the wording 
>> "pose" to "may pose" to better reflect the current state (this does 
>> not change the intent of this work item otherwise). In the second 
>> sentence, I suggest to change "cryptosystems" to "public key 
>> algorithms", so as to align with verbiage in 5b below. <<RS
>
>> implemen and where K2 is another algorithm [PQC or not]). In this 
>> case, one should define default drop-in values for K2, so that 
>> authenticated key agreement does not fail automatically. I am not 
>> sure how to exactly word this in charter text, but think this is not 
>> just an operational practice (since changes calculation of values 
>> involved in the hybrid scheme). While the primary focus should be on 
>> PQC, essentially this is about crypto agility (PQC or not), where one 
>> wants to have the cryptographic assurances a nonempty set of 
>> algorithms can provide. <<RS
>>
> I do not agree with this characterization.  If one of the parties 
> cannot use the PQC key-establishment algorithm, then they are not 
> using a hybrid.  In this case, the party that is capable of using 
> the PQC key-establishment algorithm will have to settle for a 
> traditional only mechanism, or refuse the connection.
>
> During the LAMPS WG interim session, Max Pala talked about the 
> possibility of certificates that contained public keys for traditional 
> and PQC algorithms.  Since that 
> session, draft-ounsworth-pq-composite-sigs has been revised to capture 
> some suggestions for signature algorithms.  Something like this will 
> be needed for key-establishment algorithms as well.

RS>> I do not see the issue. Conceptually, hybrid is simply L schemes at 
the same time, where L=1 correspond to (what you call) traditional case. 
No matter how one calls this, the problem of having to cater to very 
long transition time windows remains. As far as I can tell, the informal 
description I used above is consistent with that in Section 2 of NIST SP 
800-56C - Recommendation for Key-Derivation Methods in Key-Establishment 
Schemes, Rev2 (August 18, 2020), which states (second para):

    In addition to the currently approved techniques for the generation
    of the shared secret Z as specified in SP 800-56A and SP 800-56B,
    this Recommendation permits the use of a “hybrid” shared secret of
    the form Z′ = Z || T, a concatenation consisting of a “standard”
    shared secret Z that was generated during the execution of a
    key-establishment scheme (as currently specified in [SP 800-56A] or
    [SP 800-56B]) followed by an auxiliary shared secret T that has been
    generated using some other method. The content, format, length, and
    method used to generate T must be known and agreed upon by all
    parties that will rely upon the derived keying material, as well as
    by any agents trusted to act on their behalf. The key-derivation
    methods specified in this Recommendation will process a hybrid Z′ in
    the same way they process a standard Z. Therefore, for simplicity of
    notation and exposition, any shared secret denoted by the symbol Z
    in the remainder of this Recommendation can be of either the
    “standard” or “hybrid” variety.

The advantage of this "fits both world" model is that an implementation 
that already accommodates the traditional key establishment scheme can 
simply reuse the surrounding functionality, while only requiring a 
"swap-in" of the key establishment and shared key computation flows, 
once the policy would dictate so. Having a data object T already in 
place (which for traditional devices could, e.g., be set to a fixed 
string) would facilitate a change, where T is set to the computed 
outcome whatever alternative key establishment model one wants to enable 
as well. {This assumes one can reuse the message flows.}

<<RS

>
>> RS>> (discussion) The current text seems to rule out use of, e.g., 
>> KMAC. Shouldn't one be somewhat more flexible with where one draws 
>> kdfs from (and doesn't one expect too much of cfrg)? <<RS
>>
> The LAMPS WG does not have many cryptographers in the group.  We do 
> have a few, but not as many as CFRG, so we need to depend on the CFRG 
> to get as many cryptographers involved as possible.
>
>>>
>> adoption for various drafts, where, 
>> e.g.,https://datatracker.ietf.org/doc/draft-struik-lamps-verification-friendly-ecdsa/is 
>> hard to categorize as a clarification. Shouldn't we add another work 
>> item, so as to make sure this can be tackled? Or, should we simply 
>> scrap all but the first sentence of this paragraph (where the 
>> preamble of the recharter text already suggests a sufficiently high 
>> bar for taking this on, since it states "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". <<RS
>>
> Three options for a way forward were suggested.  I think the 
> discussion of the options needs to continue.  Once a way forward is 
> agreed, then we can recharter again if needed.
RS>> I would rather not having administrative hurdles be in place if 
those can be avoided (these take lots of time and also unnecessarily 
delay actual deployment). Since the suggested cause of action path of 
IETF-110 already includes potential adoption, it should not be left as 
ambiguous as to whether adopted material is chartered territory or not. 
I could try and come up with some suggested text for this (although am 
not a parliamentarian). <<RS
>
> This part is unchanged from the current charter, and there was a fair 
> amount of discussion about it previously.  I'd reather not reopen that 
> discussion.
>
> Russ
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 22 Mar 2021 14:22:26 -0400

Rene:

Comments below.

> RS>> I do not see the issue. Conceptually, hybrid is simply L schemes at the same time, where L=1 correspond to (what you call) traditional case. No matter how one calls this, the problem of having to cater to very long transition time windows remains. As far as I can tell, the informal description I used above is consistent with that in Section 2 of NIST SP 800-56C - Recommendation for Key-Derivation Methods in Key-Establishment Schemes, Rev2 (August 18, 2020), which states (second para): 
> 
> In addition to the currently approved techniques for the generation of the shared secret Z as specified in SP 800-56A and SP 800-56B, this Recommendation permits the use of a “hybrid” shared secret of the form Z′ = Z || T, a concatenation consisting of a “standard” shared secret Z that was generated during the execution of a key-establishment scheme (as currently specified in [SP 800-56A] or [SP 800-56B]) followed by an auxiliary shared secret T that has been generated using some other method. The content, format, length, and method used to generate T must be known and agreed upon by all parties that will rely upon the derived keying material, as well as by any agents trusted to act on their behalf. The key-derivation methods specified in this Recommendation will process a hybrid Z′ in the same way they process a standard Z. Therefore, for simplicity of notation and exposition, any shared secret denoted by the symbol Z in the remainder of this Recommendation can be of either the “standard” or “hybrid” variety.
> 
> The advantage of this "fits both world" model is that an implementation that already accommodates the traditional key establishment scheme can simply reuse the surrounding functionality, while only requiring a "swap-in" of the key establishment and shared key computation flows, once the policy would dictate so. Having a data object T already in place (which for traditional devices could, e.g., be set to a fixed string) would facilitate a change, where T is set to the computed outcome whatever alternative key establishment model one wants to enable as well. {This assumes one can reuse the message flows.}
> 
> <<RS
> 
To me, hybrid key-establishment algorithm MUST combine the output of at least one traditional algorithm AND at least one PQC algorithm.  Otherwise, you are just using the traditional  key-establishment algorithm OR the PQC algorithm.
> RS>> I would rather not having administrative hurdles be in place if those can be avoided (these take lots of time and also unnecessarily delay actual deployment). Since the suggested cause of action path of IETF-110 already includes potential adoption, it should not be left as ambiguous as to whether adopted material is chartered territory or not. I could try and come up with some suggested text for this (although am not a parliamentarian). <<RS

Depending on the outcome of the discussion, a charter update may not be needed.

Russ

---

From: Mike Ounsworth <[email-masked]>
Date: Tue, 23 Mar 2021 05:24:32 +0000

Hi Russ and Rene,

I’ll wade into this. 

My current understanding is that strong cryptography wants hybrid and dual modes to be a “MUST USE ALL” sort of thing, while strong backwards compatibility wants a “client can use as many as they support” kind of thing. Conflicting requirements. For signatures you can design such a system where the signer produces all the signatures and the verifying only checks as many as they can since dual signatures are parallel and independent anyway (In an upcoming version of draft-ounsworth-pq-composite-sigs I have added a separate OID for "Composite-OR" to keep the wishy-washy dual signatures distinct from the strict ones, and I'm expecting a healthy debate to arise about whether this is a good idea or not).

But for keyEncipherment and dataEncipherment I don't think you can do that at all; either you do something like:

RSA_encrypt(Z)
PQ_encrypt(T)
K = kdf( Z || T )
or
Z = ECDHE_agree()
PQ_encaps(T)
K = kdf( Z || T )

which requires the client to have implementations of both RSA / ECDHE and PQ.

Or, you do:

RSA_encrypt(Z)
PQ_encrypt(Z)
K = kdf( Z )
or
Z = ECDHE_agree()
PQ_encaps(Z)
K = kdf( Z )
(which may lead to some weird protocol gymnastics..)

Which allows the client to succeed even if it does not understand PQ, but is in fact not a hybrid mode, so, actually, don't do this. So I don't think it's possible to produce hybrid keyEncipherment or dataEncipherment payloads that can be read by both upgraded and legacy clients.

That said, I think I agree with Rene that there will be scenarios where a sender is trying to encrypt for or establish a shared secret with a recipient who has a Composite public key with a PQ alg that the sender does not have an implementation of (ie sender understands composite, but not that PQ alg). I think it is in-scope for any RFCs we produce on this topic to give guidance here: we could give NOT RECOMMENDED type guidance (ie senders should not even attempt to send data unless they support all of the recipient's pub keys), or we could explicitly allow it in either a traditional structure or in a {RSA, null} composite structure. Thoughts? Either way, I think that's an edge-case of implementing hybrid and does not need to be called out in the charter.

To make this more complicated, in many cases the right answer might be that if the recipient wants clients to have the option of communicating with them on RSA-only, then they should publish an RSA-only certificate along with their {RSA, PQ} composite certificate, but I'm not sure that makes sense in all contexts. I'm not sure if we're planning to continue developing the multiple certificates model that Russ was advocating for at the Jan 28 interim meeting, but it handles this situation even less gracefully since there is no good way in a non-negotiated protocol for a recipient to specify whether it wants to receive RSA-only communications.

Related to this: draft-ounsworth-pq-composite-sigs currently defines all the composite structures as "SEQUENCE (1..MAX) OF ..". In an upcoming version I'm planning to change that to "(2..MAX)" unless anyone has a strong need to produce a composite key, signature, or ciphertext with a single element in it?

---
Mike Ounsworth

From: Spasm <[email-masked]> On Behalf Of Russ Housley
Sent: March 22, 2021 1:22 PM
To: Rene Struik <[email-masked]>
Cc: LAMPS <[email-masked]>
Subject: [EXTERNAL] Re: [lamps] LAMPS Re-charter

Comments below.

Thoughts?

Russ

= = = = = = = = =

 
RS>> During IETF-110, it was suggested to issue a potential call for adoption for various drafts, where, e.g., https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-struik-lamps-verification-friendly-ecdsa/__;!!FJ-Y8qCqXTj2!P5P484zgCE-i_SjUZ-vexzoUuiqLYC-niGU4bL9gpVuF7rddsO7NbgmWQAQpPHCj3s4WyN6-oQ$ is hard to categorize as a clarification. Shouldn't we add another work item, so as to make sure this can be tackled? Or, should we simply scrap all but the first sentence of this paragraph (where the preamble of the recharter text already suggests a sufficiently high bar for taking this on, since it states "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". <<RS

Russ

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 23 Mar 2021 11:57:30 -0400

On Tue 2021-03-23 05:24:32 +0000, Mike Ounsworth wrote:

> My current understanding is that strong cryptography wants hybrid and
> dual modes to be a “MUST USE ALL” sort of thing, while strong
> backwards compatibility wants a “client can use as many as they
> support” kind of thing. Conflicting requirements.
>
> For signatures you can design such a system where the signer produces
> all the signatures and the verifying only checks as many as they can
> since dual signatures are parallel and independent anyway (In an
> upcoming version of draft-ounsworth-pq-composite-sigs I have added a
> separate OID for "Composite-OR" to keep the wishy-washy dual
> signatures distinct from the strict ones, and I'm expecting a healthy
> debate to arise about whether this is a good idea or not).
>
> But for keyEncipherment and dataEncipherment I don't think you can do
> that at all;

I agree with Mike's characterizations here about the problem space.

PQ-hybrid signatures are a much easier thing to tackle than PQ-hybrid
encryption.  But PQ-hybrid encryption is also the thing that has the
most urgency.  Signature verification has an out: verifiers can
time-bound their acceptance of legacy signatures once a quantum-based
cryptanalytic attack becomes known to be plausible.  Encryption has no
such out -- an attack isn't necessarily visible to either the producer
or consumer of the ciphertext.  And, an encrypted object might be
attacked in the future so it needs to defend against future mechanisms.

So if we're going to prioritize this work in LAMPS, I think we need to
prioritize the hard problem.  That means tackling PQ-hybrid public key
keyAgreement or keyEncipherment or dataEncipherment schemes that are
"MUST USE ALL", along with whatever attendent signalling mechanisms are
necessary for experimentation and (hopefully) deployment.

I generally advocate for tackling the easier problems first, but i don't
think we should block handling the encryption side of things while we
wrestle with the signatures.

          --dkg

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Mar 2021 12:53:28 -0400

Daniel Kahn Gillmor <[email-masked]> wrote:
    > cryptanalytic attack becomes known to be plausible.

Do you mean that a verifier can say, "I'll accept your legacy signature as
long as it's less than 2hr old"
("2hr" being the time I think it takes for a PQ to be mounted).

Or are you saying something different?

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

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 24 Mar 2021 17:38:27 -0400

> ("2hr" being the time I think it takes for a PQ to be mounted).

The time-bound i was thinking of was:

 - If a quantum-based cryptanalytic attack becomes feasible on a given
   algorithm at time T, then a verifier can still re-validate any
   signatures that arrived (that is, that the verifier has had a copy
   of, or that is visible in some robust historic ledger) prior to time
   T.  That is, old, pre-existing signatures are not automatically
   invalidated by a new quantum attack.  Note that this is *not* the
   case for encrypted material -- old, pre-existing encryption
   protection can indeed be invalidated by a new quantum attack.

The scenario I think you're describing does seem like it might be
potentially useful, but only in the context of defending against a very
specific kind of attack, with very specific protocol expectations.

In particular, if we learn of a quantum-based cryptanalytic attack that
weakens an existing signature system by allowing the production of a
signature (with some remaining non-negligible workfactor), but *without*
permitting private key recovery from public key material, then:

 - the legacy scheme could still be useful in contexts where "freshness"
   of signatures can be detected. For example, in a time-bounded
   challenge-response protocol (verifier sends signer a challenge,
   signer produces signature over a message that includes that challenge
   in a predetermined way), or a key-agreement protocol (e.g. in modern
   TLS) where both parties contribute to the underlying ephemeral
   established secret, and then one or both parties sign the secret to
   prove identity to the other.

I don't know enough about the field of possible quantum attacks to know
whether this latter situation is a plausible scenario.  Certainly if the
quantum attack permits private key recovery from public key material,
then the time bounds described above are meaningless, beceause the
private key could be derived offline, in advance of the protocol
exchange, and then the private key could be used directly with no
additional delay.

        --dkg

---

From: Michael Richardson <[email-masked]>
Date: Thu, 25 Mar 2021 10:49:40 -0400

> protection can indeed be invalidated by a new quantum attack.

Thank you for the clarification.
I wasn't proposing something different, just trying to understand.

You are right that a the PQ attack would likely be used to recover private
keys, not just forge signatures.

---

From: Mike Ounsworth <[email-masked]>
Date: Thu, 25 Mar 2021 17:12:01 +0000

@dkg it sounds a bit like you're hinting at timestamping servers (or their modern equivalent: blockchains and merkle trees).

I wonder if CT logs have the "time-bounded" property you're looking for: any certs indexed into the CT Merkle tree before the "quantum apocalypse" can still be trusted (the cert itself - DN, SANs, etc - can still be trusted; the keys inside it may well be compromised). Though the things getting CT-logged (public web certs) are only valid for ~ 1 year, so they'd likely be expired by the time you care to look back.

---
Mike Ounsworth

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Michael Richardson
Sent: March 25, 2021 9:50 AM
To: Daniel Kahn Gillmor <[email-masked]>
Cc: LAMPS <[email-masked]>; Russ Housley <[email-masked]>; Mike Ounsworth <Mike.Ounsworth=[email-masked]>; Rene Struik <[email-masked]>
Subject: Re: [lamps] [EXTERNAL] Re: LAMPS Re-charter

You are right that a the PQ attack would likely be used to recover private keys, not just forge signatures.

---

From: Carl Wallace <[email-masked]>
Date: Thu, 25 Mar 2021 13:19:14 -0400

Evidence records (RFC4998) and DSSC policies (RFC5698) got at that kind of thing using timestamps and Merkle trees with maintenance of the evidence record being required before an outgoing algorithm was of no value.

On 3/25/21, 1:12 PM, "Spasm on behalf of Mike Ounsworth" <[email-masked] on behalf of Mike.Ounsworth=[email-masked]> wrote:

    ---
    Mike Ounsworth

---

From: Jonathan Hammell <[email-masked]>
Date: Fri, 26 Mar 2021 09:44:06 -0400

I'm in favour of LAMPS working on the PQC items described in 5.*.

Will the changes to PKIX certificates to support hybrid key
establishment (5.b.i) and dual signatures (5.b.ii) also require
modifications to CMP or CMC/EST to support requesting such
certificates from CAs?  The text in 5.b.i and 5.b.ii includes that
LAMPS will specify "operational practices" to support hybrid/dual.  Is
that text intended to cover those aspects?

Jonathan

---

From: Russ Housley <[email-masked]>
Date: Fri, 26 Mar 2021 10:00:38 -0400

Jonathan, we could say "enrollment and operational practices" for greater clarity.

Russ

> On Mar 26, 2021, at 9:44 AM, Jonathan Hammell <[email-masked]> wrote:
>

---

From: Russ Housley <[email-masked]>
Date: Fri, 26 Mar 2021 10:38:47 -0400

The only changes that have been requested are in Section 5 of the draft charter text.  I think this captures it.

Russ

= = = = = = = = = 

5.b.i. The LAMPS WG will specify formats, identifiers, enrollment, and
operational practices for "hybrid key establishment" that combines the
shared secret values one or more traditional key-establishment algorithm
and one or more NIST PQC key-establishment algorithm or a PQC
key-establishment algorithm vetted by the CFRG.  The shared secret
values will be combined using HKDF (see RFC 5869), one of the key
derivation functions in NIST SP 800-56C, or a key derivation
function vetted by the CFRG.

5.b.ii. The LAMPS WG will specify formats, identifiers, enrollment, and
operational practices for "dual signature" that combine one or more
traditional signature algorithm with one or more NIST PQC signature
algorithm or a PQC algorithm vetted by the CFRG.

---

From: Jonathan Hammell <[email-masked]>
Date: Fri, 26 Mar 2021 16:51:19 -0400

Thanks Russ. Yes, that is more clear for me. I agree with this updated
charter text.

Jonathan

On Fri., Mar. 26, 2021, 10:00 a.m. Russ Housley, <[email-masked]>
wrote:

> >> After listening to the LAMPS re-charter comments, I think this captures
> a way forward.  The PQC milestones do not have a "send to the IESG" part.
> The idea is that we would add those when NIST winners get announced.
> >>
> >> Thoughts?
> >>
> >> Russ
> >>
> >> = = = = = = = = =
> >>

---

From: Russ Housley <[email-masked]>
Date: Wed, 31 Mar 2021 15:18:19 -0400

I only heard positive responses, so I am now sending this to the SEC ADs for charter processing.  For the archive, the text is below.

Russ

= = = = = = = =

 

MILESTONES

Task 1:

Task 2:

Task 3:

Task 4:

Task 5.a:

Task 5.b.i:

Task 5.b.ii: