Subject: RE: Elliptic Curve Cryptography with PKIX

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 21 Apr 2006 13:13:52 -0700

The list approach appears to be a somewhat aggressive approach.

I really do not feel like being aggressive in the area of binding keys to
algorithms, particularly not at this stage in the proceedings and
particularly not when the only benefit on offer seems to be comptibility
with another document. 

I especially do not feel like taking a more aggressive approach with ECC
crypto than we feel comfortable with for RSA.

The upside appears to be negligible, the potential downside is we have
fallen and can't get up, oh and the WG has been disbanded so there is no
quick fix.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Russ Housley
> Sent: Thursday, April 20, 2006 4:54 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Elliptic Curve Cryptography with PKIX
> 
> 
> This message stimulated an off-list discussion between a 
> small group, and I think that it is time to bring the core 
> issue to the whole PKIX list.
> 
> Recent updates to ANSI X9.62 and X9.63 are making use of the 
> subject public key info algorithm identifier parameters to 
> list the ECC algorithms with which the certified public key 
> is allowed to be used.  I greatly prefer the approach used in 
> RFC 4055 to bind a particular public key to a particular 
> algorithm.  What do others think?
> 
> Russ
> 
> At 07:10 PM 4/13/2006, Russ Housley wrote:
> >I just realized that draft-ietf-pkix-ecc-pkalgs-02.txt is handling 
> >algorithm constraints in a different manner than RFC 4055.  I would 
> >really like to see PKIX use a single approach throughout the 
> set of documents.
> >
> >In RFC 4055, the security considerations say:
> >
> >    Generally, good cryptographic practice employs a given 
> RSA key pair
> >    in only one scheme.  This practice avoids the risk that 
> vulnerability
> >    in one scheme may compromise the security of the other, 
> and may be
> >    essential to maintain provable security.  While PKCS #1 
> Version 1.5
> >    [P1v1.5] has been employed for both key transport and digital
> >    signature without any known bad interactions, such a 
> combined use of
> >    an RSA key pair is not recommended in the future.  
> Therefore, an RSA
> >    key pair used for RSASSA-PSS signature generation should 
> not be used
> >    for other purposes.  For similar reasons, one RSA key pair should
> >    always be used with the same RSASSA-PSS parameters 
> (except possibly
> >    for the salt length).  Likewise, an RSA key pair used 
> for RSAES-OAEP
> >    key transport should not be used for other purposes.  For similar
> >    reasons, one RSA key pair should always be used with the 
> same RSAES-
> >    OAEP parameters.
> >
> >Due to these concerns, RFC 4055 specifies more than one different 
> >algorithm identifier to be carried in the subject public key 
> algorithm 
> >identifier.
> >
> >The rsaEncryption object identifier continues to identify 
> the subject 
> >public key when the RSA private key owner does not wish to limit the 
> >use of the public key exclusively to either RSASSA-PSS or 
> RSAES-OAEP.  
> >This is the one that is used with PKCS#1 v1.5.
> >
> >When the RSA private key owner wishes to limit the use of the public 
> >key exclusively to RSASSA-PSS, then the id-RSASSA-PSS object 
> identifier 
> >MUST be used in the algorithm field within the subject public key 
> >algorithm identifier.
> >
> >When the RSA private key owner wishes to limit the use of the public 
> >key exclusively to RSAES-OAEP, then the id-RSAES-OAEP object 
> identifier 
> >MUST be used in the algorithm field within the subject public key 
> >algorithm identifier.
> >
> >draft-ietf-pkix-ecc-pkalgs-02.txt advocates a very different 
> approach.  
> >It uses the algorithm identifier parameters to list the 
> algorithms that 
> >can employ the ECC public key.  Listing multiple leads to 
> the concerns 
> >discussed in the RFC 4055 security considerations, so I 
> would prefer to 
> >follow the same approach as RFC 4055.
> >
> >In the case of ECC, that would mean using id-ecPublicKey 
> when ane ECC 
> >algorithm can be used, and using a specific algorithm OID when one 
> >wants select a single one.
> >
> >The only weird thing in the ECC space is ECMQV.  We may want 
> to assign 
> >an OID for any of the variants (1-pass and 2-pass come to mind).
> >
> >Russ
> 
> 
>