Subject: [lamps] I-D Action: draft-ietf-lamps-cmp-updates-04.txt

From: [email-masked]
Date: Tue, 08 Sep 2020 02:38:54 -0700

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 Updates
        Author          : Hendrik Brockhaus
	Filename        : draft-ietf-lamps-cmp-updates-04.txt
	Pages           : 45
	Date            : 2020-09-08

Abstract:
   This document contains a set of updates to the base syntax and
   transport of Certificate Management Protocol (CMP) version 2.  This
   document updates RFC 4210 and RFC 6712.

   Specifically, the CMP services updated in this document comprise the
   enabling of using EnvelopedData instead of EncryptedValue, the
   definition of extended key usages to identify certificates of CMP
   endpoints on certification and registration authorities, and adds an
   HTTP URI discovery mechanism and extend the URI structure.

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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lamps-cmp-updates-04
https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cmp-updates-04

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

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: Tue, 8 Sep 2020 10:02:44 +0000

The update of draft-ietf-lamps-cmp-updates-04 contains the following changes:

   From version 03 -> 04:

   o  Added Section 2.7 to introduce three new id-it IDs for uses in
      general messages as discussed (see thread "draft-ietf-lamps-cmp-
      updates add section to introduce id-it-caCerts, id-it-
      rootCaKeyUpdate, and id-it-certReqTemplate")

   o  Added the new id-it IDs and the /.well-known/cmp to the IANA
      Considerations of [RFC4210] in Section 2.9

   o  Updated the IANA Considerations of [RFC4210] in Section 2.10

   o  Some changes in wording on Section 3 due to review comments from
      Martin Peylo

Any feedback is welcome!

- Hendrik

> -----Ursprüngliche Nachricht-----
> Von: Spasm <[email-masked]> Im Auftrag von [email-masked]
> Gesendet: Dienstag, 8. September 2020 11:39
> An: [email-masked]
> Cc: [email-masked]
> Betreff: [lamps] I-D Action: draft-ietf-lamps-cmp-updates-04.txt
> 
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrack
> er.ietf.org%2Fdoc%2Fdraft-ietf-lamps-cmp-
> updates%2F&amp;data=02%7C01%7Chendrik.brockhaus%40siemens.com%7Cd
> 50630850443468dc4d608d853db31e5%7C38ae3bcd95794fd4addab42e1495d55
> a%7C1%7C0%7C637351548182227735&amp;sdata=QLqk%2FRUIf8RDIL%2BSFX
> 9Jukr2v6YdbdLYlvoTLJWqBf8%3D&amp;reserved=0
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.
> org%2Fhtml%2Fdraft-ietf-lamps-cmp-updates-
> 04&amp;data=02%7C01%7Chendrik.brockhaus%40siemens.com%7Cd50630850
> 443468dc4d608d853db31e5%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7
> C0%7C637351548182237721&amp;sdata=yNr38w4emJY%2FODDb6wONR0K6I
> MGM%2FY9KqC6y9HMNKEU%3D&amp;reserved=0
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrack
> er.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lamps-cmp-updates-
> 04&amp;data=02%7C01%7Chendrik.brockhaus%40siemens.com%7Cd50630850
> 443468dc4d608d853db31e5%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7
> C0%7C637351548182237721&amp;sdata=lUvCFDbP2HyTZoFzqs5ZLuLrTuzDElAL
> NrRs5oxKMUE%3D&amp;reserved=0
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.
> org%2Frfcdiff%3Furl2%3Ddraft-ietf-lamps-cmp-updates-
> 04&amp;data=02%7C01%7Chendrik.brockhaus%40siemens.com%7Cd50630850
> 443468dc4d608d853db31e5%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7
> C0%7C637351548182237721&amp;sdata=wRBh3G0j0dQ0MoXNRXUamhdmVK
> 4udpUynMj%2FH5KxNwQ%3D&amp;reserved=0
> 
> 
> https://eur01.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%
> 2Finternet-
> drafts%2F&amp;data=02%7C01%7Chendrik.brockhaus%40siemens.com%7Cd50
> 630850443468dc4d608d853db31e5%7C38ae3bcd95794fd4addab42e1495d55a
> %7C1%7C0%7C637351548182237721&amp;sdata=%2FU1wcBFTw%2BOBGzlI6l
> RH5rmnRqdtwNdKTp2MWMERtho%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=02%7C01%7Chendrik.brockha
> us%40siemens.com%7Cd50630850443468dc4d608d853db31e5%7C38ae3bcd95
> 794fd4addab42e1495d55a%7C1%7C0%7C637351548182237721&amp;sdata=w
> BWVnxiezLTuhtJkm5933Okt541C5f3FD6qZWY2Mb0U%3D&amp;reserved=0

---

From: Russ Housley <[email-masked]>
Date: Tue, 8 Sep 2020 11:15:18 -0400

Hendrik:

I just took a quick look at the ASN.1 modules in the I-D.  They need some work, and new module identifiers.

I would be fine with dropping the old ASN.1 syntax (Appendix A.1) at this stage, but I'd like to know if anyone still relies on it.

A.1. says:

   PKIXCMP {iso(1) identified-organization(3)
         dod(6) internet(1) security(5) mechanisms(5) pkix(7)
         id-mod(0) id-mod-cmp2000(16)}

The module OID needs to be updated.  I think the module name should be updated too. I suggest:

   PKIXCMP-2020-88 {iso(1) identified-organization(3)
         dod(6) internet(1) security(5) mechanisms(5) pkix(7)
         id-mod(0) id-mod-cmp2020-88(TBD1)}

And, then the IANA considerations should ask for this OID to be assigned.

A.2 says:

   PKIXCMP-2009
       { iso(1) identified-organization(3) dod(6) internet(1)
       security(5) mechanisms(5) pkix(7) id-mod(0)
       id-mod-cmp2000-02(50) } DEFINITIONS EXPLICIT TAGS ::=
   BEGIN

First, the DEFINITIONS should be on a new line.

Second, The module OID needs to be updated, and I think the module name should be updated too.  I suggest:

   PKIXCMP-2020-02
       { iso(1) identified-organization(3) dod(6) internet(1)
       security(5) mechanisms(5) pkix(7) id-mod(0)
       id-mod-cmp2020-02(TBD2) } 

And, then the IANA considerations should ask for this OID to be assigned.

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 8 Sep 2020 14:16:53 -0400

Hendrik:

I also have a question.  Is there a need to add another pvno value to indicate that one of the new OIDs in being used?  I am not sure from the I-D whether this is needed or not?

Russ

> On Sep 8, 2020, at 11:15 AM, Russ Housley <[email-masked]> wrote:
> 
> Hendrik:
>

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 9 Sep 2020 06:08:14 +0000

Russ

> Von: Russ Housley <[email-masked]>
> Gesendet: Dienstag, 8. September 2020 17:15
> 
> Hendrik:
> 
> I would be fine with dropping the old ASN.1 syntax (Appendix A.1) at this stage,
> but I'd like to know if anyone still relies on it.

>From CMC Updates (RFC 6402) I understood that I should also do the update to the module from RFC4210, as this is the normative one. 
I can also drop it, if it is not required.

> And, then the IANA considerations should ask for this OID to be assigned.

Thanks you for this hint. I will update the document accordingly.

Shall I add RFC 5912 to the list of updated RFCs, as A.2 updates the ASN.1 module in Section 9 of RFC 5912?

Hendrik

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 9 Sep 2020 06:20:21 +0000

Russ

> Gesendet: Dienstag, 8. September 2020 20:17
> 
> Hendrik:
> 
> I also have a question.  Is there a need to add another pvno value to indicate
> that one of the new OIDs in being used?  I am not sure from the I-D whether
> this is needed or not?
> 

My goal was to come up with an update that does not require a new pvno.
As I see the changes, they are all compatible and not in conflict with CMP V2.
All OIDs for general messages are optional. CMP V2 explicitly offers the specification of additional OIDs.

   -- Example InfoTypeAndValue contents include, but are not limited
   -- to, the following (un-comment in this ASN.1 module and use as
   -- appropriate for a given environment):
...
   -- This construct MAY also be used to define new PKIX Certificate
   -- Management Protocol request and response messages, or general-
   -- purpose (e.g., announcement) messages for future needs or for
   -- specific environments.

I am not sure, if I understood your point correctly. Where do you see the need for a new pvno? 

Hendrik