RE: Elliptic Curve Cryptography with PKIX

[Daniel Brown <DBrown@xxxxxxxxxxxx>]

Jim,

X9 never vote against it.  As I
understand it, X9 now forbids using the same key both for signing and for
key agreement.  Otherwise, X9 allows use of the same key for multiple
key agreement algorithms, or multiple signing algorithms (e.g. ECDSA with
different hashes).  

By the way, as I understand from Russ's
email, in RFC 4055, IETF is still allowing multiple algorithms to be used
with a single RSA public key, even for both signing and encryption (although
there key usage extension can be used to indicate not to do this).

Perhaps the following may explain X9's
approach.  X9.63-2001, the ECC key establishment standard which is
the basis for NIST SP 800-56A, has some 14 different key establishment
schemes, each with a few different options for key confirmation. I anticipate
that the upcoming revision of X9.63 will multiply the number of options
by a factor for the number of hash function options, and possible the number
of key derivation options, and possibly the number of key wrap options.
 It might be a nuissance to have a separate cert (and public key)
for each configuration.  A syntax to specify a subset of the algorithms
in a single cert is useful.

Thanks,

Dan Brown
(905) 501-3857
http://www.certicom.com

Jim Schaad wrote on 04/21/2006 12:41:45 PM:

> Robert,
>  
> does the X9 group really think that the same
public key should be 
> used for multiple algorithms?
>  
> jim
> 
> From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> On Behalf Of Robert Zuccherato
> Sent: Friday, April 21, 2006 6:45 AM
> To: 'Russ Housley'; ietf-pkix@xxxxxxx
> Cc: DBrown@xxxxxxxxxxxx
> Subject: RE: Elliptic Curve Cryptography with PKIX

> Russ; 
> Since X9.62-2005 is a published standard and
is using the algorithm 
> identifier parameters to list the allowed algorithms, I believe that
> we should follow their lead.  I do not think that having 
> incompatible specifications is in anyone's best interests.
>         Robert Zuccherato.

> > -----Original Message----- 
> > From: owner-ietf-pkix@xxxxxxxxxxxx 
> > [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Russ Housley
> > Sent: April 20, 2006 4:54 PM 
> > To: ietf-pkix@xxxxxxx 
> > Cc: DBrown@xxxxxxxxxxxx 
> > 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 
> >