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

[Russ Housley <[e-mail]>]

Hendrik:

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

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