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

From: [email-masked]
Date: Fri, 09 Jul 2021 07:37:34 -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           : Certificate Management Protocol (CMP) Updates
        Authors         : Hendrik Brockhaus
                          David von Oheimb
	Filename        : draft-ietf-lamps-cmp-updates-12.txt
	Pages           : 56
	Date            : 2021-07-09

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

   The aspects of CMP updated in this document are using EnvelopedData
   instead of EncryptedValue, clarifying the handling of p10cr messages,
   improving the crypto agility, as well as adding new general message
   types, extended key usages to identify certificates for use with CMP,
   and '.well-known' HTTP path segments.

   To properly differentiate the support of EnvelopedData instead of
   EncryptedValue, the CMP version 3 is introduced in case a transaction
   is supposed to use EnvelopedData.

   CMP version 3 is introduced to enable signaling support of
   EnvelopedData instead of EncryptedValue and signaling the use of an
   explicit hash AlgorithmIdentifier in certConf messages, as far as
   needed.

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

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

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

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

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 9 Jul 2021 14:54:02 +0000

The update of CMP Updates consists of only one change as discussed on the mailing list:

   From version 11 -> 12:
   *  Extended Section 2.5 and the ASN.1 modules in Appendix A to allow
      a sequence of certificate profiles in CertProfileValue (see thread
      "id-it-CertProfile in draft-ietf-lamps-cmp-updates")

Any feedback is welcome!

Hendrik

> Von: Spasm <[email-masked]> Im Auftrag von [email-masked]
> Gesendet: Freitag, 9. Juli 2021 16:38
> 
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrac
> ker.ietf.org%2Fdoc%2Fdraft-ietf-lamps-cmp-
> updates%2F&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C2
> ad9a6a4108f4a01377908d942e73fbd%7C38ae3bcd95794fd4addab42e1495d55
> a%7C1%7C0%7C637614383251855583%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C100
> 0&amp;sdata=X5dzQU%2FfjuQLkHC%2FGq1hvgIs%2FbxcBYHdKLVBPZBFDPA%3
> D&amp;reserved=0
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf
> .org%2Farchive%2Fid%2Fdraft-ietf-lamps-cmp-updates-
> 12.html&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C2ad9a
> 6a4108f4a01377908d942e73fbd%7C38ae3bcd95794fd4addab42e1495d55a%7C
> 1%7C0%7C637614383251855583%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&am
> p;sdata=PRZdX8Q1t4%2BU6jjtgfvAMLv92tbog3O%2F1Y%2Bx6w%2FHLvk%3D&a
> mp;reserved=0
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf
> .org%2Frfcdiff%3Furl2%3Ddraft-ietf-lamps-cmp-updates-
> 12&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C2ad9a6a41
> 08f4a01377908d942e73fbd%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7
> C0%7C637614383251855583%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sd
> ata=vg4CoF1V31NZi4kVuT8S5gFWtAGGiSS5iTasBi%2BV8cQ%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%7C2ad
> 9a6a4108f4a01377908d942e73fbd%7C38ae3bcd95794fd4addab42e1495d55a%
> 7C1%7C0%7C637614383251855583%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&a
> mp;sdata=ua%2BlKuLA7%2BuesjODNVmmVOqrkRJHFt9XxmH%2F7cyLX04%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.brockha
> us%40siemens.com%7C2ad9a6a4108f4a01377908d942e73fbd%7C38ae3bcd957
> 94fd4addab42e1495d55a%7C1%7C0%7C637614383251855583%7CUnknown%7
> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
> XVCI6Mn0%3D%7C1000&amp;sdata=uq7w8W9zLF%2FghKVUh8OEY87Hry9rh4C
> dGXl%2Bdv6YP9k%3D&amp;reserved=0

---

From: Russ Housley <[email-masked]>
Date: Wed, 14 Jul 2021 17:39:36 -0400

Hendrik and co-authors:

The document says:

   IMPORTS

       Certificate, CertificateList, Extensions, Name,
       AlgorithmIdentifier, UTF8String,
       id-kp -- if required; otherwise, comment out
              FROM PKIX1Explicit88 {iso(1) identified-organization(3)
              dod(6) internet(1) security(5) mechanisms(5) pkix(7)
              id-mod(0) id-pkix1-explicit-88(18)}
       -- The import of Name is added to define CertificationRequest
       -- instead of importing it from PKCS#10 [RFC2986]

However, I do not think this is what you mean.  I think you always want to import id-kp, and you want to also import UTF8String if needed.

I suggest:

   IMPORTS

       Certificate, CertificateList, Extensions, Name, 
       AlgorithmIdentifier, id-kp
       -- , UTF8String --  -- if required, remove the comments
              FROM PKIX1Explicit88 -- {iso(1) identified-organization(3)
              -- dod(6) internet(1) security(5) mechanisms(5) pkix(7)
              -- id-mod(0) id-pkix1-explicit-88(18)}
       -- The import of Name is added to define CertificationRequest
       -- instead of importing it from PKCS#10 [RFC2986]

By now, I would expect that UTF8String is widely supported, which may not have been true when RFC 4210 was published.

Russ

> On Jul 9, 2021, at 10:54 AM, Brockhaus, Hendrik <[email-masked]> wrote:
>

---

From: Russ Housley <[email-masked]>
Date: Wed, 14 Jul 2021 18:04:02 -0400

Hendrik and co-authors:

The ASN.1 module does not properly compile.  A small change will make it compile, and I think it represent your intent.

OLD:

   CertStatus ::= SEQUENCE {
      hashAlg [0] AlgorithmIdentifier OPTIONAL,
      -- the hash algorithm to use for calculating certHash
      -- SHOULD NOT be used in all cases where the AlgorithmIdentifier
      -- of the certificate signature specifies a hash algorithm
       certHash    OCTET STRING,
       -- the hash of the certificate, using the same hash algorithm
       -- as is used to create and verify the certificate signature
       certReqId   INTEGER,
       -- to match this confirmation with the corresponding req/rep
       statusInfo  PKIStatusInfo OPTIONAL }

NEW:

   CertStatus ::= SEQUENCE {
      hashAlg [0] AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} OPTIONAL,
      -- the hash algorithm to use for calculating certHash
      -- SHOULD NOT be used in all cases where the AlgorithmIdentifier
      -- of the certificate signature specifies a hash algorithm
       certHash    OCTET STRING,
       -- the hash of the certificate, using the same hash algorithm
       -- as is used to create and verify the certificate signature
       certReqId   INTEGER,
       -- to match this confirmation with the corresponding req/rep
       statusInfo  PKIStatusInfo OPTIONAL }

In addition, I suspect that you should look at the comments where AlgorithmIdentifier is used without { } after them.  For example:

   --      KeyPairParamRepValue    ::= AlgorithmIdentifer

should probably be something like:

   --      KeyPairParamRepValue    ::= AlgorithmIdentifer{{...}}

since it is a comment, I am not sure...

Russ

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Thu, 15 Jul 2021 06:01:35 +0000

Russ

Thank you for checking the ASN.1 modules.

> Von: Russ Housley <[email-masked]>
> Gesendet: Mittwoch, 14. Juli 2021 23:40
> 
> Hendrik and co-authors:
> 
> The document says:
> 
>    IMPORTS
> 
> However, I do not think this is what you mean.  I think you always want to
> import id-kp, and you want to also import UTF8String if needed.

Yes, you are right.

> been true when RFC 4210 was published.

Thanks for your suggestion. I will do the change with the next update.

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Thu, 15 Jul 2021 06:17:58 +0000

Russ

Thank you this hint. 

> Gesendet: Donnerstag, 15. Juli 2021 00:04
> 
> Hendrik and co-authors:
> 
> The ASN.1 module does not properly compile.  A small change will make it
> compile, and I think it represent your intent.
> 
> OLD:
> 

I will also adapt this with the next update of the draft.

Would you recommend to also use the {DIGEST-ALGORITHM, {...}} in the ASN.1 example in Section 2.10?
In RFC4210 this syntax was not used, but it was introduced later.

> In addition, I suspect that you should look at the comments where
> AlgorithmIdentifier is used without { } after them.  For example:
> 

That was hard to find, as I was looking for AlgorithmIdentifier and the module says AlgorithmIdentifer :-)
Thank you for the hint.
It will be changed with the next version too.

Hendrik

---

From: Russ Housley <[email-masked]>
Date: Thu, 15 Jul 2021 10:32:12 -0400

> On Jul 15, 2021, at 2:17 AM, Brockhaus, Hendrik <[email-masked]> wrote:
> 
> Russ
> 
> Thank you this hint. 
> 

That is correct.  The new module employs the conventions adopted in RFC 5911, RFC 5912, and RFC 6268.

> It will be changed with the next version too.

Thanks.

Russ

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Thu, 15 Jul 2021 15:21:41 +0000

Russ

I am not sure, if I get your point correctly :-)

> Gesendet: Donnerstag, 15. Juli 2021 16:32
> 
> >> The ASN.1 module does not properly compile.  A small change will make
> >> it compile, and I think it represent your intent.
> >>
> >> OLD:
> >>

My question was on the content of Section 2.19. Should we also use the specific syntax {DIGEST-ALGORITHM, {...}}, or should we stay without the {}?

Hendrik

---

From: Russ Housley <[email-masked]>
Date: Thu, 15 Jul 2021 11:30:10 -0400

> My question was on the content of Section 2.19. Should we also use the specific syntax {DIGEST-ALGORITHM, {...}}, or should we stay without the {}?

In the comments that talk about the various id-it InfoTypeAndValue, when it is an AlgorithmIdentifier, it would be helpful to indicate the kind of algorithm that is expected.  The current module does not provide this information, in most places it has {{...}}.  I did not lokk back into the body of the document for this information.

Russ

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Thu, 15 Jul 2021 15:38:34 +0000

Russ 

Sorry, my fault. I should have copied the text portion.

> Gesendet: Donnerstag, 15. Juli 2021 17:30
> 
> Hendrik:
> 
> > My question was on the content of Section 2.19. Should we also use the
> specific syntax {DIGEST-ALGORITHM, {...}}, or should we stay without the {}?
> 
> In the comments that talk about the various id-it InfoTypeAndValue, when it is
> an AlgorithmIdentifier, it would be helpful to indicate the kind of algorithm that
> is expected.  The current module does not provide this information, in most
> places it has {{...}}.  I did not lokk back into the body of the document for this
> information.

Current Text:
2.10.  Update Section 5.3.18. - Certificate Confirmation Content

   This section introduces an optional hashAlg field to the CertStatus
   type used in certConf messages to explicitly specify the hash
   algorithm for those certificates where no hash algorithm is specified
   in the signatureAlgorithm field.

   Replace the ASN.1 Syntax of CertStatus with the following text:

      CertStatus ::= SEQUENCE {
         hashAlg [0] AlgorithmIdentifier OPTIONAL, 
         certHash    OCTET STRING,
         certReqId   INTEGER,
         statusInfo  PKIStatusInfo OPTIONAL
      }

My question is, should I also add {DIGEST-ALGORITHM, {...}} in the update Section 5.3.18. of RFC 4210?
The changes in the comments of the ASN.1 modules is understood and will be done with the next update.

Hendrik

---

From: Russ Housley <[email-masked]>
Date: Thu, 15 Jul 2021 11:46:56 -0400

> The changes in the comments of the ASN.1 modules is understood and will be done with the next update.

Yes, this should be both in the module and in the body of the document.

The alternative is to define DigestAlgorithmIdentifier as is done in RFC 5911:

     DigestAlgorithmIdentifier ::= AlgorithmIdentifier{DIGEST-ALGORITHM, {...}}

This might be a bit more readable, but it is actually the same thing.

Russ

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Thu, 15 Jul 2021 16:08:56 +0000

Russ

OK, thanks. I will also change the content accordingly.

Hendrik

> -----Ursprüngliche Nachricht-----
> Gesendet: Donnerstag, 15. Juli 2021 17:47
> An: Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked]>
> Cc: [email-masked]; von Oheimb, David (T RDA CST SEA-DE)
> <[email-masked]>
> Betreff: Re: [lamps] draft-ietf-lamps-cmp-updates-12: Comments on A.2. 2002
> ASN.1 Module
> 
> Hendrik:
> 
> >>>>> Would you recommend to also use the {DIGEST-ALGORITHM, {...}} in
> >>>>> the
> >>>> ASN.1 example in Section 2.10?
> >> In the comments that talk about the various id-it InfoTypeAndValue,
> >> when it is an AlgorithmIdentifier, it would be helpful to indicate
> >> the kind of algorithm that is expected.  The current module does not
> >> provide this information, in most places it has {{...}}.  I did not
> >> lokk back into the body of the document for this information.
> >
> > Current Text: