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