Subject: [lamps] I-D Action: draft-ietf-lamps-cmp-algorithms-02.txt

From: [email-masked]
Date: Wed, 20 Jan 2021 08:10:36 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF.

        Title           : CMP Algorithms
        Authors         : Hendrik Brockhaus
                          Hans Aschauer
                          Mike Ounsworth
                          Serge Mister
	Filename        : draft-ietf-lamps-cmp-algorithms-02.txt
	Pages           : 27
	Date            : 2021-01-20

Abstract:
   This document describes the conventions for using concrete
   cryptographic algorithms with the Certificate Management Protocol
   (CMP).  CMP is used to enroll and further manage the lifecycle of
   X.509 certificates.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lamps-cmp-algorithms/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-lamps-cmp-algorithms-02.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cmp-algorithms-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 20 Jan 2021 16:23:16 +0000

The new version of CMP Algorithms cover the following changes. 
Thanks to the co-authors for their engagement and support.
Any feedback and comments are welcome.
Hendrik

   Changes from version 01 -> 02:
   *  Added Hans Aschauer, Mike Ounsworth, and Serge Mister as co-author
   *  Changed to XML V3
   *  Added SHAKE digest algorithm to Section 2 as discussed at IETF 109
   *  Deleted DSA from Section 3 as discussed at IETF 109
   *  Added RSASSA-PSS with SHAKE to Section 3
   *  Added SECP curves the section on ECDSA with SHA2, ECDSA with
      SHAKE, and EdDSA to Section 3 as discussed at IETF 109
   *  Deleted static-static D-H and ECDH from Section 4.1 based on the
      discussion on the mailing list (see thread "[CMP Algorithms]
      Section 4.1.1 and 4.1.2 drop static-static (EC)DH key agreement
      algorithms for use in CMP")
   *  Added ECDH OIDs and SECP curves, as well as ECDH with curve25519
      and curve448 to Section 4.1 as discussed at IETF 109
   *  Deleted RSA-OAEP from Section 4.2 first as discussed at IETF 109,
      but re-added it after discussion on the mailing list (see thread
      "Mail regarding draft-ietf-lamps-cmp-algorithms")
   *  Added a paragraph to Section 4.3.1 to explain that the algorithms
      and key length for content encryption and key wrapping must be
      aligned as discussed on the mailing list (see thread "[CMP
      Algorithms] Use Key-Wrap with or without padding in Section 4.3
      and Section 5")
   *  Deleted AES-CCM and AES-GMC from and added AES-CBC to Section 5 as
      discussed at IETF 109
   *  Added Section 6.1.2 to offer PBMAC1 as discusses on the mailing
      list (see thread "Mail regarding draft-ietf-lamps-crmf-update-
      algs-02") and restructured text in Section 6 to be easier to
      differentiate between password- and shared-key-based MAC
   *  Deleted Diffie-Hellmann based MAC from Section 6 as is only
      relevant when using enrolling Diffie-Hellmann certificates
   *  Added AES-GMAC and SHAKE-based KMAC to Section 6 as discussed at
      IETF 109
   *  Extended Section 9 to mention Russ supporting with two additional
      I-Ds and name further supporters of the draft
   *  Added a first draft of a generic algorithm selection guideline to
      Appendix A
   *  Added a first proposal for mandatory algorithms for the
      Lightweight CMP Profile to Appendix A
   *  Minor changes in wording

> Von: Spasm <[email-masked]> Im Auftrag von internet-
> [email-masked]
> Gesendet: Mittwoch, 20. Januar 2021 17:11
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatr
> acker.ietf.org%2Fdoc%2Fdraft-ietf-lamps-cmp-
> algorithms%2F&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com
> %7C33f72021ce2446610b6a08d8bd5df512%7C38ae3bcd95794fd4addab42e1
> 495d55a%7C1%7C0%7C637467558529016092%7CUnknown%7CTWFpbGZsb3
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%
> 3D%7C1000&amp;sdata=iCDVg2iRbQL8lyHhCLgFyMC%2Bq5clHP66SNNLLjJ4J
> Qg%3D&amp;reserved=0
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Farchive%2Fid%2Fdraft-ietf-lamps-cmp-algorithms-
> 02.html&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C33f
> 72021ce2446610b6a08d8bd5df512%7C38ae3bcd95794fd4addab42e1495d55
> a%7C1%7C0%7C637467558529016092%7CUnknown%7CTWFpbGZsb3d8eyJ
> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C1000&amp;sdata=aPFIhgAI0QsNrZd0WixSIKgzbsvaD%2F1P0VySbeYoCf4%3
> D&amp;reserved=0
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-lamps-cmp-algorithms-
> 02&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C33f7202
> 1ce2446610b6a08d8bd5df512%7C38ae3bcd95794fd4addab42e1495d55a%7C
> 1%7C0%7C637467558529016092%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000
> &amp;sdata=AIMc2rvOMFDZTsnbuIQ5aYCKzTK%2Boq6qDpTAguR2cu8%3D&
> amp;reserved=0
> 
> 
> https://eur01.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.
> org%2Finternet-
> drafts%2F&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C
> 33f72021ce2446610b6a08d8bd5df512%7C38ae3bcd95794fd4addab42e1495
> d55a%7C1%7C0%7C637467558529026085%7CUnknown%7CTWFpbGZsb3d8e
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> %7C1000&amp;sdata=KpiHghtdehyWTEpEaehk%2Bus0y7cRKQxADq7xBKPMx
> 9E%3D&amp;reserved=0
> 
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=04%7C01%7Chendrik.b
> rockhaus%40siemens.com%7C33f72021ce2446610b6a08d8bd5df512%7C38a
> e3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637467558529026085%7C
> Unknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
> iI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=62sdFOf4HxlerYX%2BDl
> O7ibsG3EEDxfA27mkCGoWrc78%3D&amp;reserved=0

---

From: Russ Housley <[email-masked]>
Date: Thu, 21 Jan 2021 11:58:51 -0500

Hendrik:

Wow, that is a lot of key agreement algorithm alternatives. Do we really need all of them?  Can we drop any?

Russ

> On Jan 20, 2021, at 11:10 AM, [email-masked] wrote:
> 
>

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 21 Jan 2021 18:23:44 +0000

>    Wow, that is a lot of key agreement algorithm alternatives. Do we really need all of them?  Can we drop any?

It's a lot of *everything*  With no guidance on what's important.

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Thu, 21 Jan 2021 18:53:04 +0000

The guidance is to come in the Appendix A

Hendrik

> -----Ursprüngliche Nachricht-----
> Von: Spasm <[email-masked]> Im Auftrag von Salz, Rich
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=04%7C01%7Chendrik.
> brockhaus%40siemens.com%7C31191d8b952c416a5e1508d8be39b7dd%7C38
> ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637468502413902057%7CU
> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
> 6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=WqHe0VxkVbuuLyd6mck
> OpkKKTnq%2BrSr9uymRkiJ3TFc%3D&amp;reserved=0

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Thu, 21 Jan 2021 18:54:07 +0000

What would you suggest to drop?

Hendrik

> Von: Spasm <[email-masked]> Im Auftrag von Russ Housley
> 
> Hendrik:
> 
> brockhaus%40siemens.com%7Ceb613e47461a441631f208d8be2ddc95%7C38
> ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637468451471439269%7CU
> 6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=WgDQTSsFwQKsqwA1Cs
> BDegLvXHV1Py1xwyCPFOwt1ME%3D&amp;reserved=0

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 21 Jan 2021 18:58:52 +0000

>    The guidance is to come in the Appendix A

Okay.  Maybe next draft could have a skeleton Appendix that just said what it will be when done.

I anticipate much bikeshedding there.

CMP is what I consider "old school" where every algorithm is allowed.  Kinda like TLS especially for 1.1, but certainly before 1.3

Maybe we can make it "new school" and just pick a few?  For example, what's in TLS 1.3 plus one or two.

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Thu, 21 Jan 2021 19:10:23 +0000

Sorry, I wanted to say, that there is already guidance in Appendix A. There is also an Update to RFC4210 Appendix D.2 and an Algorithm Profile for the Lightweight CMP.
Any feedback and concrete suggestions to theses algorithm profiles is very welcome. I like the idea to align to algorithms supported by TLS 1.3.

But you are right, when supporting EnvelopedData, e.g., for central key generation, it really gets complex. But this is not due to CMP but to the complexity of key transport in EnvelopedData.
For the Lightweight CMP Profile the central key generation is optional and one could skip Section 4 (apart from PBKDF2, that is needed for PBMAC1 in Section 6) and 5 completely.

Hendrik

> Von: Salz, Rich <[email-masked]>
> Gesendet: Donnerstag, 21. Januar 2021 19:59
> An: Brockhaus, Hendrik (T RDA CST SEA-DE)
> <[email-masked]>; Russ Housley <[email-masked]>;
> [email-masked]
> Betreff: Re: [lamps] I-D Action: draft-ietf-lamps-cmp-algorithms-02.txt
> 
> CMP is what I consider "old school" where every algorithm is allowed.  Kinda
> like TLS especially for 1.1, but certainly before 1.3
>

---

From: Sean Turner <[email-masked]>
Date: Thu, 21 Jan 2021 14:27:26 -0500

Ah this helps.

Can you correct me if I am wrong, but it seems like Sections 2-6 list the OIDs and associated parameters for the various places where AlgorithmIdentifer appears in CMP. And, there’s nothing new; this is okay, it’s just that there are no new OIDs and there are no parameters for the OIDs.

Appendix A is the part of the draft that Appendix D of RFC 4210?

spt

> On Jan 21, 2021, at 14:10, Brockhaus, Hendrik <[email-masked]> wrote:
> 
> https://www.ietf.org/mailman/listinfo/spasm

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 21 Jan 2021 20:47:55 +0000

On 1/21/21, 2:10 PM, "Brockhaus, Hendrik" <[email-masked]> wrote:

    Sorry, I wanted to say, that there is already guidance in Appendix A.

Thanks for the info.

---

From: Russ Housley <[email-masked]>
Date: Thu, 21 Jan 2021 16:37:49 -0500

If all of the algorithms are actually used, I would not mink keeping them, but I wonder about a few that are on the list.  I guess this is a call for people to propose ones to drop.

Russ

> On Jan 21, 2021, at 1:54 PM, Brockhaus, Hendrik <[email-masked]> wrote:
>

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 22 Jan 2021 07:00:31 +0000

Thanks Sean for the summary. That is exactly what I intended to do.
I wanted to enlist the OIDs and where to find the details on relevant algorithms in Sections 2-6.
The specific guidance and profiles is located in Appendix A.

Hendrik 

> Von: Sean Turner <[email-masked]>
> Gesendet: Donnerstag, 21. Januar 2021 20:27
> <[email-masked]>
> Cc: Rich Salz <[email-masked]>; Russ Housley <[email-masked]>;
> [email-masked]
> Can you correct me if I am wrong, but it seems like Sections 2-6 list the OIDs
> and associated parameters for the various places where AlgorithmIdentifer
> appears in CMP. And, there's nothing new; this is okay, it's just that there are
> no new OIDs and there are no parameters for the OIDs.
> 
> > Sorry, I wanted to say, that there is already guidance in Appendix A. There
> is also an Update to RFC4210 Appendix D.2 and an Algorithm Profile for the
> Lightweight CMP.
> > Any feedback and concrete suggestions to theses algorithm profiles is very
> welcome. I like the idea to align to algorithms supported by TLS 1.3.
> >
> > But you are right, when supporting EnvelopedData, e.g., for central key
> generation, it really gets complex. But this is not due to CMP but to the
> complexity of key transport in EnvelopedData.
> > For the Lightweight CMP Profile the central key generation is optional and
> one could skip Section 4 (apart from PBKDF2, that is needed for PBMAC1 in
> Section 6) and 5 completely.
> >
> > Hendrik
> >
> >> CMP is what I consider "old school" where every algorithm is allowed.
> >> Kinda like TLS especially for 1.1, but certainly before 1.3
> >>
> rock
> haus%40siemens.com%7Caf2a533f39304bd8101d08d8be4298c1%7C38ae3bc
> d95794f
> >
> d4addab42e1495d55a%7C1%7C0%7C637468540520523618%7CUnknown%7
> CTWFpbGZsb3
> >
> 3D%7
> C1000&amp;sdata=GHOXtxAVGOzowtF23f7XQ9LP2UnYs%2FpLdrdMtvmYxP8
> %3D&amp;r
> > eserved=0

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 22 Jan 2021 07:03:54 +0000

Yes, if people think, we should drop some of the listed algorithms, we should discuss and align on the mailing list.
I would also like to get input to Appendix A. Any suggestions on how to enhance the Appendix are welcome.

Hendrik

> Von: Russ Housley <[email-masked]>
> 
> If all of the algorithms are actually used, I would not mink keeping them, but
> I wonder about a few that are on the list.  I guess this is a call for people to
> propose ones to drop.
> 
> Russ
> 
> >> Wow, that is a lot of key agreement algorithm alternatives. Do we
> >> really need all of them?  Can we drop any?
> >>
> >> Russ
> >>
> >>
> >>> This draft is a work item of the Limited Additional Mechanisms for
> >>> PKIX and
> >> SMIME WG of the IETF.
> >>>
> >>>       Title           : CMP Algorithms

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 22 Jan 2021 14:38:45 +0000

I suggest you change Appendix A to be a new section 7.  I think it will cause much less confusion; normative appendices are not common, especially something so important as the guidance.

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 22 Jan 2021 17:33:36 +0000

> I suggest you change Appendix A to be a new section 7.  I think it will cause
> much less confusion; normative appendices are not common, especially
> something so important as the guidance.

Good point. If there is consensus, I will do that.

Hendrik

---

From: Russ Housley <[email-masked]>
Date: Fri, 22 Jan 2021 13:31:12 -0500

> Good point. If there is consensus, I will do that.

I think moving the MUST and SHOULD statements about the algorithms into a numbered section is a good idea.

Russ