[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Straw poll for Algorithm Identifiers in Subject Public Key Info.
Is KDF an appropriate level of granularity for certificate-based
constraints on the usage of public keys? And if so, is it
cryptographically appropriate to use a single public key size
with both SHA-256 and SHA-384 KDFs?
Specifying a list of allowed features does not satisfy the design
team's goal of using certificates to reduce protocol negotiation -
if more than one KDF is possible with a pair of peer certificates,
it is still necessary to negotiate which KDF to use.
But to answer the question, the design team slides stated:
* Define an optionally critical certificate extension
- Sequence of Algorithm Identifiers, as in X9.62 parameters
- Reuse X9 algorithm Identifiers
. Deprecating "with recommended"?
- Add three "family" OIDs (ECDSA, ECDH, ECMQV)
So the extension approach allows a list of KDFs, but the RFC 4055
approach does not. I believe that a list is unnecessary because
an ECMQV public key of a given size should imply the acceptable
KDF size (or conversely, a key derive function should imply the
acceptable public key size).
Dave
________________________________________
From: Daniel Brown [mailto:DBrown@xxxxxxxxxxxx]
Sent: Tuesday, January 16, 2007 4:03 PM
To: Kemp, David P.
Cc: ietf-pkix@xxxxxxx
Subject: RE: Straw poll for Algorithm Identifiers in Subject Public Key Info.
David P. Kemp wrote on 01/16/2007 12:21:27 PM:
>
> > - The structured algorithm OID is maybe not the hardest to define
> > but the worse alternative in every other aspect.
>
> Agree.
>
Suppose that a subject has an ECMQV-only cert, and wishes to allow either SHA-256 or SHA-384 based KDFs, but no other KDFs. Also, the EKU field says that the cert can be used for SMIME, IPSec, SSH, or TLS (suppose the private key is on the user's smart card). The X9.62 "structured" approach allows for this. How would the other approaches allow for this?
Regards,
Dan Brown
(905) 501-3857
http://www.certicom.com