Jim,
I like this proposition. I feel that S/MIMECapabilities and
PreferedEncryptionKey should play a much more important role. They are
necessary in a multi vendor environment, where products with strong
cryptography and others , which are cryptographically crippled by US export
restrictions, have to interoperate.
Ludwig Wiechers
Siemens Nixdorf, Munich, Germany
----------
Von: Jim Schaad
(Exchange)[SMTP:jimsch(_at_)EXCHANGE(_dot_)MICROSOFT(_dot_)com]
Gesendet: Donnerstag, 5. März 1998 22:22
An: Ietf-Smime (E-mail)
Betreff: New way of transporting certificates
I would like to propose to the working group a new way of carrying
certificates between clients (as an export/import mechinism) and for storage
in directory services (such as LDAP). The current mechinism are lacking in
that they have no way to convey certian fields which are desirable. One
such field is the SMIMECapabilities of a user. As I am not a believer in
inventing new things which I don't have to, I am followin the PKCS #7 certs
only format as a basis.
Define a new content type id-smime-certs-only.
Construct a CMS SignedData message the the following:
1. Inner content type is id-smime-certs-only
2. Inner content is NULL (i.e. no content).
3. One optional SignerInfo may be placed in the message. This SignerInfo
MUST be signed by the end-entity certificate.
4. If the optional SignerInfo is used, then authenticated attributes
such as SMIMECapabilities and PreferedEncryptionKey may be placed here and
would be evaluated in a normal manner of receiving an signed message from
the user.
5. Standard verification rules apply. If you can form a chain to a
trusted root, then don't use this information (just like a plain certs only
PKCS #7 message).
Comments?
jim