ietf-smime
[Top] [All Lists]

Re: New way of transporting certificates

1998-03-05 15:48:10
Jim,

This sounds good to me, but I have two comments:

1) What goes in the messageDigest attribute in the authenticatedAttributes?
Normally this is the digest of the content, but in your proposal there would
be no content.  Do we want to make a special rule that the messageDigest
attribute is omitted or do we want to say that some special value is
included in messageDigest?

2) You said "If you can form a chain to a trusted root, then don't use this
information..."  Do you mean: "If you can't form a chain to a trusted root,
then don't use this information..."???

- John Pawling


At 01:22 PM 3/5/98 -0800, Jim Schaad (Exchange) wrote:
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






<Prev in Thread] Current Thread [Next in Thread>