The fact that you can put
the info into a cert does not mean that the whole system will do what you want.
We are dealing with a field that historically has not been used
to carry such information and where it will be a challenge make sure they will
act in a “good” manner if they do. The situation is different for
private key operations protected by a smart card than using the public key from
a certificate. Both sides need to honor the restriction.
Stefan Santesson
Senior Program Manager
Windows Security, Standards
From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx]
On Behalf Of Daniel Brown
Sent: den 16 januari 2007 13:03
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