draft-ietf-smime-cert-02.txt   draft-ietf-smime-cert-03.txt 
Internet Draft Editor: Blake Ramsdell, Internet Draft Editor: Blake Ramsdell,
draft-ietf-smime-cert-02.txt Worldtalk draft-ietf-smime-cert-03.txt Worldtalk
March 11, 1998 March 24, 1998
Expires in six months Expires in six months
S/MIME Version 3 Certificate Handling S/MIME Version 3 Certificate Handling
Status of this memo Status of this memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress." or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the To view the entire list of current Internet-Drafts, please check
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow the "1id-abstracts.txt" listing contained in the Internet-Drafts
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
ftp.isi.edu (US West Coast). (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
1. Overview 1. Overview
S/MIME (Secure/Multipurpose Internet Mail Extensions), described in S/MIME (Secure/Multipurpose Internet Mail Extensions), described in
[SMIME-MSG], provides a method to send and receive secure MIME [SMIME-MSG], provides a method to send and receive secure MIME
messages. In order to validate the keys of a message sent to it, an messages. Before using a public key to provide security services, the
S/MIME agent needs to certify that the key is valid. This draft S/MIME agent MUST certify that the public key is valid. S/MIME agents
describes the mechanisms S/MIME uses to create and validate keys using MUST use X.509 certificates to validate public keys as described in
certificates. the ITU-T Recommendation X.509 (1997) [X.509] and the Internet Public
Key Infrastructure (PKIX) X.509 Certificate and CRL Profile [KEYM].
S/MIME agents MUST meet the S/MIME-specific requirements documented in
this I-D in addition to those stated in [X.509] and [KEYM].
This specification is compatible with the Cryptographic Message Syntax This specification is compatible with the Cryptographic Message Syntax
[CMS] in that it uses the data types defined by CMS. It also inherits [CMS] in that it uses the data types defined by CMS. It also inherits
all the varieties of architectures for certificate-based key all the varieties of architectures for certificate-based key
management supported by CMS. Note that the method S/MIME messages make management supported by CMS. Note that the method S/MIME messages make
certificate requests is defined in [SMIME-MSG]. certificate requests is defined in [SMIME-MSG].
In order to handle S/MIME certificates, an agent has to follow
specifications in this draft, as well as some of the specifications
listed in the following documents:
- "PKCS #1: RSA Encryption", [PKCS-1].
- "Cryptographic Message Syntax", [CMS].
1.1 Definitions 1.1 Definitions
For the purposes of this draft, the following definitions apply. For the purposes of this draft, the following definitions apply.
ASN.1: Abstract Syntax Notation One, as defined in ITU-T X.680-689. ASN.1: Abstract Syntax Notation One, as defined in ITU-T X.680-689.
Attribute Certificate (AC): An X.509 AC is a separate structure from a Attribute Certificate (AC): An X.509 AC is a separate structure from a
subject's public key X.509 Certificate. A subject may have multiple subject's public key X.509 Certificate. A subject may have multiple
X.509 ACs associated with each of its public key X.509 Certificates. X.509 ACs associated with each of its public key X.509 Certificates.
Each X.509 AC binds a SEQUENCE OF Attributes with one of the subject's Each X.509 AC binds a SEQUENCE OF Attributes with one of the subject's
public key X.509 Certificates. The X.509 AC syntax is defined in public key X.509 Certificates. The X.509 AC syntax is defined in
[X.509] [X.509]
BER: Basic Encoding Rules for ASN.1, as defined in ITU-T X.690. BER: Basic Encoding Rules for ASN.1, as defined in ITU-T X.690.
Certificate: A type that binds an entity's distinguished name to a Certificate: A type that binds an entity's distinguished name to a
public key with a digital signature. This type is defined in ITU-T public key with a digital signature. This type is defined in ITU-T
X.509 [X.509]. This type also contains the distinguished name of the X.509 [X.509]. This type also contains the distinguished name of the
certificate issuer (the signer), an issuer-specific serial number, the certificate issuer (the signer), an issuer-specific serial number, the
issuer's signature algorithm identifier, and a validity period. issuer's signature algorithm identifier, a validity period, and
extensions as defined in [KEYM].
Certificate Revocation List (CRL): A type that contains information Certificate Revocation List (CRL): A type that contains information
about certificates whose validity an issuer has prematurely revoked. about certificates whose validity an issuer has prematurely revoked.
The information consists of an issuer name, the time of issue, the The information consists of an issuer name, the time of issue, the
next scheduled time of issue, and a list of certificate serial numbers next scheduled time of issue, a list of certificate serial numbers and
and their associated revocation times. The CRL is signed by the their associated revocation times, and extensions as defined in
issuer. The type intended by this specification is the one defined in [KEYM]. The CRL is signed by the issuer. The type intended by this
[KEYM]. specification is the one defined in [KEYM].
DER: Distinguished Encoding Rules for ASN.1, as defined in ITU-T DER: Distinguished Encoding Rules for ASN.1, as defined in ITU-T
X.690. X.690.
1.2 Compatibility with Prior Practice of S/MIME 1.2 Compatibility with Prior Practice of S/MIME
Appendix C contains important information about how S/MIME agents S/MIME version 3 agents should attempt to have the greatest
following this specification should act in order to have the greatest interoperability possible with S/MIME version 2 agents. S/MIME version
interoperability with earlier implementations of S/MIME. 2 is described in RFC 2311 through RFC 2315, inclusive. RFC 2311 also
has historical information about the development of S/MIME.
1.3 Terminology 1.3 Terminology
Throughout this draft, the terms MUST, MUST NOT, SHOULD, and SHOULD Throughout this draft, the terms MUST, MUST NOT, SHOULD, and SHOULD
NOT are used in capital letters. This conforms to the definitions in NOT are used in capital letters. This conforms to the definitions in
[MUSTSHOULD]. [MUSTSHOULD] defines the use of these key words to help [MUSTSHOULD]. [MUSTSHOULD] defines the use of these key words to help
make the intent of standards track documents as clear as possible. The make the intent of standards track documents as clear as possible. The
same key words are used in this document to help implementors achieve same key words are used in this document to help implementors achieve
interoperability. interoperability.
skipping to change at line 119 skipping to change at line 119
interoperability among all S/MIME implementations. Most of the CMS interoperability among all S/MIME implementations. Most of the CMS
format for S/MIME messages is defined in [SMIME-MSG]. format for S/MIME messages is defined in [SMIME-MSG].
2.1 CertificateRevocationLists 2.1 CertificateRevocationLists
Receiving agents MUST support for the Certificate Revocation List Receiving agents MUST support for the Certificate Revocation List
(CRL) format defined in [KEYM]. If sending agents include CRLs in (CRL) format defined in [KEYM]. If sending agents include CRLs in
outgoing messages, the CRL format defined in [KEYM] MUST be used. outgoing messages, the CRL format defined in [KEYM] MUST be used.
All agents MUST validate CRLs and check certificates against CRLs, if All agents MUST validate CRLs and check certificates against CRLs, if
available, in accordance with [KEYM]. All agents SHOULD check the available, in accordance with [KEYM].
nextUpdate field in the CRL against the current time. If the current
time is later than the nextUpdate time, the action that the agent
takes is a local decision. For instance, it could warn a human user,
it could retrieve a new CRL if able, and so on.
Receiving agents MUST recognize CRLs in received S/MIME messages. Receiving agents MUST recognize CRLs in received S/MIME messages.
Clients MUST use revocation information included as a CRL in an S/MIME Clients MUST use revocation information included as a CRL in an S/MIME
message when verifying the signature and certificate path validity in message when verifying the signature and certificate path validity in
that message. Clients SHOULD store CRLs received in messages for use that message. Clients SHOULD store CRLs received in messages for use
in processing later messages. in processing later messages.
Clients MUST handle multiple valid Certificate Authority (CA) Clients MUST handle multiple valid Certificate Authority (CA)
certificates containing the same subject name and the same public keys certificates containing the same subject name and the same public keys
but with overlapping validity intervals. but with overlapping validity intervals.
2.2 CertificateChoices 2.2 CertificateChoices
Receiving agents MUST support X.509 v1 and X.509 v3 certificates. See Receiving agents MUST support X.509 v1 and X.509 v3 certificates. See
[KEYM] for details about the profile for certificate formats. End [KEYM] for details about the profile for certificate formats. End
entity certificates MUST include an Internet mail address, as entity certificates MAY include an Internet mail address, as described
described in section 3.1. in section 3.1.
Receiving agents SHOULD support X.509 attribute certificates. Receiving agents SHOULD support X.509 attribute certificates.
2.2.1 Historical Note About CMS Certificates 2.2.1 Historical Note About CMS Certificates
The CMS message format supports a choice of certificate two formats The CMS message format supports a choice of certificate formats for
for public key content types: X.509 and PKCS #6 Extended Certificates. public key content types: X.509, PKCS #6 Extended Certificates and
The PKCS #6 format is not in widespread use. In addition, proposed X.509 Attribute Certificates. The PKCS #6 format is not in widespread
revisions of X.509 certificates address much of the same functionality use. In addition, X.509 v3 certificate extensions address much of the
and flexibility as was intended in the PKCS #6. Thus, sending and same functionality and flexibility as was intended in the PKCS #6.
receiving agents MUST NOT use PKCS #6 extended certificates. Thus, sending and receiving agents MUST NOT use PKCS #6 extended
certificates.
2.3 CertificateSet 2.3 CertificateSet
Receiving agents MUST be able to handle an arbitrary number of Receiving agents MUST be able to handle an arbitrary number of
certificates of arbitrary relationship to the message sender and to certificates of arbitrary relationship to the message sender and to
each other in arbitrary order. In many cases, the certificates each other in arbitrary order. In many cases, the certificates
included in a signed message may represent a chain of certification included in a signed message may represent a chain of certification
from the sender to a particular root. There may be, however, from the sender to a particular root. There may be, however,
situations where the certificates in a signed message may be unrelated situations where the certificates in a signed message may be unrelated
and included for convenience. and included for convenience.
skipping to change at line 272 skipping to change at line 269
Sending agents SHOULD make the address in the From or Sender header in Sending agents SHOULD make the address in the From or Sender header in
a mail message match an Internet mail address in the signer's a mail message match an Internet mail address in the signer's
certificate. Receiving agents MUST check that the address in the From certificate. Receiving agents MUST check that the address in the From
or Sender header of a mail message matches an Internet mail address in or Sender header of a mail message matches an Internet mail address in
the signer's certificate, if mail addresses are present in the the signer's certificate, if mail addresses are present in the
certificate. A receiving agent SHOULD provide some explicit alternate certificate. A receiving agent SHOULD provide some explicit alternate
processing of the message if this comparison fails, which may be to processing of the message if this comparison fails, which may be to
display a message that shows the recipient the addresses in the display a message that shows the recipient the addresses in the
certificate or other certificate details. certificate or other certificate details.
All subject and issuer names MUST be non-NULL in S/MIME-compliant v3 All subject and issuer names MUST be populated (i.e. not an empty
X.509 Certificates, except that the subject DN in a user's (i.e. end- SEQUENCE) in S/MIME-compliant v3 X.509 Certificates, except that the
entity) certificate MAY be NULL in which case the subjectAltName subject DN in a user's (i.e. end-entity) certificate MAY be an empty
extension will include the subject's identifier and MUST be marked as SEQUENCE in which case the subjectAltName extension will include the
critical. subject's identifier and MUST be marked as critical.
3.2 Required Name Attributes 3.2 Required Name Attributes
Receiving agents MUST support parsing of zero, one, or more instances Receiving agents MUST support parsing of zero, one, or more instances
of each of the following set of name attributes within the of each of the following set of name attributes within the
Distinguished Names in certificates. Distinguished Names in certificates.
Guidelines for the inclusion, omission, and ordering of name Guidelines for the inclusion, omission, and ordering of name
attributes during the creation of a distinguished name will most attributes during the creation of a distinguished name will most
likely be dictated by the policies associated with the certification likely be dictated by the policies associated with the certification
skipping to change at line 339 skipping to change at line 336
retrieval mechanism would be limited to the certificates that a user retrieval mechanism would be limited to the certificates that a user
has stored (presumably from incoming messages). A comprehensive has stored (presumably from incoming messages). A comprehensive
certificate retrieval/storage solution may combine two or more certificate retrieval/storage solution may combine two or more
mechanisms to allow the greatest flexibility and utility to the user. mechanisms to allow the greatest flexibility and utility to the user.
For instance, a secure Internet mail agent may resort For instance, a secure Internet mail agent may resort
to checking a centralized certificate retrieval mechanism for a to checking a centralized certificate retrieval mechanism for a
certificate if it can not be found in a user's local certificate certificate if it can not be found in a user's local certificate
storage/retrieval database. storage/retrieval database.
Receiving and sending agents SHOULD provide a mechanism for the import Receiving and sending agents SHOULD provide a mechanism for the import
and export of certificates, using a PKCS #7 certs-only message. This and export of certificates, using a CMS certs-only message. This
allows for import and export of full certificate chains as opposed to allows for import and export of full certificate chains as opposed to
just a single certificate. This is described in [SMIME-MSG]. just a single certificate. This is described in [SMIME-MSG].
4.1 Certificate Revocation Lists 4.1 Certificate Revocation Lists
A receiving agent SHOULD have access to some certificate-revocation A receiving agent SHOULD have access to some certificate-revocation
list (CRL) retrieval mechanism in order to gain access to certificate- list (CRL) retrieval mechanism in order to gain access to certificate-
revocation information when validating certificate chains. A receiving revocation information when validating certificate chains. A receiving
or sending agent SHOULD also provide a mechanism to allow a user to or sending agent SHOULD also provide a mechanism to allow a user to
store incoming certificate-revocation information for correspondents store incoming certificate-revocation information for correspondents
skipping to change at line 371 skipping to change at line 368
information in a particular context is beyond the scope of this draft information in a particular context is beyond the scope of this draft
but may be governed by the policies associated with particular but may be governed by the policies associated with particular
certificate hierarchies. certificate hierarchies.
4.2 Certificate Chain Validation 4.2 Certificate Chain Validation
In creating a user agent for secure messaging, certificate, CRL, and In creating a user agent for secure messaging, certificate, CRL, and
certificate chain validation SHOULD be highly automated while still certificate chain validation SHOULD be highly automated while still
acting in the best interests of the user. Certificate, CRL, and chain acting in the best interests of the user. Certificate, CRL, and chain
validation MUST be performed as per [KEYM] when validating a validation MUST be performed as per [KEYM] when validating a
correspondent's public key. This is necessary when a) verifying a correspondent's public key. This is necessary before using a public
signature from a correspondent and, b) creating a digital envelope key to provide security services such as: verifying a signature;
with the correspondent as the intended recipient. encrypting a content-encryption key (ex: RSA); or forming a pairwise
symmetric key (ex: Diffie-Hellman) to be used to encrypt or decrypt a
content-encryption key.
Certificates and CRLs are made available to the chain validation Certificates and CRLs are made available to the chain validation
procedure in two ways: a) incoming messages, and b) certificate and procedure in two ways: a) incoming messages, and b) certificate and
CRL retrieval mechanisms. Certificates and CRLs in incoming messages CRL retrieval mechanisms. Certificates and CRLs in incoming messages
are not required to be in any particular order nor are they required are not required to be in any particular order nor are they required
to be in any way related to the sender or recipient of the message to be in any way related to the sender or recipient of the message
(although in most cases they will be related to the sender). Incoming (although in most cases they will be related to the sender). Incoming
certificates and CRLs SHOULD be cached for use in chain validation and certificates and CRLs SHOULD be cached for use in chain validation and
optionally stored for later use. This temporary certificate and CRL optionally stored for later use. This temporary certificate and CRL
cache SHOULD be used to augment any other certificate and CRL cache SHOULD be used to augment any other certificate and CRL
skipping to change at line 457 skipping to change at line 456
lists and other data. lists and other data.
For example, a certification authority may create subordinate issuer For example, a certification authority may create subordinate issuer
certificates which contain a keyUsage extension which specifies that certificates which contain a keyUsage extension which specifies that
the corresponding public key can be used to sign end user certs and the corresponding public key can be used to sign end user certs and
sign CRLs. sign CRLs.
If a key usage extension is included in a v3 X.509 Certificate, then If a key usage extension is included in a v3 X.509 Certificate, then
it MUST be marked as critical. it MUST be marked as critical.
4.4.3 Subject Alt Name Extension 4.4.3 Subject Alternative Name Extension
TBD The subject alternative name extension is used in S/MIME as the
preferred means to convey the RFC-822 email address(es) that
correspond to the entity for this certificate. Any RFC-822 email
addresses present MUST be encoded using the rfc822Name CHOICE of the
GeneralName type. Since the SubjectAltName type is a SEQUENCE OF
GeneralName, multiple RFC-822 email addresses MAY be present.
5. Security Considerations 5. Security Considerations
All of the security issues faced by any cryptographic application must All of the security issues faced by any cryptographic application must
be faced by a S/MIME agent. Among these issues are protecting the be faced by a S/MIME agent. Among these issues are protecting the
user's private key, preventing various attacks, and helping the user user's private key, preventing various attacks, and helping the user
avoid mistakes such as inadvertently encrypting a message for the avoid mistakes such as inadvertently encrypting a message for the
wrong recipient. The entire list of security considerations is beyond wrong recipient. The entire list of security considerations is beyond
the scope of this document, but some significant concerns are listed the scope of this document, but some significant concerns are listed
here. here.
skipping to change at line 496 skipping to change at line 500
- no ability to check the CRL for a certificate - no ability to check the CRL for a certificate
- an invalid CRL was received - an invalid CRL was received
- the CRL being checked is expired - the CRL being checked is expired
- the certificate is expired - the certificate is expired
- the certificate has been revoked - the certificate has been revoked
There are certainly other instances where a certificate may be There are certainly other instances where a certificate may be
invalid, and it is the responsibility of the processing software to invalid, and it is the responsibility of the processing software to
check them all thoroughly, and to decide what to do if the check check them all thoroughly, and to decide what to do if the check
fails. fails.
A. Object Identifiers and Syntax A. References
Sections A.1 through A.4 are adopted from [SMIME-MSG].
A.5 Name Attributes
emailAddress OBJECT IDENTIFIER ::=
{iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9)
1}
id-at-countryName OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 6}
id-at-stateOrProvinceName OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 8}
id-at-localityName OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 7}
id-at-commonName OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 3}
id-at-title OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 12}
id-at-organizationName OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 10}
id-at-organizationalUnitName OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 11}
id-at-streetAddress OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 9}
id-at-postalCode OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 17}
id-at-telephoneNumber OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 20}
A.6 X.509 V3 Certificate Extensions
basicConstraints OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) 29 19 }
The ASN.1 definition of basicConstraints certificate extension is:
basicConstraints basicConstraints EXTENSION ::= {
SYNTAX BasicConstraintsSyntax
IDENTIFIED BY { id-ce 19 } }
BasicConstraintsSyntax ::= SEQUENCE {
cA BOOLEAN DEFAULT FALSE,
pathLenConstraint INTEGER (0..MAX) OPTIONAL }
keyUsage OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) 29 15 }
The ASN.1 definition of keyUsage certificate extension is:
keyUsage EXTENSION ::= {
SYNTAX KeyUsage
IDENTIFIED BY { id-ce 15 }}
KeyUsage ::= BIT STRING {
digitalSignature (0),
nonRepudiation (1),
keyEncipherment (2),
dataEncipherment (3),
keyAgreement (4),
keyCertSign (5),
cRLSign (6)}
B. References
[CERTV2] "S/MIME Certificate Handling", Internet Draft draft-dusse- [CERTV2] "S/MIME Version 2 Certificate Handling", RFC 2312
smime-cert
[CMS] "Cryptographic Message Syntax", Internet Draft draft-housley- [CMS] "Cryptographic Message Syntax", Internet Draft draft-housley-
smime-cms smime-cms
[CRMF] "Certificate Request Message Format", Internet Draft draft-ietf- [CRMF] "Certificate Request Message Format", Internet Draft draft-ietf-
pkix-crmf pkix-crmf
[KEYM] "Internet Public Key Infrastructure X.509 Certificate and CRL [KEYM] "Internet Public Key Infrastructure X.509 Certificate and CRL
Profile", Internet-Draft draft-ietf-pkix-ipki-part1 Profile", Internet-Draft draft-ietf-pkix-ipki-part1
[MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement [MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119 Levels", RFC 2119
[PKCS-1], "PKCS #1: RSA Encryption", draft has been submitted for RFC
status
[RFC-822], "Standard For The Format Of ARPA Internet Text Messages", [RFC-822], "Standard For The Format Of ARPA Internet Text Messages",
RFC 822. RFC 822.
[SMIME-MSG] "S/MIME Version 3 Message Specification ", Internet Draft [SMIME-MSG] "S/MIME Version 3 Message Specification ", Internet Draft
draft-ietf-smime-msg draft-ietf-smime-msg
[X.500] ITU-T Recommendation X.500 (1997) | ISO/IEC 9594-1:1997, [X.500] ITU-T Recommendation X.500 (1997) | ISO/IEC 9594-1:1997,
Information technology - Open Systems Interconnection - The Directory: Information technology - Open Systems Interconnection - The Directory:
Overview of concepts, models and services Overview of concepts, models and services
skipping to change at line 611 skipping to change at line 538
Models Models
[X.509] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1997, [X.509] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1997,
Information technology - Open Systems Interconnection - The Directory: Information technology - Open Systems Interconnection - The Directory:
Authentication framework Authentication framework
[X.520] ITU-T Recommendation X.520 (1997) | ISO/IEC 9594-6:1997, [X.520] ITU-T Recommendation X.520 (1997) | ISO/IEC 9594-6:1997,
Information technology - Open Systems Interconnection - The Directory: Information technology - Open Systems Interconnection - The Directory:
Selected attribute types. Selected attribute types.
C. Compatibility with Prior Practice in S/MIME B. Acknowledgements
S/MIME was originally developed by RSA Data Security, Inc. Many
developers implemented S/MIME agents before this document was
published. All S/MIME receiving agents SHOULD make every attempt to
interoperate with these earlier implementations of S/MIME.
D. Changes from S/MIME v2
Reworded section 4.3 for signing algorithms to MUST id-dsa-with-sha1
and SHOULD all others
Changed [SMIME-MSG] to draft-ietf-smime-msg
Changed references to PKCS #7 and [PKCS-7] to Cryptographic Message
Specification and [CMS]
Section 2.2 is now "CertificateChoices" instead of
"ExtendedCertificatesOrCertificate"
Section 2.3 is now "CertificateSet" instead of
"ExtendedCertificatesAndCertificates"
Attribute certificates added
Section 5.3 is now SHOULD id-dsa-with-sha1 and MAY sha-
1WithRSAEncryption
Added CRMF for certificate requests in section 5
Section 4.4.2 X.509v3 key usage extension MUST be critical if present
E. Acknowledgements
This document is largely based on [CERTV2] written by Steve Dusse, This document is largely based on [CERTV2] written by Steve Dusse,
Paul Hoffman, Blake Ramsdell, and Jeff Weinstein. Paul Hoffman, Blake Ramsdell, and Jeff Weinstein.
Significant comments and additions were made by Michael Myers, John Significant comments and additions were made by John Pawling and Jim
Pawling and Jim Schaad. Schaad.
F. Needed changes C. Needed changes
Algorithms for certs Names for chaining -- still no clear consensus
Names for chaining
Rewrite 5.2 for CMP and id-dsa-with-sha1
Make references [PKCS-*] consistent with smime-msg spec
2.2.1 -- are they "proposed" revisions, or actual revisions?
Section A.7 -- bit 7 is encipherOnly, bit 8 is decipherOnly. Are we
going to use these?
Challenge password -- CHOICE should be tagged for assigning values,
and should UTF8 should be an option?
A.7 -- certificate extensions. Are we keeping this up-to-date, or do
we just refer to PKIX?
subjectAltName is an extension -- we need to deal with it as such
Key usage for signing / encrypting certificate explanation Key usage for signing / encrypting certificate explanation
4.4.3 -- do we need to further qualify the syntax for rfc822Name (no
wildcards or comments)?
We need a reference for attribute certificates
G. Changes from last draft D. Changes from last draft
Cleaned up OIDs (Phil Griffin) Revised section 1 (John Pawling)
MUST changed to MAY for email address in certs (section 3.1) (Elliott Removed [PKCS-1] due to section 1 revisions (Blake Ramsdell)
Ginsburg) Changed Certificate and Certificate Revocation List definitions to
Added clarification for certificate chaining in 4.2 to refer to PKIX identify extensions and refer to [KEYM] (John Pawling)
Another MUST to MAY for email address in certificates, section 2.2
(John Pawling) (John Pawling)
Removed all cert request language (Paul Hoffman) Added Attribute Certificates to 2.2.1 (Jim Schaad)
Changed some CCITT to ITU-T Changed language regarding "proposed" v3 extensions in 2.2.1 (Jim
Schaad / John Pawling)
Reworded NULL-DN sentence in 3.1 to avoid confusion with ASN.1 NULL
(John Pawling)
PKCS #7 to CMS in section 4 (John Pawling)
Section 4.2, revised language to support Diffie-Hellman (John Pawling)
Removed section A which was basically restating things in other drafts
(John Pawling)
Section 2.1, removed language regarding nextUpdate field in CRL
(Elliott Ginsburg)
Wrote 4.4.3. Flames welcome. (Blake Ramsdell)
Fixed [CERTV2] to point to RFC 2312 (Blake Ramsdell)
Removed "old S/MIME" appendix (Jim Schaad, John Pawling, Paul Hoffman)
H. Editor's address E. Editor's address
Blake Ramsdell Blake Ramsdell
Worldtalk Worldtalk
13122 NE 20th St., Suite C 13122 NE 20th St., Suite C
Bellevue, WA 98005 Bellevue, WA 98005
(425) 882-8861 (425) 882-8861
blaker@deming.com blaker@deming.com
 End of changes. 

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