Subject: Elliptic Curve Cryptography with PKIX

From: Russ Housley <[email-masked]>
Date: Thu, 13 Apr 2006 19:10:40 -0400

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

---

From: Russ Housley <[email-masked]>
Date: Thu, 20 Apr 2006 16:54:13 -0400

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

---

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 21 Apr 2006 19:13:01 +0100

I share the concerns regarding the proposed approach in
draft-ietf-pkix-ecc-pkalgs-02.

Even if the structure of parameters provided in SubjectPublicKeyInfo is
define by the Algorithm OID; I still view this as a stretch of semantics
that doesn't follow the intent of X.509 (nor RFC 3280).

4.1.2.7  Subject Public Key Info

   This field is used to carry the public key and identify the algorithm
   with which the key is used (e.g., RSA, DSA, or Diffie-Hellman).  The
   algorithm is identified using the AlgorithmIdentifier structure
   specified in section 4.1.1.2.

The main concern is that the proposed structure introduces a completely
new way to determine and constrain algorithms and assumes it to be legal
to defer specification of algorithm(s) to the parameter part.

This opens up a whole range of new concerns and decision points for
applications that are quite complex to implement and test. Especially
when an application need to consider the intersection between what the
certificate defines, what is defined in a protocol being used and what
is configured in the local platform.

I believe we need to be very restrictive to propose use of algorithm
OIDs within the PKIX profiles that goes beyond defining the syntax and
semantics of the key and its parameters.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Russ Housley
> Sent: den 20 april 2006 13:54
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Elliptic Curve Cryptography with PKIX
> 
>