Subject: [lamps] ASN.1 Module in draft-ietf-lamps-cmp-updates

From: Russ Housley <[email-masked]>
Date: Fri, 23 Apr 2021 14:05:51 -0400

Hendrik:

I do not understand how the AlgIdCtrl works.  Can you provide more text in the document?  Is it about the subject public key?  Is it about the signature algorithm to be used by the CA?

I had a few minutes to look at Appendix A.2.  It needs work.  I have not yet gotten to the point that the module will compile, but these things need to be corrected.  There may be more that I find as I continue to work through the module.

1. I suggest that the module name be change to "PKIXCMP-2021".  This seems apropriate since a new version of the protocol is defined.

2. There is a missing comma:

   RootCaKeyUpdateContent ::= SEQUENCE {
      newWithNew       CMPCertificate,
     ...

3. This does not work with the definition of AlgorithmIdentifier from RFC 5912:

   id-regCtrl-algId OBJECT IDENTIFIER ::= { id-regCtrl TBD3 }
   AlgIdCtrl ::= AlgorithmIdentifier

4. Incorrect Syntax: s/Integer/INTEGER/

   id-regCtrl-rsaKeyLen OBJECT IDENTIFIER ::= { id-regCtrl TBD4 }
   RsaKeyLenCtrl ::= Integer

5. You do not mean to end these comment with the second "--".  Maybe use "-" for the indented one:

   --   id-it-revPassphrase    OBJECT IDENTIFIER ::= {id-it 12}
   --      RevPassphraseValue      ::= EncryptedKey
   --      -- Changed from Encrypted Value to EncryptedKey as a CHOICE
   --      -- of EncryptedValue and EnvelopedData due to the changes
   --      -- made in CMP Updates [thisRFC]
   --      -- Using the choice EncryptedValue is bit-compatible to
   --      -- the syntax without this change

   --   id-it-caCerts OBJECT IDENTIFIER ::= { id-it 17}
   --      CaCertsValue ::= SEQUENCE OF CMPCertificate
   --      -- id-it-caCerts added in CMP Updates [thisRFC]

   --   id-it-rootCaKeyUpdate OBJECT IDENTIFIER ::= { id-it 18}
   --      RootCaKeyUpdateValue ::= RootCaKeyUpdateContent
   --      -- id-it-rootCaKeyUpdate added in CMP Updates [thisRFC]

   --   id-it-certReqTemplate OBJECT IDENTIFIER ::= { id-it 19}
   --      CertReqTemplateValue ::= CertReqTemplateContent
   --      -- id-it-certReqTemplate added in CMP Updates [thisRFC]

Russ

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Mon, 26 Apr 2021 06:52:33 +0000

Russ

Thank you for your review and feedback.
David and I plan to provide a new version of CMP Updates by the end of this week to address the changes from IETF 110. We will also cover the below issues then.

> Von: Russ Housley <[email-masked]>
> Gesendet: Freitag, 23. April 2021 20:06
> 
> Hendrik:
> 
> I do not understand how the AlgIdCtrl works.  Can you provide more text in the
> document?  Is it about the subject public key?  Is it about the signature algorithm
> to be used by the CA?

The purpose of AlgIdCtrl is to provide the algorithm specification the end entity should use for generating its new key pair.
We discussed the concept of the new controls in thread "dtaft-ietf-lamps-cmp-updates and rsaKeyLen".

The current text is:
5.3.19.16.  Certificate Request Template
   This MAY be used by the client to get a template containing
   requirements for certificate request attributes and extensions and
   optionally a specification for the key pair to generate for a future
   certificate request operation.

I could change this to:
5.3.19.16.  Certificate Request Template
   This MAY be used by the client to get a template containing
   requirements for certificate request attributes and extensions.
   The controls id-regCtrl-algId and id-regCtrl-rsaKeyLen MAY contain 
   details on the algorithms whose subject public key values the CA is
   willing to certify.

Is this clearer?
More details on the usage will be provided in the Lightweight CMP Profile document.

> 
> 
> I had a few minutes to look at Appendix A.2.  It needs work.  I have not yet
> gotten to the point that the module will compile, but these things need to be
> corrected.  There may be more that I find as I continue to work through the
> module.
> 
> 
> 1. I suggest that the module name be change to "PKIXCMP-2021".  This seems
> apropriate since a new version of the protocol is defined.

OK, I will change this.

>       newWithNew       CMPCertificate,

Thanks
I will also change this in the 1988 ASN.1 Module in Appendix A1.

>    AlgIdCtrl ::= AlgorithmIdentifier

I will change this to 
id-regCtrl-algId OBJECT IDENTIFIER ::= { id-regCtrl TBD3 }
AlgIdCtrl ::= AlgorithmIdentifier{{...}}

This does not need to be changed in the 1988 ASN.1 Module in Appendix A1, right?

>    RsaKeyLenCtrl ::= Integer

Thanks
I will also change this in the 1988 ASN.1 Module in Appendix A1.

>    --      -- id-it-certReqTemplate added in CMP Updates [thisRFC]

Right, I was not aware, that the second '--' will end the comment. I will change it accordingly.
I will also change this in the 1988 ASN.1 Module in Appendix A1.

Hendrik

---

From: Russ Housley <[email-masked]>
Date: Mon, 26 Apr 2021 09:54:13 -0400

> On Apr 26, 2021, at 2:52 AM, Brockhaus, Hendrik <[email-masked]> wrote:
> 
> Russ
> 

Yes, but I would like to see another sentence about parameters.  With ECDSA, for example, the parameters tell which curve the client should use.

> This does not need to be changed in the 1988 ASN.1 Module in Appendix A1, right?

This is part of the reason that I asked the question at the top.  I think you want:

   AlgorithmIdentifier{ALGORITHM, {...}}

Russ

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 28 Apr 2021 16:27:45 +0000

> >> I do not understand how the AlgIdCtrl works.  Can you provide more
> >> text in the document?  Is it about the subject public key?  Is it
> >> about the signature algorithm to be used by the CA?
> >
> > The purpose of AlgIdCtrl is to provide the algorithm specification the end
> entity should use for generating its new key pair.
> Yes, but I would like to see another sentence about parameters.  With ECDSA,
> for example, the parameters tell which curve the client should use.
> 

I would propose to add the following text.

"The id-regCtrl-algId control MAY be used to identify a cryptographic algorithm, 
see RFC 5820 Section 4.1.2.7, other than rsaEncryption. The algorithm field 
SHALL identify the cryptographic algorithm. The contents of the optional 
parameters field will vary according to the algorithm identified.

The id-regCtrl-rsaKeyLen control SHALL be used for algorithm rsaEncrytion and 
SHALL contain the intended length of the RSA key."

Hendrik

---

From: Russ Housley <[email-masked]>
Date: Wed, 28 Apr 2021 12:50:35 -0400

> On Apr 28, 2021, at 12:27 PM, Brockhaus, Hendrik <[email-masked]> wrote:
> 
> 

This seems fine.  I might also say: For example, when the algorithm is set to id-ecPublicKey, the parameters identify the elliptic curve to be used [RFC5480].

Russ

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 28 Apr 2021 16:52:10 +0000

> Gesendet: Mittwoch, 28. April 2021 18:51
> 
> >>> We discussed the concept of the new controls in thread
> >>> "dtaft-ietf-lamps-cmp-
> >> updates and rsaKeyLen".
> >>>
> >>> The current text is:
> >>> 5.3.19.16.  Certificate Request Template  This MAY be used by the
> >>> client to get a template containing  requirements for certificate
> >>> request attributes and extensions and  optionally a specification
> >>> for the key pair to generate for a future  certificate request
> >>> operation.
> >>>
> >>> I could change this to:
> >>> 5.3.19.16.  Certificate Request Template  This MAY be used by the
> >>> client to get a template containing  requirements for certificate
> >>> request attributes and extensions.
> >>> More details on the usage will be provided in the Lightweight CMP
> >>> Profile
> >> document.
> >>
> >> Yes, but I would like to see another sentence about parameters.  With
> >> ECDSA, for example, the parameters tell which curve the client should use.
> >>
> >
> > "The id-regCtrl-algId control MAY be used to identify a cryptographic
> > algorithm, see RFC 5820 Section 4.1.2.7, other than rsaEncryption. The
> > algorithm field SHALL identify the cryptographic algorithm. The
> > contents of the optional parameters field will vary according to the algorithm
> identified.
> >
> > The id-regCtrl-rsaKeyLen control SHALL be used for algorithm
> > rsaEncrytion and SHALL contain the intended length of the RSA key."
> 
> This seems fine.  I might also say: For example, when the algorithm is set to id-
> ecPublicKey, the parameters identify the elliptic curve to be used [RFC5480].

I will add that sentence. Thanks!

Hendrik

---

From: Russ Housley <[email-masked]>
Date: Fri, 30 Apr 2021 15:23:40 -0400

Thanks for the changes in the ASN.1 module.  The module in draft-ietf-lamps-cmp-updates-09 compiles cleanly for me.

Russ