One document matched: draft-ietf-smime-certdist-00.txt

Internet Draft                                                 Jim Schaad
draft-ietf-smime-certdist-00.txt                                Microsoft
May 28, 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 ftp.is.co.za
  (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific
  Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US
  West Coast).
     
Abstract
     
  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" mailing
  list.  To join the list, send a message to <ietf-smime-
  request@imc.org> with the single word "subscribe" in the
  body of the message.  Also, there is a Web site for the
  mailing list at <http://www.imc.org/ietf-smime>.

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 interoperability.
     

2.   Current Publishing Methods

  At the present time 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 impossible1.  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.) In 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
  basically done via a one-on-one process.

3.   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 MUST contain exactly one
  SignerInfo object.

3.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>)
  
  When creating a SMimeCertificatePublish object, the
  eContent of the Signed-Data object is omitted and the
  eContentType oid is set to 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.)

3.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])
  and the SMimeCapabilities and SMIMEEncryptionKeyPreference
  (from [SMIME]).

3.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
  content.
  
  User agents MUST NOT automatically trust any root
  certificate found in a SMimeCertificatePublish object.
     

3.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.
  
  Thus 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 validated.
  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 step 3.
  3.   Does the certificate referenced in the
    SMIMEEncryptionKeyPreference attribute "match" the intended
    recipient of the encryption object?  If so proceed to step
    4, else stop.
  4.   Validate the reference encryption certificate.
  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 found.
  6.   Locate the encryption certificate using the
    SMimeEncryptionKeyPreference attribute in the signed
    attributes of the SMimeCertificatePublish object.


3.5  LDAP Schema

  The SignedData object produced as described in section 3.?
  Needs to be published in a directory for usage by others.
  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'
    MULTI-VALUE
    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.
  

3.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
     
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 schema.
  
  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

  To: ietf-types@iana.org
  Subject: Registration of MIME media type application/pkcs7-
  mime-publish
  
  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 rqeuired 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, jimsch@microsoft.com
  
  Intended usage: COMMON
     
D.   Open Issues

  -    At some level an argument can be made that more than
    one SignerInfo object should be allowed in a
    SMimeCertificatePublish object.  My initial reason for
    making this restriction is that I generally expect signing
    and encryption certificates to come in pairs and thus would
    be matched in a single object.  If we allow for multiple
    SignerInfos then we must define consistency rules about the
    attributes that can appear in the signatures.
  -    Currently SMimeCertificatePublish objects contain no
    content.  One could make a case that some content, such as a
    vCard should be allowed.  I don't see a big win for this as
    we are talking about publishing in directories and the
    additional information could be carried in the directory
    itself.
  -    I would like to allow RAs to publish
    SMimeCertificatePublish objects into a directory as well.  I
    don't however see a way (short of adding an extension to a
    certificate) which allows one to distinguish between the
    case of an RA signing and publishing the
    SMimeCertificatePublish object and an arbitrary agent doing
    so.
  -    The current draft is setup to allow for the publishing
    of a single encryption certificate as part of a directory
    entry.  If one had 2 different encryption certificates then
    both would need to be published in independent
    SMimeCertificatePublish objects.  Does it make sense to
    allow for the publishing of multiple encryption certificates
    within a single object?  If this is allowed how is this
    represented? With a sequence attribute listing all of the
    certificates or by using name matching rules.
          JSP:  I believe that a single
          SMimeCertificatePublish object should be capable
          of including multiple encryption (a.k.a. key
          management) certs.  This strategy can be used to
          minimize the number of objects that need to be
          verified.  I believe that your strategy should
          also allow for
          multiple SMimeCertificatePublish objects to be
          stored in the userSMimeCertificate attribute so
          that various entity can store
          SMimeCertificatePublish objects in the user's
          userSMimeCertificate attribute.
          
          Suggestions on how to accomplish this are welcome.
          I think it is going to require a new attribute,
          should we define a new attribute or expand the
          present one?
     
  -    If multiple certificates are allowed to occur in a
    single SMimeCertificatePublish object, do we need a way to
    represent the fact that different certificates will probably
    need different sets of capabilities?
     
     
References

  CMS     "Cryptographic Message Syntax", Internet Draft
          ietf-draft-smime-cms
  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-draft-smime-msg
  SMIMECERT    "S/MIME Version 3 Certificate Handling",
          Internet Draft ietf-draft-smime-cert
     
     
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
  Microsoft
  One Microsoft Way
  Redmond, WA 98052-6399
  Jimsch@Microsoft.com