Re: [lamps] Potential Topics for LAMPS Recharter

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:spasm-bounces@ietf.org] On Behalf Of Russ Housley
Sent: Friday, March 30, 2018 2:05 PM
To: LAMPS <spasm@ietf.org>
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
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm