Subject: [lamps] dtaft-ietf-lamps-cmp-updates and rsaKeyLen

From: Russ Housley <[email-masked]>
Date: Tue, 15 Sep 2020 17:20:47 -0400

Hendrik:

The ASN.1 modules add rsaKeyLen, but the body of the document does not say anything.  I think it should explain the new field.

The ASN.1 module comment is the only hint right now:

      -- Any reasonable RSA key length, if subjectPublicKeyInfo
      -- of the certTemplate has the OID rsaEncryption.

Also, if the certTemplate has the OID id-ecPublicKey, is a similar convention needed to provide a list of supported curves?

Russ

---

From: Tomas Gustavsson <[email-masked]>
Date: Wed, 16 Sep 2020 07:37:05 +0200

How about if the oid is RSA-PSS? We've started seing such OIDs lately
(mostly by mistake).

Regards,
Tomas

On 2020-09-15 23:20, Russ Housley wrote:
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 16 Sep 2020 07:02:31 +0000

Russ

> Von: Russ Housley <[email-masked]>
> Gesendet: Dienstag, 15. September 2020 23:21
> 
> Hendrik:
> 
> The ASN.1 modules add rsaKeyLen, but the body of the document does not say
> anything.  I think it should explain the new field.

You are right. I will add a brief explanation to the respective section.

> Also, if the certTemplate has the OID id-ecPublicKey, is a similar convention
> needed to provide a list of supported curves?

For rsaKeyLen it is possible to specify one key length and for id-ecPublicKey it is possible to specify one named curve in ECParameters. I think we are consistent in this regard.
If an RA needs to offer a set of allowed algorithms or curves, it can use the Signing Key Pair Types general message as specified in RFC 4210 Section 5.3.19.2.

Hendrik

---

From: Russ Housley <[email-masked]>
Date: Wed, 16 Sep 2020 09:14:11 -0400

> If an RA needs to offer a set of allowed algorithms or curves, it can use the Signing Key Pair Types general message as specified in RFC 4210 Section 5.3.19.2.

Okay.  That means that id-ecPublicKey would appear many times, once for each curve.  Can we add text to say that?

Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 16 Sep 2020 09:15:16 -0400

Good point. Probably should cover RSA-OAEP too.

Russ

> On Sep 16, 2020, at 1:37 AM, Tomas Gustavsson <[email-masked]> wrote:
> 
>

---

From: Russ Housley <[email-masked]>
Date: Wed, 16 Sep 2020 15:11:37 -0400

Hendrik:

I had another though about rsaKeyLen.  RFC 4210 uses CertRequest as defined on RFC 4211 in the certificate request, which is:

   CertRequest ::= SEQUENCE {
      certReqId     INTEGER,        -- ID for matching request and reply
      certTemplate  CertTemplate, --Selected fields of cert to be issued
      controls      Controls OPTIONAL } -- Attributes affecting issuance

   Controls  ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue

Would it be cleaner to define a new control for the rsaKeyLen?

These controls are already set up as an OID followed by one or more attribute values.  So this seems like a very clean way to provide a minimum RSA key size or a set of elliptic curves.

Russ

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 18 Sep 2020 10:46:43 +0000

Russ

> Gesendet: Mittwoch, 16. September 2020 15:14
> 
> Hendrik:
> >
> >> The ASN.1 modules add rsaKeyLen, but the body of the document does
> >> not say anything.  I think it should explain the new field.
> >
> >> Also, if the certTemplate has the OID id-ecPublicKey, is a similar
> >> convention needed to provide a list of supported curves?
> >
> > For rsaKeyLen it is possible to specify one key length and for id-ecPublicKey it
> is possible to specify one named curve in ECParameters. I think we are
> consistent in this regard.
> > If an RA needs to offer a set of allowed algorithms or curves, it can use the
> Signing Key Pair Types general message as specified in RFC 4210 Section
> 5.3.19.2.
> 

Right, a genRep can carry a sequence of InfoTypeAndValue and therefore a sequence of offered algorithms.
- In the case of 5.3.19.2 it could be a number of id-ecPublicKey structures.
- In the case of id-it-certReqTemplate (Lightweight CMP Profile, Section 4.4.4) we did not allow this case, but yes, we could change Lightweight CMP Profile Section 4.4.1 accordingly to offer it.
I can add a sentence to RFC 4210 Section 5.3.20 to explicitly state that several InfoTypeAndValues of the same type are allowed.
Did I get your suggestion right?

I will respond to your second suggestion on using Controls separately.

Hendrik

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 18 Sep 2020 11:09:34 +0000

Russ

> -----Ursprüngliche Nachricht-----
> I had another though about rsaKeyLen.  RFC 4210 uses CertRequest as defined
> on RFC 4211 in the certificate request, which is:
> 
> These controls are already set up as an OID followed by one or more attribute
> values.  So this seems like a very clean way to provide a minimum RSA key size
> or a set of elliptic curves.

I am uncertain if this addressing the use case I had in mind. But may be I did not fully understand your suggestion.

I defined id-it-certReqTemplate to offer the EE means to request detailed guideline on the content of a certificate request it whishes to send. The response should include the option to specify the concrete algorithm to generate a key pair for. Therefor a prefilled certTemplate is exactly what we need, plus the key length for RSA keys in rsaKeyLen.
The EE does not need to specify the key length of the RSA key in the certificate request itself when sending it to the PKI.

May be it helps, if you explain your use case.

Hendrik

---

From: Russ Housley <[email-masked]>
Date: Fri, 18 Sep 2020 09:29:27 -0400

> Did I get your suggestion right?

That seems like a fine way to move forward.

> I will respond to your second suggestion on using Controls separately.

That is an alternative to the above.

Russ

---

From: Russ Housley <[email-masked]>
Date: Fri, 18 Sep 2020 09:31:08 -0400

> May be it helps, if you explain your use case.

I see.  Never mind.

Russ

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 18 Sep 2020 15:18:21 +0000

Russ

> Von: Brockhaus, Hendrik (CT RDA CST SEA-DE)
> 
> Russ
> 
> > I had another though about rsaKeyLen.  RFC 4210 uses CertRequest as
> > defined on RFC 4211 in the certificate request, which is:
> >
> > These controls are already set up as an OID followed by one or more
> > attribute values.  So this seems like a very clean way to provide a
> > minimum RSA key size or a set of elliptic curves.
> 
> I defined id-it-certReqTemplate to offer the EE means to request detailed
> guideline on the content of a certificate request it whishes to send. The
> response should include the option to specify the concrete algorithm to
> generate a key pair for. Therefor a prefilled certTemplate is exactly what we
> need, plus the key length for RSA keys in rsaKeyLen.
> The EE does not need to specify the key length of the RSA key in the certificate
> request itself when sending it to the PKI.
> 

After discussing your proposal with David, we came up with this suggestion:

--------------------snip--------------------
CertReqTemplateContent ::= SEQUENCE {
   certTemplate           CertTemplate,
   controls                    Controls OPTIONAL
   }

-- Controls  ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue

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

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

CertReqTemplateValue contains a prefilled certTemplate to be used for the future certificate request. The SubjectPublicKeyInfo field in the certTemplate MUST NOT be used. In case the PKI management entity wishes to specify supported algorithms, the controls field MUST be used. One AttributeTypeAndValue per supported algorithm MUST be used.
--------------------snip--------------------

Does this go into the direction you had in mind?

Hendrik

---

From: Russ Housley <[email-masked]>
Date: Fri, 18 Sep 2020 12:38:06 -0400

> Does this go into the direction you had in mind?

Yes, and it puts the control in place fo DSA keys, DH keys, and others that might come along that might need parameters at this stage in the processing.

Russ

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Mon, 21 Sep 2020 16:02:49 +0000

Russ:

> Von: Spasm <[email-masked]> Im Auftrag von Russ Housley
> 
> Hendrik:
> 
> > - In the case of id-it-certReqTemplate (Lightweight CMP Profile, Section 4.4.4)
> we did not allow this case, but yes, we could change Lightweight CMP Profile
> Section 4.4.1 accordingly to offer it.
> > I can add a sentence to RFC 4210 Section 5.3.20 to explicitly state that several
> InfoTypeAndValues of the same type are allowed.

I agree. 
But I just think I caused a little confusion above. I will try to sort this out:
- 5.3.19.2 and 5.3.19.3 already allow for a list of AlgorithmIdentifier. This should be fine except that one cannot specify RSA key lengths this way.
- If id-it-certReqTemplate uses the new Controls element (instead of rsaKeyLen) it also allows specifying several AlgorithmIdentifier elements and in addition also several RSA key lengths.
Therefore I feel like there is no need to add a note to 5.3.20 to point out that it is allowed to return several InfoTypeAndValue elements of same type but different values.
Do we have the same understanding?

- Hendrik

---

From: Russ Housley <[email-masked]>
Date: Mon, 21 Sep 2020 12:10:49 -0400

> - 5.3.19.2 and 5.3.19.3 already allow for a list of AlgorithmIdentifier. This should be fine except that one cannot specify RSA key lengths this way.

Right.  As already pointes out on the list, this applies to RSA-PSS and RSA-OAEP as well as the umbrella RSA OID (rsaEncryption) that is in the current document.

In addition, DSA and Diffie-Hellman also have the need to name a group.  This is usually done by the Dss-Parms structure and the DomainParameters structure, respectively, (Both structures are defined in RFC 3279, and the were originally defined in RFC 2459.)

> Do we have the same understanding?

Yes.

Russ