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

[Russ Housley <[e-mail]>]

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.
>>> 
>>>> 
>>>> 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?
>>> 
>>> 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.
>> 
>> Okay.  That means that id-ecPublicKey would appear many times, once for each
>> curve.  Can we add text to say that?
> 
> 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?

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