Internet Draft                                                Jim Schaad
draft-ietf-smime-certdist-02.txt                               Microsoft
July 6,
October 12, 1998
Expires in six months

               Certificate Distribution Specification

Status of this memo

  This document is an Internet-Draft. Internet-Drafts are working
  documents of the Internet Engineering Task Force (IETF), its areas,
  and its working groups. Note that other groups may also distribute
  working documents as Internet-Drafts.

  Internet-Drafts are draft documents valid for a maximum of six months
  and may be updated, replaced, or obsoleted by other documents at any
  time. It is inappropriate to use Internet-Drafts as reference material
  or to cite them other than as "work in progress."

  To learn the current status of any Internet-Draft, please check the
  "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  Directories on (Africa), (Europe), (Pacific Rim), (US East Coast), or (US West Coast).


  Current methods of publishing certificates in directory services are
  restricted to just certificates.  This document provides a method of
  publishing certificates with secondary support information such as the
  SMimeCapabilities attribute (containing bulk algorithm support) in a
  way that is both authenticated and bound to a given certificate.

  This draft is being discussed on the "ietf-smime" 'ietf-smime' mailing list.  To
  join the list, send a message to <> with the
  single word "subscribe" 'subscribe' in the body of the message.  Also, there is a
  Web site for the mailing list at <>.

1.   Introduction

  This document discusses a new method of publishing certificates in a
  directory to provide authenticated attributes as part of the
  certificate publishing process.  This allows for the addition of
  information such as the SMimeCapabilities attribute from [SMIME] which
  contains information about the bulk encryption algorithms supported by
  the End-Entity's cryptography module.

  Section 2 discusses the current set of publishing methods available
  for use, along with the benefits and restrictions of each method.
  Section 3 covers the definition and properties of a
  SMimeCertificatePublish object.

  Throughout this draft, the terms MUST, MUST NOT, SHOULD, and SHOULD
  NOT are used in capital letters. This conforms to the definitions in
  [MUSTSHOULD]. [MUSTSHOULD] defines the use of these key words to help
  make the intent of standards track documents as clear as possible. The
  same key words are used in this document to help implementers achieve

2.   Current Publishing Methods

  There are several different ways to publish certificate information.
  These methods include the userCertificate property in LDAP
  directories, sending signed objects between users, and transport of
  certificate files (either bare or as CMS degenerate signed objects).
  Each of these methods has benefits and drawbacks.  Each of these
  methods will now be briefly discussed.

  A public directory may be used to distribute certificates.  LDAP
  currently has the userCertificate property defined just for that
  purpose.  The benefits of using a public directory are that a sender
  may create an encrypted object for a recipient without first receiving
  information (such as a signed message) from the recipient. Most public
  directories currently only contain leaf certificates for individuals
  in the directory entry for the individual.  While some directories,
  such as X.500 directories, provide for a directory entry to contain
  the CA certificate, this is not the case for all directories.  Outside
  of the structure of an X.500 directory the problems associated with
  chaining from the individual's certificate to the CA's directory entry
  in order to obtain it's certificate is difficult to impossible.  This
  leads to two drawbacks: First, the set of bulk algorithms supported by
  the recipient is unknown.  Second, no additional certificates may be
  carried which would help in validating the recipient's certificates.

  Using certificate files for certificate distribution has the benefit
  of already being in wide spread use. (They are commonly used for
  certificate distribution from Certificate Authorities either as part
  of the enrollment protocol or from web based repositories.) The
  degenerate CMS signed object form, certificate files may carry a set
  of certificates to allow a sender to validate the recipients
  certificates.  However, they suffer from two drawbacks.  First, as
  with the public directory, the additional information is not available
  as part of the certificate file.  Second, the certificate is obtained
  from either the recipient one is encrypting for or a third party (not
  a directory).

  Using signed objects for certificate distribution has the benefit of
  allowing additional information such as the SMimeCapabilities
  attribute to be carried as part of the package.  It also allows for
  the inclusion of additional certificates to be used in verifying the
  encryption certificate used to build an encrypted object. However, it
  has the drawback that the initialization process is done via a one-on-
  one process.

3.   SMimeEncryptionCerts

  When publishing one's own encryption certificates, it is often
  advisable to publish a wide selection of certificates to insure
  maximum interoperability.  This section describes an attribute that
  may be used to both identify the set of encryption certificates and
  establish the set of bulk encryption algorithms supported by each of
  the certificates.

  The SMimeEncryptionCerts attribute is used to identify one's own
  encryption certificates to the other party.  This attribute is a
  sequence so that more than one encryption certificate can be
  identified in a single SignerInfo object.  Each certificate is then
  given a set of capabilities so senders can identify the correct
  certificate to use for specific capabilities.

  The structure and OID for the SMimeEncryptionCerts attribute are:

       id-aa-smimeEncryptionCerts OBJECT IDENTIFIER ::= { iso(1)
            member-body(2) us(840)
            rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-aa(2) <TBD> 13 }

       SMimeEncryptionCert ::= SEQUENCE {
            hash           Hash,
            capabilities   SMIMECapabilities

       SMimeEncryptionCerts ::= SEQUENCE OF SmimeEncryptionCert SMimeEncryptionCert

       Hash ::= OCTET STRING - SHA1 hash of the certificate

  When a certificate appears in an SMimeEncryptionCerts attribute, the
  certificate MUST be included SignedData object.  The order of
  certificates in the SMimeEncryptionCerts attribute is the preferred
  order of use by the sender.  It is expected that the preferred
  certificate in the SMIMEEncrpytionKeyPreference would be the first
  certificate in the SMimeEncryptionCerts attribute.

  If present, the SMimeEncryptionCerts attribute MUST be an
  authenticated attribute; it MUST NOT be an unauthenticated attribute.
  CMS defines authenticatedAttributes as a SET OF AuthAttribute.  A
  SignerInfo MUST NOT include multiple instances of the
  SMimeEncryptionCerts attribute. CMS defines the ASN.1 syntax for the
  authenticated attributes to include attrValues SET OF AttributeValue.
  A SMimeEncryptionCerts attribute MUST only include a single instance
  of AttributeValue. There MUST NOT be zero or multiple instances of
  AttributeValue present in the attrValues SET OF AttributeValue.

4.   SMimeCertificatePublish Object

  The structure of the SMimeCertificatePublish object is defined in this
  section.  This object has the benefit that it is published into a
  directory service (and thus is available to all parties) and it
  contains a signed object that allows it to carry the additional
  information desired to increase interoperability.

  This section describes the LDAP directory schema, the body content and
  additional restrictions on the attribute and signers of the SignedData
  object used in publishing the user's certificate.

  The ASN definition of a SMimeCertificatePublish object is the same a
  CMS signed object.

  SMimeCertificatePublish ::= ContentInfo

  Where the contentType is id-signed-data and the content is a
  SignedData content.

  A SMimeCertificatePublish object MAY contain multiple SignerInfo
  objects.  Each SignerInfo object is independent.  This document
  imposes no restrictions on attributes that appear in more that one
  SignerInfo object.

4.1  Signed Content

  The SMimeCertificatePublish object is explicitly designed to carry no
  body content.  All information is carried in the signed attribute
  section of the SignerInfo.

  The following object identifier is used to distinguish the content of
  a SMimeCertificatePublish:

  id-ct-publishCert OBJECT IDENTIFIER ::=  { iso(1) member-body(2)
     us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-ct(1)
     <TBD>) 3 }

  When creating a SMimeCertificatePublish object, the eContent of the
  Signed-Data object is omitted and the eContentType OID is set to id-ct-
  id-ct-publishCert.  Note this is different from an empty content,
  which would be represented as an octet string containing zero bytes.
  The hash of the body (used in the id-message-digest attribute) is set
  to the initialization value of the hash function.  (This is expected
  to provide the same result as if you had hashed a body containing
  exactly 0 bytes.)

4.2  Signed Attributes

  The signed attributes section MUST be present in the SignerInfo
  object, and the following signed attributes MUST be present: The
  signing-time attribute (from [CMS]), the SMimeCapabilities and
  SMIMEEncryptionKeyPreference (from [SMIME]).

4.3  CertificateSet

  This draft imposes additional restrictions on the set of certificates
  to be included in the SignedData object beyond those specified in
  [CMS] and [SMIMECERT].  A chain of certificate from the end-entity
  certificate(s) to the root certificate(s) MUST be included in the
  CertificateSet. Unlike in S/MIME messages the root certificate MUST be
  included in the CertificateSet. The root certificate is included so
  that end-entities have a better chance of finding and independently
  verifying the trustworthiness of the root certificate based on its

  User agents MUST NOT automatically trust any root certificate found in
  a SMimeCertificatePublish object.

4.4  Signing Certificate

  The SMimeCertificatePublish object MUST be signed by a signing
  certificate associated with the end-entity, or a signing certificate
  of a CA in the validation path of the encryption certificate.

  Part of the process of extracting certificates involves comparing the
  certificate found to the address matching the directory look-up.  The
  validation SHOULD match the address used to look up the certificate
  with one of the names found in the certificate.  Thus if an RFC822
  name was used to do the directory look-up, the RFC822 name would be in
  the SubjectAltName extension on the certificate.

  The steps for extracting the encryption certificate from a
  SMimeCertificatePublish object are as follows:

  1. Verify that the SMimeCertificatePublish object contains a valid
     signature and the certificate used to sign the message can be
     a) Certificate validates -- goto 2.
     b) Certificate fails validation -- stop.

  2. Does the certificate used to sign the SMimeCertificatePublish
     object "match" the intended recipient of the encryption object.  If so,
    proceed to step 6 else
     a) "Match" found -- goto step 3. 6.
     b) No "Match" found -- stop.

  3. Does the certificate referenced in the SMIMEEncryptionKeyPreference
     attribute "match" the intended recipient of the encryption object?  If
    so, proceed to
     a) "Match" found -- goto step 4, else 4.
     b) No "Match" found -- stop.

  4. Validate the reference encryption certificate.
     a) Validation succeedes -- goto step 5
     b) Validation fails -- stop.

  5. Compare the signing certificate to the set of certificates used to
     verify the encryption certificate.  Is the signing certificate in
     the set of verification certificates?  If yes then the encryption
     certificate has been located.  If no, no encryption certificate was

  6. Locate the encryption certificate using the
     SMIMEEncryptionKeyPreference attribute in the signed attributes of
     the SMimeCertificatePublish object.

  In all cases, once an encryption certificate has been obtained, the
  standard methods of validating signatures on the certificate and
  checking for revocation MUST be followed.

4.5  LDAP Schema

  After a SignedData object has been produced, it needs to be published
  into one or more directories. This section describes the LDAP schema
  used to support this.

  A new LDAP attribute userSMimeCertificate is defined by this document.
  The attribute is defined according to the syntax provided in [LDAPV3].
  The definition of this attribute is:

  ( 1 2 840 113549 1 9 16 <TBD>
    NAME    `userSMimeCertificate'
    SYNTAX  `binary'
    USAGE userApplications

  If the CA is the only entity that can write to the directory, it may
  wish to provide some mechanism for updating the attributes such as the
  smimeUserCapabilities in the published object.

4.6  MIME Encoding

  The application/pkcs7-mime-publish type is used to carry
  SMimeCertificatePublish objects as mime objects.  The optional "name"
  parameter SHOULD be emitted as part of the Content-Type field.  The
  file extension for the file name SHOULD be ". p7p".

A.   ASN Module
  To be supplied


    Cryptographic Message Syntax (CMS)
      FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840)
      rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) CMS(1) };

  SMIMECapability ::= SEQUENCE {
   parameters ANY DEFINED BY capabilityID OPTIONAL }

  SMIMECapabilities ::= SEQUENCE OF SMIMECapability

  id-aa-smimeEncryptionCerts OBJECT IDENTIFIER ::= { iso(1)
      member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16)
      id-aa(2) 13 }

  SMimeEncryptionCert ::= SEQUENCE {
      hash              Hash,
      capabilities      SMIMECapabilities

  SMimeEncrpytionCerts ::= SEQUENCE OF SMimeEncryptionCert

  Hash ::= OCTET STRING        -- SHA1 hash of a certificate

  SMimeCertificatePublish ::= ContentInfo

  id-ct-publishCert OBJECT IDENTIFIER ::= {iso(1) member-body(2)
     us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-ct(1) 3 }


B.   Backwards Compatibility

  The SMimeCertificatePublish object is based on work previously done at
  both Microsoft and Netscape.

  Both of these companies have implemented a version of
  userSMimeCertificate in their mail LDAP directory structures.
  Microsoft has also put the property into its MAPI based directory

  Both companies use a ContentInfo object containing a SignedData object
  with one SignerInfo object.  In both cases however the eContent is
  tagged with id-data not id-ct-publishCert.  The actual content is
  omitted from the SMimeCertificatePublish object.

  In the case of both companies, clients who implement this feature
  require that the end-entity is the signer of the object, the CA is not
  permitted to sign and publish the object.

C.   Registration of MIME

  Subject: Registration of MIME media type application/pkcs7-mime-

  MIME media type name: application

  MIME subtype name: pkcs7-mime-publish

  Required parameters: none
  Optional parameters: name, filename

  Encoding considerations: Will be binary data, therefore should use
  base-64 encoding

  Security considerations: There is no requirement for additional
  security mechanisms to be applied at this level. The required
  mechanisms are designed into the SMimeCertificatePublish content.

  Interoperability considerations: -

  Published specification: this document

  Applications that use this media type: Secure Internet mail and other
  secure data transports.

  Additional information:
    File extension (s): p7p
    Macintosh File Type Code (s): -

  Person and email address to contact for further information:
  Jim Schaad,

  Intended usage: COMMON

D.   Open Issues

  - Currently SMimeCertificatePublish objects contain There are no content.  One
    could make a case that some content, such as a vCard should be allowed. current open issues.

E. Changes

  As stated at the August IETF Working group meeting, I don't see a big win now consider the
  issue on content for this as we are talking an SMimeCertificatePublish object to be closed.
  There has been no communications about publishing in
    directories and the additional information could this being a desired goal or
  suggesting what should be carried in the
    directory itself.
  - I would like included here.

  All attempts to allow for RAs to publish do publishing of
  SMimeCertificatePublish objects into a directory as well.  I don't however see a way (short on behalf of
    adding an extension the end-user are being
  terminated.  The reason for this is two-fold.

  1) There appears to a certificate) be no good way of identifying which allows one RA
     certificates would be allowed to distinguish
    between do the case publishing without the
     introduction of a new certificate extension specifically for that
     purpose.  This is something that I just cannot think of as good at
     this point in time.

  2) Allowing CAs to either directly or indirectly (through an RA signing and publishing
     certificate) do the
    SMimeCertificatePublish object and an arbitrary agent doing so.

E.   Changes

  Add SMimeEncryptionCerts attribute publishing seems must to identify multiple encryption
  certificates and their capabilities.
  Allow multiple SignerInfos liberal.  If this was
     to be in continue then a single SignedData object when
  publishing certificates.
  Clarify that encryption certificates must still good set of restrictions would need to be validated after one
  is found.
     developed as part of the change.

  CMS     "Cryptographic Message Syntax", Internet Draft ietf-draft-
  MUSTSHOULD "Key words for use in RFCs to Indicate Requirement Levels",
          RFC 2119
  LDAPV3  "Lightweight Directory Access Protocol (v3): Attribute Syntax
          Definitions", RFC 2252
  SMIME   "S/MIME Version 3 Message Specification", Internet Draft ietf-
  SMIMECERT    "S/MIME Version 3 Certificate Handling", Internet Draft

Security Considerations
  Something goes here about making sure that you have the correct
  certificate and that no substitutions are done when getting
  certificates and information from the directory service.

Author Address
  Jim Schaad
  One Microsoft Way
  Redmond, WA 98052-6399