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

[Russ Housley <[e-mail]>]

Hendrik:

>>> 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 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.

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.)

> - 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?

Yes.

Russ