draft-ietf-smime-certdist-00.txt   draft-ietf-smime-certdist-01.txt 
Internet Draft Jim Schaad Internet Draft Jim Schaad
draft-ietf-smime-certdist-00.txt Microsoft draft-ietf-smime-certdist-01.txt Microsoft
May 28, 1998 July 6, 1998
Expires in six months Expires in six months
Certificate Distribution Specification Certificate Distribution Specification
Status of this memo Status of this memo
This document is an Internet-Draft. Internet-Drafts are This document is an Internet-Draft. Internet-Drafts are working
working documents of the Internet Engineering Task Force documents of the Internet Engineering Task Force (IETF), its areas,
(IETF), its areas, and its working groups. Note that other and its working groups. Note that other groups may also distribute
groups may also distribute working documents as Internet- working documents as Internet-Drafts.
Drafts.
Internet-Drafts are draft documents valid for a maximum of Internet-Drafts are draft documents valid for a maximum of six months
six months and may be updated, replaced, or obsoleted by and may be updated, replaced, or obsoleted by other documents at any
other documents at any time. It is inappropriate to use time. It is inappropriate to use Internet-Drafts as reference material
Internet-Drafts as reference material or to cite them or to cite them other than as "work in progress."
other than as "work in progress."
To learn the current status of any Internet-Draft, please To learn the current status of any Internet-Draft, please check the
check the "1id-abstracts.txt" listing contained in the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Internet-Drafts Shadow Directories on ftp.is.co.za Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
(Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US ftp.isi.edu (US West Coast).
West Coast).
Abstract Abstract
Current methods of publishing certificates in directory Current methods of publishing certificates in directory services are
services are restricted to just certificates. This restricted to just certificates. This document provides a method of
document provides a method of publishing certificates with publishing certificates with secondary support information such as the
secondary support information such as the SMimeCapabilities attribute (containing bulk algorithm support) in a
SMimeCapabilities attribute (containing bulk algorithm way that is both authenticated and bound to a given certificate.
support) in a way that is both authenticated and bound to
a given certificate.
This draft is being discussed on the "ietf-smime" mailing This draft is being discussed on the "ietf-smime" mailing list. To
list. To join the list, send a message to <ietf-smime- join the list, send a message to <ietf-smime-request@imc.org> with the
request@imc.org> with the single word "subscribe" in the single word "subscribe" in the body of the message. Also, there is a
body of the message. Also, there is a Web site for the Web site for the mailing list at <http://www.imc.org/ietf-smime>.
mailing list at <http://www.imc.org/ietf-smime>.
1. Introduction 1. Introduction
This document discusses a new method of publishing This document discusses a new method of publishing certificates in a
certificates in a directory to provide authenticated directory to provide authenticated attributes as part of the
attributes as part of the certificate publishing process. certificate publishing process. This allows for the addition of
This allows for the addition of information such as the information such as the SMimeCapabilities attribute from [SMIME] which
SMimeCapabilities attribute from [SMIME] which contains contains information about the bulk encryption algorithms supported by
information about the bulk encryption algorithms supported the End-Entity's cryptography module.
by the End-Entity's cryptography module.
Section 2 discusses the current set of publishing methods Section 2 discusses the current set of publishing methods available
available for use, along with the benefits and for use, along with the benefits and restrictions of each method.
restrictions of each method. Section 3 covers the Section 3 covers the definition and properties of a
definition and properties of a SMimeCertificatePublish SMimeCertificatePublish object.
object.
Throughout this draft, the terms MUST, MUST NOT, SHOULD, Throughout this draft, the terms MUST, MUST NOT, SHOULD, and SHOULD
and SHOULD NOT are used in capital letters. This conforms NOT are used in capital letters. This conforms to the definitions in
to the definitions in [MUSTSHOULD]. [MUSTSHOULD] defines [MUSTSHOULD]. [MUSTSHOULD] defines the use of these key words to help
the use of these key words to help make the intent of make the intent of standards track documents as clear as possible. The
standards track documents as clear as possible. The same same key words are used in this document to help implementers achieve
key words are used in this document to help implementers interoperability.
achieve interoperability.
2. Current Publishing Methods 2. Current Publishing Methods
At the present time there are several different ways to There are several different ways to publish certificate information.
publish certificate information. These methods include These methods include the userCertificate property in LDAP
the userCertificate property in LDAP directories, sending directories, sending signed objects between users, and transport of
signed objects between users, and transport of certificate certificate files (either bare or as CMS degenerate signed objects).
files (either bare or as CMS degenerate signed objects). Each of these methods has benefits and drawbacks. Each of these
Each of these methods has benefits and drawbacks. Each of methods will now be briefly discussed.
these methods will now be briefly discussed.
A public directory may be used to distribute certificates. A public directory may be used to distribute certificates. LDAP
LDAP currently has the userCertificate property defined currently has the userCertificate property defined just for that
just for that purpose. The benefits of using a public purpose. The benefits of using a public directory are that a sender
directory are that a sender may create an encrypted object may create an encrypted object for a recipient without first receiving
for a recipient without first receiving information (such information (such as a signed message) from the recipient. Most public
as a signed message) from the recipient. Most public directories currently only contain leaf certificates for individuals
directories currently only contain leaf certificates for in the directory entry for the individual. While some directories,
individuals in the directory entry for the individual. such as X.500 directories, provide for a directory entry to contain
While some directories, such as X.500 directories, provide the CA certificate, this is not the case for all directories. Outside
for a directory entry to contain the CA certificate, this of the structure of an X.500 directory the problems associated with
is not the case for all directories. Outside of the chaining from the individual's certificate to the CA's directory entry
structure of an X.500 directory the problems associated in order to obtain it's certificate is difficult to impossible. This
with chaining from the individual's certificate to the leads to two drawbacks: First, the set of bulk algorithms supported by
CA's directory entry in order to obtain it's certificate the recipient is unknown. Second, no additional certificates may be
is difficult to impossible1. This leads to two drawbacks: carried which would help in validating the recipient's certificates.
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 Using certificate files for certificate distribution has the benefit
the benefit of already being in wide spread use. (They are of already being in wide spread use. (They are commonly used for
commonly used for certificate distribution from certificate distribution from Certificate Authorities either as part
Certificate Authorities either as part of the enrollment of the enrollment protocol or from web based repositories.) The
protocol or from web based repositories.) In the degenerate CMS signed object form, certificate files may carry a set
degenerate CMS signed object form, certificate files may of certificates to allow a sender to validate the recipients
carry a set of certificates to allow a sender to validate certificates. However, they suffer from two drawbacks. First, as
the recipients certificates. However they suffer from two with the public directory, the additional information is not available
drawbacks. First, as with the public directory, the as part of the certificate file. Second, the certificate is obtained
additional information is not available as part of the from either the recipient one is encrypting for or a third party (not
certificate file. Second, the certificate is obtained a directory).
from either the recipient one is encrypting for or a third
party (not a directory).
Using signed objects for certificate distribution has the Using signed objects for certificate distribution has the benefit of
benefit of allowing additional information such as the allowing additional information such as the SMimeCapabilities
SMimeCapabilities attribute to be carried as part of the attribute to be carried as part of the package. It also allows for
package. It also allows for the inclusion of additional the inclusion of additional certificates to be used in verifying the
certificates to be used in verifying the encryption encryption certificate used to build an encrypted object. However, it
certificate used to build an encrypted object. However, it has the drawback that the initialization process is done via a one-on-
has the drawback that the initialization process is one process.
basically done via a one-on-one process.
3. SMimeCertificatePublish Object 3. SMimeEncryptionCerts
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 When publishing one's own encryption certificates, it is often
content and additional restrictions on the attribute and advisable to publish a wide selection of certificates to insure
signers of the SignedData object used in publishing the maximum interoperability. This section describes an attribute that
user's certificate. 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 ASN definition of a SMimeCertificatePublish object is The SMimeEncryptionCerts attribute is used to identify one's own
the same a CMS signed object. 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> }
SMimeEncryptionCert ::= SEQUENCE {
hash Hash,
capabilities SMIMECapabilities
}
SMimeEncryptionCerts ::= SEQUENCE OF 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 SMimeCertificatePublish ::= ContentInfo
Where the contentType is id-signed-data and the content is Where the contentType is id-signed-data and the content is a
a SignedData content. SignedData content.
A SMimeCertificatePublish object MUST contain exactly one 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. SignerInfo object.
3.1 Signed Content 4.1 Signed Content
The SMimeCertificatePublish object is explicitly designed The SMimeCertificatePublish object is explicitly designed to carry no
to carry no body content. All information is carried in body content. All information is carried in the signed attribute
the signed attribute section of the SignerInfo. section of the SignerInfo.
The following object identifier is used to distinguish the The following object identifier is used to distinguish the content of
content of a SMimeCertificatePublish: a SMimeCertificatePublish:
id-ct-publishCert OBJECT IDENTIFIER ::= { iso(1) member- id-ct-publishCert OBJECT IDENTIFIER ::= { iso(1) member-body(2)
body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-ct(1) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-ct(1)
<TBD>) <TBD>)
When creating a SMimeCertificatePublish object, the When creating a SMimeCertificatePublish object, the eContent of the
eContent of the Signed-Data object is omitted and the Signed-Data object is omitted and the eContentType OID is set to id-ct-
eContentType oid is set to id-ct-publishCert. Note this publishCert. Note this is different from an empty content, which
is different from an empty content, which would be would be represented as an octet string containing zero bytes. The
represented as an octet string containing zero bytes. The hash of the body (used in the id-message-digest attribute) is set to
hash of the body (used in the id-message-digest attribute) the initialization value of the hash function. (This is expected to
is set to the initialization value of the hash function. provide the same result as if you had hashed a body containing exactly
(This is expected to provide the same result as if you had 0 bytes.)
hashed a body containing exactly 0 bytes.)
3.2 Signed Attributes 4.2 Signed Attributes
The signed attributes section MUST be present in the The signed attributes section MUST be present in the SignerInfo
SignerInfo object, and the following signed attributes object, and the following signed attributes MUST be present: The
MUST be present: The signing-time attribute (from [CMS]) signing-time attribute (from [CMS]), the SMimeCapabilities and
and the SMimeCapabilities and SMIMEEncryptionKeyPreference SMIMEEncryptionKeyPreference (from [SMIME]).
(from [SMIME]).
3.3 CertificateSet 4.3 CertificateSet
This draft imposes additional restrictions on the set of This draft imposes additional restrictions on the set of certificates
certificates to be included in the SignedData object to be included in the SignedData object beyond those specified in
beyond those specified in [CMS] and [SMIMECERT]. A chain [CMS] and [SMIMECERT]. A chain of certificate from the end-entity
of certificate from the end-entity certificate(s) to the certificate(s) to the root certificate(s) MUST be included in the
root certificate(s) MUST be included in the CertificateSet. Unlike in S/MIME messages the root certificate MUST be
CertificateSet. Unlike in S/MIME messages the root included in the CertificateSet. The root certificate is included so
certificate MUST be included in the CertificateSet. The that end-entities have a better chance of finding and independently
root certificate is included so that end-entities have a verifying the trustworthiness of the root certificate based on its
better chance of finding and independently verifying the
trustworthiness of the root certificate based on its
content. content.
User agents MUST NOT automatically trust any root User agents MUST NOT automatically trust any root certificate found in
certificate found in a SMimeCertificatePublish object. a SMimeCertificatePublish object.
3.4 Signing Certificate 4.4 Signing Certificate
The SMimeCertificatePublish object MUST be signed by a The SMimeCertificatePublish object MUST be signed by a signing
signing certificate associated with the end-entity, or a certificate associated with the end-entity, or a signing certificate
signing certificate of a CA in the validation path of the of a CA in the validation path of the encryption certificate.
encryption certificate.
Part of the process of extracting certificates involves Part of the process of extracting certificates involves comparing the
comparing the certificate found to the address matching certificate found to the address matching the directory look-up. The
the directory look-up. The validation SHOULD match the validation SHOULD match the address used to look up the certificate
address used to look up the certificate with one of the with one of the names found in the certificate. Thus if an RFC822
names found in the certificate. Thus if an RFC822 name name was used to do the directory look-up, the RFC822 name would be in
was used to do the directory look-up, the RFC822 name the SubjectAltName extension on the certificate.
would be in the SubjectAltName extension on the
certificate.
Thus the steps for extracting the encryption certificate The steps for extracting the encryption certificate from a
from a SMimeCertificatePublish object are as follows: SMimeCertificatePublish object are as follows:
1. Verify that the SMimeCertificatePublish object contains 1. Verify that the SMimeCertificatePublish object contains a valid
a valid signature and the certificate used to sign the signature and the certificate used to sign the message can be validated.
message can be validated. 2. Does the certificate used to sign the SMimeCertificatePublish
2. Does the certificate used to sign the object "match" the intended recipient of the encryption object. If so,
SMimeCertificatePublish object "match" the intended proceed to step 6 else step 3.
recipient of the encryption object. If so proceed to step 6 3. Does the certificate referenced in the SMIMEEncryptionKeyPreference
else step 3. attribute "match" the intended recipient of the encryption object? If
3. Does the certificate referenced in the so, proceed to step 4, else stop.
SMIMEEncryptionKeyPreference attribute "match" the intended
recipient of the encryption object? If so proceed to step
4, else stop.
4. Validate the reference encryption certificate. 4. Validate the reference encryption certificate.
5. Compare the signing certificate to the set of 5. Compare the signing certificate to the set of certificates used to
certificates used to verify the encryption certificate. Is verify the encryption certificate. Is the signing certificate in the
the signing certificate in the set of verification set of verification certificates? If yes then the encryption
certificates? If yes then the encryption certificate has certificate has been located. If no, no encryption certificate was
been located. If no, no encryption certificate was found. found.
6. Locate the encryption certificate using the 6. Locate the encryption certificate using the
SMimeEncryptionKeyPreference attribute in the signed SMIMEEncryptionKeyPreference attribute in the signed attributes of the
attributes of the SMimeCertificatePublish object. SMimeCertificatePublish object.
3.5 LDAP Schema 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.
The SignedData object produced as described in section 3.? 4.5 LDAP Schema
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 After a SignedData object has been produced, it needs to be published
this document. The attribute is defined according to the into one or more directories. This section describes the LDAP schema
syntax provided in [LDAPV3]. The definition of this used to support this.
attribute is:
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> ( 1 2 840 113549 1 9 16 <TBD>
NAME 'userSMimeCertificate' NAME `userSMimeCertificate'
SYNTAX 'binary' SYNTAX `binary'
MULTI-VALUE MULTI-VALUE
USAGE userApplications USAGE userApplications
) )
If the CA is the only entity that can write to the If the CA is the only entity that can write to the directory, it may
directory, it may wish to provide some mechanism for wish to provide some mechanism for updating the attributes such as the
updating the attributes such as the smimeUserCapabilities smimeUserCapabilities in the published object.
in the published object.
3.6 MIME Encoding 4.6 MIME Encoding
The application/pkcs7-mime-publish type is used to carry The application/pkcs7-mime-publish type is used to carry
SMimeCertificatePublish objects as mime objects. The SMimeCertificatePublish objects as mime objects. The optional "name"
optional "name" parameter SHOULD be emitted as part of the parameter SHOULD be emitted as part of the Content-Type field. The
Content-Type field. The file extension for the file name file extension for the file name SHOULD be ". p7p".
SHOULD be ".p7p".
A. ASN Module A. ASN Module
To be supplied To be supplied
B. Backwards Compatibility B. Backwards Compatibility
The SMimeCertificatePublish object is based on work The SMimeCertificatePublish object is based on work previously done at
previously done at both Microsoft and Netscape. both Microsoft and Netscape.
Both of these companies have implemented a version of Both of these companies have implemented a version of
userSMimeCertificate in their mail LDAP directory userSMimeCertificate in their mail LDAP directory structures.
structures. Microsoft has also put the property into its Microsoft has also put the property into its MAPI based directory
MAPI based directory schema. schema.
Both companies use a ContentInfo object containing a Both companies use a ContentInfo object containing a SignedData object
SignedData object with one SignerInfo object. In both with one SignerInfo object. In both cases however the eContent is
cases however the eContent is tagged with id-data not id- tagged with id-data not id-ct-publishCert. The actual content is
ct-publishCert. The actual content is omitted from the omitted from the SMimeCertificatePublish object.
SMimeCertificatePublish object.
In the case of both companies, clients who implement this In the case of both companies, clients who implement this feature
feature require that the end-entity is the signer of the require that the end-entity is the signer of the object, the CA is not
object, the CA is not permitted to sign and publish the permitted to sign and publish the object.
object.
C. Registration of MIME C. Registration of MIME
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of MIME media type application/pkcs7- Subject: Registration of MIME media type application/pkcs7-mime-
mime-publish publish
MIME media type name: application MIME media type name: application
MIME subtype name: pkcs7-mime-publish MIME subtype name: pkcs7-mime-publish
Required parameters: none Required parameters: none
Optional parameters: name, filename Optional parameters: name, filename
Encoding considerations: Will be binary data, therefore Encoding considerations: Will be binary data, therefore should use
should use base-64 encoding base-64 encoding
Security considerations: There is no requirement for Security considerations: There is no requirement for additional
additional security mechanisms to be applied at this security mechanisms to be applied at this level. The required
level. The rqeuired mechanisms are designed into the mechanisms are designed into the SMimeCertificatePublish content.
SmimeCertificatePublish content.
Interoperability considerations: - Interoperability considerations: -
Published specification: this document Published specification: this document
Applications that use this media type: Secure Internet Applications that use this media type: Secure Internet mail and other
mail and other secure data transports. secure data transports.
Additional information: Additional information:
File extension (s): p7p File extension (s): p7p
Macintosh File Type Code (s): - Macintosh File Type Code (s): -
Person and email address to contact for further Person and email address to contact for further information:
information:
Jim Schaad, jimsch@microsoft.com Jim Schaad, jimsch@microsoft.com
Intended usage: COMMON Intended usage: COMMON
D. Open Issues D. Open Issues
- At some level an argument can be made that more than - Currently SMimeCertificatePublish objects contain no content. One
one SignerInfo object should be allowed in a could make a case that some content, such as a vCard should be allowed.
SMimeCertificatePublish object. My initial reason for I don't see a big win for this as we are talking about publishing in
making this restriction is that I generally expect signing directories and the additional information could be carried in the
and encryption certificates to come in pairs and thus would directory itself.
be matched in a single object. If we allow for multiple - I would like to allow RAs to publish SMimeCertificatePublish
SignerInfos then we must define consistency rules about the objects into a directory as well. I don't however see a way (short of
attributes that can appear in the signatures. adding an extension to a certificate) which allows one to distinguish
- Currently SMimeCertificatePublish objects contain no between the case of an RA signing and publishing the
content. One could make a case that some content, such as a SMimeCertificatePublish object and an arbitrary agent doing so.
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. E. Changes
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 Add SMimeEncryptionCerts attribute to identify multiple encryption
single SMimeCertificatePublish object, do we need a way to certificates and their capabilities.
represent the fact that different certificates will probably Allow multiple SignerInfos to be in a single SignedData object when
need different sets of capabilities? publishing certificates.
Clarify that encryption certificates must still be validated after one
is found.
References References
CMS "Cryptographic Message Syntax", Internet Draft ietf-draft-
CMS "Cryptographic Message Syntax", Internet Draft smime-cms
ietf-draft-smime-cms MUSTSHOULD "Key words for use in RFCs to Indicate Requirement Levels",
MUSTSHOULD "Key words for use in RFCs to Indicate RFC 2119
Requirement Levels", RFC 2119 LDAPV3 "Lightweight Directory Access Protocol (v3): Attribute Syntax
LDAPV3 "Lightweight Directory Access Protocol (v3): Definitions", RFC 2252
Attribute Syntax Definitions", RFC 2252 SMIME "S/MIME Version 3 Message Specification", Internet Draft ietf-
SMIME "S/MIME Version 3 Message Specification", draft-smime-msg
Internet Draft ietf-draft-smime-msg SMIMECERT "S/MIME Version 3 Certificate Handling", Internet Draft
SMIMECERT "S/MIME Version 3 Certificate Handling", ietf-draft-smime-cert
Internet Draft ietf-draft-smime-cert
Security Considerations Security Considerations
Something goes here about making sure that you have the correct
Something goes here about making sure that you have the certificate and that no substitutions are done when getting
correct certificate and that no substitutions are done certificates and information from the directory service.
when getting certificates and information from the
directory service.
Author Address Author Address
Jim Schaad Jim Schaad
Microsoft Microsoft
One Microsoft Way One Microsoft Way
Redmond, WA 98052-6399 Redmond, WA 98052-6399
Jimsch@Microsoft.com Jimsch@Microsoft.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/