Internet Draft Jim Schaad draft-ietf-smime-certdist-03.txt Microsoft February 25, 1999 Expires in six months Certificate Distribution Specification Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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), ftp.ietf.org (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 with the single word "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 interoperability. 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. SMimeEncryptCerts 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 SMimeEncryptCerts 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 SMimeEncryptCerts attribute are: id-aa-smimeEncryptCerts OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-aa(2) 13 } SMimeEncryptCert ::= SEQUENCE { hash Hash, capabilities SMIMECapabilities } SMimeEncryptCerts ::= SEQUENCE OF SmimeEncryptCert Hash ::= OCTET STRING - SHA1 hash of the certificate When a certificate appears in an SMimeEncryptCerts attribute, the certificate MUST be included SignedData object. The order of certificates in the SMimeEncryptCerts 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 SMimeEncryptCerts attribute. If present, the SMimeEncryptCerts 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 SMimeEncryptCerts attribute. CMS defines the ASN.1 syntax for the authenticated attributes to include attrValues SET OF AttributeValue. A SMimeEncryptCerts 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) 3) 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.) 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 content. 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 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 with failure. 4. Validate the referenced 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. 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 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. 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 SMimeCertDistributionSyntax { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) } DEFINITIONS IMPLICIT TAGS ::= BEGIN -- EXPORTS All -- The types and values defined in this module are exported for use -- in the other ASN.1 modules. Other applications may use them for -- their own purposes. IMPORTS -- SMime Cryptographic Message Format ContentInfo FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) } -- SecureMimeMessageV3 SMIMECapabilities FROM SecureMimeMessageV3 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) smime(4)}; -- S/MIME Object Identifier Registry id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) } -- Authenticated Attribute identifing Encryption Certificates -- Value is a single SMimeEncryptCerts id-aa-smimeEncryptCerts OBJECT IDENTIFIER ::= { id-smime id-aa(2) 13 } SMimeEncryptCerts ::= SEQUENCE OF SMimeEncryptCert SMimeEncryptCert ::= SEQUENCE { hash Hash, capabilities SMIMECapabilities } Hash ::= OCTET STRING -- SHA1 hash of the certificate -- Content Type of Certificate publish message. -- Signed content is detatched and empty id-ct-publishCert OBJECT IDENTIFIER ::= { id-smime id-ct(1) 3 } SMimeCertificatePublish ::= ContentInfo END -- of SMimeCertDistributionSyntax 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. Microsoft has also produced an early version of the SMimeEncryptCerts attribute. The syntax for this structure is id-Microsoft-SMimeEncryptCert OBJECT IDENTIFIER ::= {1 3 6 1 4 1 311 16 4} Microsoft-SMimeEncryptionert ::= IssuerAndSerialNumber A description of IssuerAndSerialNumber can be find in [CMS]. 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 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, jimsch@microsoft.com Intended usage: COMMON D. Open Issues - Need Example Message 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