Subject: Re: [lamps] Potential Topics for LAMPS Recharter

From: Tim Hollebeek <[email-masked]>
Date: Mon, 2 Apr 2018 14:11:13 +0000

>    2) draft-housley-cms-mts-hash-sig: SECDISPATCH suggested that the LAMPS
> WG take on hash-based signatures for CMS as an additional work item.
> 
>    4) draft-truskovsky-lamps-pq-hybrid-x509: certificate extensions for
quantum
> resistant keys and signatures.
> 
>    5) draft-housley-cms-mix-with-psk: a way to mix a pre-shared key with
> traditional key transport and key agreement algorithms.
> 
>    6) draft-housley-hash-of-root-key-cert-extn: a way to manage key
rollover for
> a root CA.

We would potentially implement and deploy all of these, depending on how the
effort works out.

-Tim

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 2 Apr 2018 15:34:43 +0100

On 30/03/18 19:05, Russ Housley wrote:
> 2) draft-housley-cms-mts-hash-sig: SECDISPATCH suggested that the
> LAMPS WG take on hash-based signatures for CMS as an additional work
> item.

As I said at the mic in London, I support this work being done
in the IETF, but I'm not sure LAMPS is a good choice. It's not
a *terrible* choice, but doing this in LAMPS is a bit odd as I
for one would argue that an experimental RFC could be the right
target for this work and that seems like a mismatch with the
LAMPS charter.

Re-chartering LAMPS to allow for this kind of work also seems
to me to risk hitting the PKIX problem where we end up with a
WG that's a catch-all for anything related to PKI. I figure
that'd be a bad plan, but others may disagree.

In summary, I think maybe SUIT is a better match for hash-based
sig work, given that s/w signing is the likely use-case for
these schemes. That said, I'm not subscribed to SUIT so don't
know if there's real interest from participants there either.
I'd also be fine if the ADs spun up a new short-lived WG just
for this work.

FWIW, if the end result here is to do this work in LAMPS, I
won't whine about that. (I may whine if this WG really starts
turning into PKIX++ though:-)

S.

---

From: "Erik Andersen" <[email-masked]>
Date: Mon, 2 Apr 2018 16:46:36 +0200

Hi,

Just for information. The work on extensions for quantum-safe keys and
signatures is already underway for X.509. Text is already developed and
allocation of object identifiers done. I will shortly publish the draft
amendment although this is a little against ITU-T's policy. We will push the
extension through the approval process as quickly as possible and then
publish the ninth edition of X.509.

 We should avoid duplication of work. However, we will appreciate any
comment to improve the work.

Best regards,

Erik

-----Oprindelig meddelelse-----
Fra: Spasm [mailto:[email-masked]] På vegne af Tim Hollebeek
Sendt: 02 April 2018 16:11
Til: Russ Housley <[email-masked]>; LAMPS <[email-masked]>
Emne: Re: [lamps] Potential Topics for LAMPS Recharter

> LAMPS WG take on hash-based signatures for CMS as an additional work item.
> 
quantum
>    5) draft-housley-cms-mix-with-psk: a way to mix a pre-shared key 
> with traditional key transport and key agreement algorithms.
> 
rollover for

-Tim

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 2 Apr 2018 10:51:42 -0400

> turning into PKIX++ though:-)

​I agree that PKIX became a problem. But a large part of the problem was
that PKIX became a brand in the industry and so implementing 'all of' PKIX
became an issue.

I don't see SUIT as a good fit. First, I don't think we are ready to use
these sigs for software signing, I think we would be using them for
authenticating roots of trust to be used in extremis. To go beyond that
narrow remit openeth up a very large problem space. We would have to go
through the whole issue of how to bootstrap QR crypto applications.

I do not think we need to go any further at this stage than to convince
ourselves that we tell people to create sufficient signing capacity to
support the ability to bootstrap.

The way I would like to containerize the problem is:

LAMPS: Itsy bitsy extension to certificate signing certs to embed QR
signature bootstrap
IRTF: Propose QRKI (Quantum Resistant Key Infrastructure) and bootstrap (a
five year mission)

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Mon, 2 Apr 2018 15:29:22 +0000

Hi Russ

All of these docs are very interesting. My perspective: 

- draft-nir-saag-star belongs to LAMPS as an Informational draft. Short-lived certs have been popular and revocation comes with challenges. So, addressing some of the considerations of short-lived certs is something that should exist to document and promote fixing existing issues with short lived certs. 

- I think draft-housley-cms-mts-hash-sig should be adopted, but as a "HBS in CMS" draft. It could include LMS, XMSS and SPHINCS+ or any stateless HBS scheme the NIST PQ Project standardizes. I wouldn't want it to be just "LMS in CMS" because stateful schemes might not see wide adoption because their state requirement. Pretty much all HBS schemes consist of similar structures, so I can see a more general draft fit well in LAMPS. 

- I have a concern that draft-housley-cms-mix-with-psk will not see great deployment. draft-ietf-ipsecme-qr-ikev2 is similar, but given the existing IKEv2 wide deployment, draft-ietf-ipsecme-qr-ikev2 had to exist as temporary solution in order to prevent downgrades to IKEv2 because of QC concerns. Not sure if adding PSK into CMS will see wide adoption before the NIST PQ Project standardizes on PQ algorithms. 

- draft-truskovsky-lamps-pq-hybrid-x509 should be in LAMPS. I am a co-author, so I am biased. The reason is that a PQ PKI needs to be defined early (agnostic to the NIST PQ Public Key Sig algorithms) in order to be ready start migrating when the algorithms are ready. Waiting will add years to the migration, which will take a long time anyway. A lot of the points brought up in IETF 101 and the points Eric. R. mentioned about TLS show that there are items that need to be considered here. Now, I see this draft belong to LAMPS, but the TLS WG to heavily weigh on it. 

- draft-housley-hash-of-root-key-cert-extn is needed. EST supports migrating with "transition certificates" that overlap ala CMP. I think defining the transition in one cert itself is a cleaner method and the CMP method can be the backup if for some reason a brand new key has to be used. If there is interest by CAs to implement, I think this belongs to LAMPS. 

- revocation format definition: This is a real problem, but I am concerned that it won't see much real-world adoption by CAs.

Rgs,
Panos

-----Original Message-----
From: Spasm [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Friday, March 30, 2018 2:05 PM
To: LAMPS <[email-masked]>
Subject: [lamps] Potential Topics for LAMPS Recharter

Several things have come up over the last few weeks that might be added to the LAMPS charter.

First, two Iinternet-Drafts were directed to LAMPS during the SECDISPATCH session at IETF 101 in London:

   1) draft-nir-saag-star: SECDISPATCH suggested that the LAMPS WG take on short-lived certificates as an additional work item.

   2) draft-housley-cms-mts-hash-sig: SECDISPATCH suggested that the LAMPS WG take on hash-based signatures for CMS as an additional work item.

Second, at the end of the LAMPS session at IETF 101 in London, three topics were raised as possible new work items:

   3) <no-draft>: the need for revocation request format.

   4) draft-truskovsky-lamps-pq-hybrid-x509: certificate extensions for quantum resistant keys and signatures.

   5) draft-housley-cms-mix-with-psk: a way to mix a pre-shared key with traditional key transport and key agreement algorithms.

Third, the Security ADs have asked that we consider a document that was headed for the independent stream:

   6) draft-housley-hash-of-root-key-cert-extn: a way to manage key rollover for a root CA.

The current charter give some guidelines for the work items that belong in LAMPS:

   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.

Which of these potential work items have a "known constituency" and are likely to see "real deployment"?

Russ

_______________________________________________
Spasm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spasm

---

From: Tim Hollebeek <[email-masked]>
Date: Mon, 2 Apr 2018 17:36:57 +0000

I agree with Phil.  We need something small in the short term (LAMPS is fine 
for that), and something well-baked in the longer term.  As I said in London, 
I think we will eventually need a QuiRKI working group.

-Tim

I agree that PKIX became a problem. But a large part of the problem was that 
PKIX became a brand in the industry and so implementing 'all of' PKIX became 
an issue..

I don't see SUIT as a good fit. First, I don't think we are ready to use these 
sigs for software signing, I think we would be using them for authenticating 
roots of trust to be used in extremis. To go beyond that narrow remit openeth 
up a very large problem space. We would have to go through the whole issue of 
how to bootstrap QR crypto applications.

I do not think we need to go any further at this stage than to convince 
ourselves that we tell people to create sufficient signing capacity to support 
the ability to bootstrap.

LAMPS: Itsy bitsy extension to certificate signing certs to embed QR signature 
bootstrap

---

From: Russ Housley <[email-masked]>
Date: Tue, 3 Apr 2018 13:23:04 -0400

> On Apr 2, 2018, at 10:34 AM, Stephen Farrell <[email-masked]> wrote:
> 

SUIT seems to be looking for the same document, but using COSE.

Russ