draft-ietf-smime-cert-01.txt   draft-ietf-smime-cert-02.txt 
Internet Draft Editor: Blake Ramsdell, Internet Draft Editor: Blake Ramsdell,
draft-ietf-smime-cert-01.txt Worldtalk draft-ietf-smime-cert-02.txt Worldtalk
January 28, 1998 March 11, 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.
skipping to change at line 44 skipping to change at line 44
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 In order to handle S/MIME certificates, an agent has to follow
specifications in this draft, as well as some of the specifications specifications in this draft, as well as some of the specifications
listed in the following documents: listed in the following documents:
- ''PKCS #1: RSA Encryption'', [PKCS-1]. - "PKCS #1: RSA Encryption", [PKCS-1].
- ''Cryptographic Message Syntax'', [CMS]. - "Cryptographic Message Syntax", [CMS].
- ''PKCS #10: Certification Request Syntax'', [PKCS-10].
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 CCITT 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 CCITT 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 CCITT 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, and a validity period.
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, and a list of certificate serial numbers
and their associated revocation times. The CRL is signed by the and their associated revocation times. The CRL is signed by the
issuer. The type intended by this specification is the one defined in issuer. The type intended by this specification is the one defined in
[KEYM]. [KEYM].
DER: Distinguished Encoding Rules for ASN.1, as defined in CCITT 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 Appendix C contains important information about how S/MIME agents
following this specification should act in order to have the greatest following this specification should act in order to have the greatest
interoperability with earlier implementations of S/MIME. interoperability with earlier implementations of S/MIME.
1.3 Terminology 1.3 Terminology
skipping to change at line 218 skipping to change at line 217
3.1 Using Distinguished Names for Internet Mail 3.1 Using Distinguished Names for Internet Mail
The format of an X.509 certificate includes fields for the subject The format of an X.509 certificate includes fields for the subject
name and issuer name. The subject name identifies the owner of a name and issuer name. The subject name identifies the owner of a
particular public key/private key pair while the issuer name is meant particular public key/private key pair while the issuer name is meant
to identify the entity that "certified" the subject (that is, who to identify the entity that "certified" the subject (that is, who
signed the subject's certificate). The subject name and issuer name signed the subject's certificate). The subject name and issuer name
are defined by X.509 as Distinguished Names. are defined by X.509 as Distinguished Names.
Distinguished Names are defined by a CCITT standard X.501 [X.501]. A Distinguished Names are defined by a ITU-T standard X.501 [X.501]. A
Distinguished Name is broken into one or more Relative Distinguished Distinguished Name is broken into one or more Relative Distinguished
Names. Each Relative Distinguished Name is comprised of one or more Names. Each Relative Distinguished Name is comprised of one or more
Attribute-Value Assertions. Each Attribute-Value Assertion consists of Attribute-Value Assertions. Each Attribute-Value Assertion consists of
a Attribute Identifier and its corresponding value information, such a Attribute Identifier and its corresponding value information, such
as CountryName=US. Distinguished Names were intended to identify as CountryName=US. Distinguished Names were intended to identify
entities in the X.500 directory tree [X.500]. Each Relative entities in the X.500 directory tree [X.500]. Each Relative
Distinguished Name can be thought of as a node in the tree which is Distinguished Name can be thought of as a node in the tree which is
described by some collection of Attribute-Value Assertions. The entire described by some collection of Attribute-Value Assertions. The entire
Distinguished Name is some collection of nodes in the tree that Distinguished Name is some collection of nodes in the tree that
traverse a path from the root of the tree to some end node which traverse a path from the root of the tree to some end node which
skipping to change at line 253 skipping to change at line 252
messages. However, Internet mail addresses bear no resemblance to messages. However, Internet mail addresses bear no resemblance to
X.500 Distinguished Names (except, perhaps, that they are both X.500 Distinguished Names (except, perhaps, that they are both
hierarchical in nature). Some method is needed to map Internet mail hierarchical in nature). Some method is needed to map Internet mail
addresses to entities that hold public keys. Some people have addresses to entities that hold public keys. Some people have
suggested that the X.509 certificate format should be abandoned in suggested that the X.509 certificate format should be abandoned in
favor of other binding mechanisms. Instead, S/MIME keeps the X.509 favor of other binding mechanisms. Instead, S/MIME keeps the X.509
certificate and Distinguished Name mechanisms while tailoring the certificate and Distinguished Name mechanisms while tailoring the
content of the naming information to suit the Internet mail content of the naming information to suit the Internet mail
environment. environment.
End-entity certificates MUST contain an Internet mail address as End-entity certificates MAY contain an Internet mail address as
described in [RFC-822]. The address must be an "addr-spec" as defined described in [RFC-822]. The address must be an "addr-spec" as defined
in Section 6.1 of that specification. The email address SHOULD be in in Section 6.1 of that specification. The email address SHOULD be in
the subjectAltName extension, and SHOULD NOT be in the subject the subjectAltName extension, and SHOULD NOT be in the subject
distinguished name. distinguished name.
Receiving agents MUST recognize email addresses in the subjectAltName Receiving agents MUST recognize email addresses in the subjectAltName
field. Receiving agents MUST recognize email addresses in the field. Receiving agents MUST recognize email addresses in the
Distinguished Name field. Distinguished Name field.
Sending agents SHOULD make the address in the From header in a mail Sending agents SHOULD make the address in the From or Sender header in
message match an Internet mail address in the signer's certificate. a mail message match an Internet mail address in the signer's
Receiving agents MUST check that the address in the From header of a certificate. Receiving agents MUST check that the address in the From
mail message matches an Internet mail address in the signer's or Sender header of a mail message matches an Internet mail address in
certificate. A receiving agent MUST provide some explicit alternate the signer's certificate, if mail addresses are present in the
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
reject the message. display a message that shows the recipient the addresses in the
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 non-NULL in S/MIME-compliant v3
X.509 Certificates, except that the subject DN in a user's (i.e. end- X.509 Certificates, except that the subject DN in a user's (i.e. end-
entity) certificate MAY be NULL in which case the subjectAltName entity) certificate MAY be NULL in which case the subjectAltName
extension will include the subject's identifier and MUST be marked as extension will include the subject's identifier and MUST be marked as
critical. 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.
Sending agents MUST include the Internet mail address during Guidelines for the inclusion, omission, and ordering of name
Distinguished Name creation. Guidelines for the inclusion, omission, attributes during the creation of a distinguished name will most
and ordering of the remaining name attributes during the creation of a likely be dictated by the policies associated with the certification
distinguished name will most likely be dictated by the policies service which will certify the corresponding name and public key.
associated with the certification service which will certify the
corresponding name and public key.
CountryName countryName
StateOrProvinceName stateOrProvinceName
Locality localityName
CommonName commonName
Title title
Organization organizationName
OrganizationalUnit organizationalUnitName
StreetAddress streetAddress
PostalCode postalCode
PhoneNumber telephoneNumber
EmailAddress emailAddress
All attributes other than EmailAddress are described in X.520 [X.520]. All attributes other than emailAddress are described in X.520 [X.520].
EmailAddress is an IA5String that can have multiple attribute values. emailAddress is an IA5String that can have multiple attribute values.
4. Certificate Processing 4. Certificate Processing
A receiving agent needs to provide some certificate retrieval A receiving agent needs to provide some certificate retrieval
mechanism in order to gain access to certificates for recipients of mechanism in order to gain access to certificates for recipients of
digital envelopes. There are many ways to implement certificate digital envelopes. There are many ways to implement certificate
retrieval mechanisms. X.500 directory service is an excellent example retrieval mechanisms. X.500 directory service is an excellent example
of a certificate retrieval-only mechanism that is compatible with of a certificate retrieval-only mechanism that is compatible with
classic X.500 Distinguished Names. The PKIX Working Group is classic X.500 Distinguished Names. The PKIX Working Group is
investigating other mechanisms. Another method under consideration by investigating other mechanisms. Another method under consideration by
skipping to change at line 371 skipping to change at line 370
the value of the information that is protected. The value of the CRL the value of the information that is protected. The value of the CRL
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 when validating a correspondent's public validation MUST be performed as per [KEYM] when validating a
key. This is necessary when a) verifying a signature from a correspondent's public key. This is necessary when a) verifying a
correspondent and, b) creating a digital envelope with the signature from a correspondent and, b) creating a digital envelope
correspondent as the intended recipient. with the correspondent as the intended recipient.
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 440 skipping to change at line 439
The basic constraints extension serves to delimit the role and The basic constraints extension serves to delimit the role and
position of an issuing authority or end-user certificate plays in a position of an issuing authority or end-user certificate plays in a
chain of certificates. chain of certificates.
For example, certificates issued to CAs and subordinate CAs contain a For example, certificates issued to CAs and subordinate CAs contain a
basic constraint extension that identifies them as issuing authority basic constraint extension that identifies them as issuing authority
certificates. End-user subscriber certificates contain an extension certificates. End-user subscriber certificates contain an extension
that constrains the certificate from being an issuing authority that constrains the certificate from being an issuing authority
certificate. certificate.
Certificates SHOULD contain a basicContstraints extension. Certificates SHOULD contain a basicConstraints extension.
4.4.2 Key Usage Certificate Extension 4.4.2 Key Usage Certificate Extension
The key usage extension serves to limit the technical purposes for The key usage extension serves to limit the technical purposes for
which a public key listed in a valid certificate may be used. Issuing which a public key listed in a valid certificate may be used. Issuing
authority certificates may contain a key usage extension that authority certificates may contain a key usage extension that
restricts the key to signing certificates, certificate revocation restricts the key to signing certificates, certificate revocation
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.
5. Generating Keys and Certification Requests 4.4.3 Subject Alt Name Extension
5.1 Binding Names and Keys
An S/MIME agent or some related administrative utility or function
MUST be capable of generating a certification request given a user's
public key and associated name information. In most cases, the user's
public key/private key pair will be generated simultaneously. However,
there are cases where the keying information may be generated by an
external process (such as when a key pair is generated on a
cryptographic token or by a "key recovery" service).
There SHOULD NOT be multiple valid (that is, non-expired and non-
revoked) certificates for the same key pair bound to different
Distinguished Names. Otherwise, a security flaw exists where an
attacker can substitute one valid certificate for another in such a
way that can not be detected by a message recipient. If a users wishes
to change their name (or create an alternate name), the user agent
SHOULD generate a new key pair. If the user wishes to reuse an
existing key pair with a new or alternate name, the user SHOULD first
have any valid certificates for the existing public key revoked.
In general, it is possible for a user to request certification for the
same name and different public key from the same or different
certification authorities. This is acceptable both for end-entity and
issuer certificates and can be useful in supporting a change of issuer
keys in a smooth fashion.
CAs that re-use their own name with distinct keys MUST include the
AuthorityKeyIdentifier extension in certificates that they issue, and
MUST have the SubjectKeyIdentifier extension in their own certificate.
CAs SHOULD use these extensions uniformly.
Clients SHOULD handle multiple valid CA certificates that certify
different public keys but contain the same subject name (in this case,
that CA's name).
When selecting an appropriate issuer's certificate to use to verify a
given certificate, clients SHOULD process the AuthorityKeyIdentifier
and SubjectKeyIdentifier extensions. Use of these extensions SHOULD
be compliant with [KEYM].
5.2 Certificate Acquisition
A public key certification request is formed as a CertReqMessages
object as defined in [CRMF]. The corresponding response is CMS
encapsulation of the requested certificate and its associated non-Root
CA certificate(s) as defined in Section 5.6.
Both the CertReqMessages content and the resulting response SHOULD be
encapsulated within a full CMS security envelope. This encapsulation
enables Registration Authorities to place a signature across a
certificate request. It includes other information relevant to the
processing and handling of a certification request. The request,
response, required CMS encapsulation and transaction handling is
collectively referred to as the Certification Request Syntax (CRS).
Some existing implementations of these mechanisms utilize a simplified
form of this exchange. In these implementations, an unencapsulated
PKCS10 object is provided to the Certification Authority, which
responds with an unencapsulated CertRep syntax.
5.2.1 Encapsulating PKI Messages in CMS
CMS-encapsulated certification requests and responses SHALL be
constructed as follows. The contentInfo field of a signedData type
is populated with the envelopedData content type if the content is
encrypted or Data content type if the data is sent in cleartext form.
The content contains one of the following message bodies:
- PKCSReq -- Request for a certificate
- CertRep -- Response to a certificate request
The presence of a particular message body type in either the
encryptedContent of an envelopedData content type or the content of a
Data content type SHALL be indicated by value of the messageType
authenticated attribute of the outermost SignedData.
Two options exist with respect to the use of encryption. One usage
produces an encrypted message body encapsulated by a signed, cleartext
envelope. Organizations that wish to protect against the leakage of
sensitive data via cleartext channels may chose instead to produce a
cleartext message body which is placed with a signed envelope which is
in turn encapsulated by an encrypted envelope. These options are
illustrated as:
Option 1 Option 2
SignedData EnvelopedData
EnvelopedData SignedData
Data <message body>
<message body>
CRS message bodies MAY be encrypted or transmitted in the clear.
Support SHALL be provided for encryption option 1 and SHOULD be
provided for both.
5.2.1.2 CRS Service Indicators
The SignerInfos portion of SignedData carries one or more Service
Indicators as authenticatedAttributes. [CMS] requires that the value
of authenticatedAttributes is hashed using the algorithm specified by
digestAlgorithm, signed using the message originator's private key
corresponding to digestEncryptionAlgorithm, the result encoded as an
OCTET STRING and assigned to the encryptedDigest field of SignedData.
The following Service Indicators are defined:
- version
- messageType
- pkiStatus
- failinfo
- transactionId
- senderNonce
- recipientNonce
The version service indicator indicate CRS protocol version. If
absent, a value of 0 SHALL be assumed. This specification is CRS
version 1.
The messageType service indicator identifies the syntax carried in the
message body. Every CRS message SHALL include a value for messageType
appropriate to the message.
The messageType service indicator specifies the type of operation
performed by the transaction. This attribute is required in all
messages. The following values for messageType are defined:
Message MessageType Value
CertReq (19) -- Certification request
CertRep (3) -- Response to certificate request
The value given for messageType value is set in the messageType
service indicator for messages of the indicated type. This service
indicator SHALL be included in every message.
The pkiStatus service indicator is used to convey information relevant
to a requested operation. This service indicator SHALL be included in
every message.
Response messages SHALL include transaction status information which
is defined as pkiStatus service indicator:
Status pkiStatus value
SUCCESS (0) -- request successful
PENDING (1) -- request is pending
FAILURE (2) -- request rejected
This pKIStatus service indicator is required for all PKI messages. The
value given for pkiStatus value is set in the pkiStatus service
indicator for status of the indicated type.
The failInfo service indicator conveys information relevant to the
interpretation of a failure condition. This service indicator is
mandatory in every message.
The messageType, pkiStatus, and failInfo service indicators are
mandatory for all messages. If additional transaction management or
replay protection is desired, transactionID, senderNonce and
recipientNonce MAY be implemented.
The transactionId service indicator identifies a given transaction.
It is used between client and server to manage the state of an
operation. It MAY be included in service request messages. If
included, responses SHALL included the transmitted value.
The senderNonce and recipientNonce service indicator can be used to
provide application-level replay prevention. They MAY be included in
service request messages. Originating messages include only a value
for senderNonce. If included, responses SHALL include the transmitted
value of the previously received senderNonce as recipientNonce and
include a value for senderNonce.
If nonces are used, in the first message of a transaction, no
recipientNonce is transmitted; a senderNonce is instantiated by the
message originator and retained for later reference. The recipient of
a sender nonce reflects this value back to the originator as a
recipientNonce and includes it's own senderNonce. Upon receipt by the
transaction originator of this message, the originator compares the
value of recipientNonce to its retained value. If the values match,
the message can be accepted for further security processing. The
received value for senderNonce is also retained for inclusion in the
next message associated with the same transaction.
If a transaction originator includes a value for the senderNonce
service indicator, responses SHALL include this value as a value for
recipientNonce AND include a value for the SenderNonce service
indicator. If a transaction originator includes a value for the
transaction-id service indicator in a service request, responses SHALL
include this value as a value for transaction-id service indicator.
5.2.1.2 Service Indicators Identification and Syntax
When included in a CMS message, AuthenticatedAttributes must consist
of at a minimum:
- A PKCS #9 content-type attribute having as its value the content
type of the ContentInfo value being signed.
- A PKCS #9 message-digest attribute, having as its value the message
digest of the content.
Each Service Indicator is uniquely identified by an Object Identifier.
KEYM establishes a registration arc for objects associated with
certificate management protocols. The value of id-it is imported from
that reference. This specification extends id-it as follows:
id-it OBJECT IDENTIFIER ::= { id-pkix 4 } -- imported from PKIX
id-si OBJECT IDENTIFIER ::= { id-it 1 } -- CRS service indicators
id-si-version OBJECT IDENTIFIER ::= { id-si 1 }
id-si-transactionID OBJECT IDENTIFIER ::= { id-si 2 }
id-si-messageType OBJECT IDENTIFIER ::= { id-si 3 }
id-si-pkiStatus OBJECT IDENTIFIER ::= { id-si 4 }
id-si-failInfo OBJECT IDENTIFIER ::= { id-si 5 }
id-si-senderNonce OBJECT IDENTIFIER ::= { id-si 6 }
id-si-recipientNonce OBJECT IDENTIFIER ::= { id-si 7 }
The corresponding value syntax for each is:
Service Indicator Syntax
version INTEGER
TransactionId INTEGER
messageType INTEGER
pkiStatus INTEGER
failInfo INTEGER
senderNonce OCTET STRING
recipientNonce OCTET STRING
5.2.2 Common Certification Request Requirements
This specification establishes two forms of certification request:
CRMF and PKCS10. Applications MUST support CRMF; they MAY support
PKCS10. The CRMF (Certificate Request Message Format) syntax and
semantics are defined in [CRMF]. The syntax and semantics defining
PKCS10 is defined by [PKCS10].
This section specifies information processing requirements common to
both methods. Section 5.3 defines the requirements unique to PKCS10.
Section 5.4 defines the requirements unique to CRMF.
Receiving agents MUST support the identification of an RSA key with
the rsa defined in X.509 and the rsaEncryption OID. Certification
authorities MUST support sha-1WithRSAEncryption and
md5WithRSAEncryption and SHOULD support md2WithRSAEncryption for
verification of signatures on certificate requests as described in
[SMIME-MSG].
For the creation and submission of certification-requests, RSA keys
SHOULD be identified with the rsaEncryption OID and signed with the
sha-1WithRSAEncryption signature algorithm. Certification-requests
MUST NOT be signed with the md2WithRSAEncryption signature algorithm.
Certification requests MUST include a valid Internet mail address,
either as part of the certificate (as described in 3.2) associated
with the message carrying the certificate request or as part of the
certificate request information produced by the subscriber.
Certification authorities MUST check that the address in the "From:"
header matches either of these addresses. CAs SHOULD allow the CA
operator to configure processing of messages whose addresses do not
match
5.3 Using PKCS #10 for Certification Requests
PKCS #10 is a flexible and extensible message format for representing
the results of cryptographic operations on some data. The choice of
naming information is largely dictated by the policies and procedures
associated with the intended certification service.
In addition to key and naming information, the PKCS #10 format
supports the inclusion of optional attributes, signed by the entity
requesting certification. This allows for information to be conveyed
in a certification request which may be useful to the request process,
but not necessarily part of the Distinguished Name being certified.
Certification authorities SHOULD support parsing of zero or one
instance of each of the following set of certification-request
attributes on incoming messages. Attributes that a particular
implementation does not support may generate a warning message to the
requestor, or may be silently ignored. Inclusion of the following
attributes during the creation and submission of a certification-
request will most likely be dictated by the policies associated with
the certification service which will certify the corresponding name
and public key.
postalAddress
challengePassword
unstructuredAddress
postalAddress is described in [X.520].
5.3.1 Challenge Password
The challenge-password attribute type specifies a password by which an
entity may request certificate revocation. The interpretation of the
password is intended to be specified by the issuer of the certificate;
no particular interpretation is required. The challenge-password
attribute type is intended for PKCS #10 certification requests.
Challenge-password attribute values have ASN.1 type ChallengePassword:
ChallengePassword ::= CHOICE {
PrintableString, T61String }
A challenge-password attribute must have a single attribute value.
It is expected that if UCS becomes an ASN.1 type (e.g., UNIVERSAL
STRING), ChallengePassword will become a CHOICE type:
ChallengePassword ::= CHOICE {
PrintableString, T61String, UNIVERSAL STRING }
5.3.2 Unstructured Address
The unstructured-address attribute type specifies the address or
addresses of the subject of a certificate as an unstructured ASCII or
T.61 string. The interpretation of the addresses is intended to be
specified by the issuer of the certificate; no particular
interpretation is required. A likely interpretation is as an
alternative to the X.520 postalAddress attribute type. The
unstructured-address attribute type is intended for PKCS #10
certification requests.
Unstructured-address attribute values have ASN.1 type
UnstructuredAddress:
UnstructuredAddress ::= CHOICE {
PrintableString, T61String }
An unstructured-address attribute can have multiple attribute values.
Note: T.61's newline character (hexadecimal code 0d) is recommended as
a line separator in multi-line addresses.
It is expected that if UCS becomes an ASN.1 type (e.g., UNIVERSAL
STRING), UnstructuredAddress will become a CHOICE type:
UnstructuredAddress ::= CHOICE {
PrintableString, T61String, UNIVERSAL STRING }
5.4 Use of CRMF for Certification Requests
Construction of a CRMF-formatted certification request involves the
following steps:
1. A CertRequest value is constructed. This value consists of the
public key, all or portion of the end-entity's name, other requested
certificate fields, plus additional control information related to the
registration process.
2. A proof of possession value is calculated across the CertRequest
value.
3. Additional registration information, if required, is combined with
the proof of possession value and the CertRequest structure to form a
CertReqMessage.
4. Additional CertReqMessage objects are generated using steps 1-4 as
needed.
5. The result of step 4 is encoded as a CertReqMessages object.
6. The result of step 5 is encapsulated as a CRS message body as
described in Section 5.2.1.
[CRMF] details requirements on this process and the objects mentioned
in this description.
5.5 Fulfilling a Certification Request
Certification authorities SHOULD use the id-dsa-with-sha1 signature
algorithm when signing certificates.
Certification authorities MAY use the sha-1WithRSAEncryption signature
algorithm when signing certificates.
5.6 Using CMS for Fulfilled Certificate Response
[CMS] supports a degenerate case of the SignedData content type where
there are no signers on the content (and hence, the content value is
"irrelevant"). This degenerate case is used to convey certificate and
CRL information. Certification authorities MUST use this format for
returning certificate information resulting from the successful
fulfillment of a certification request. At a minimum, the fulfilled
certificate response MUST include the actual subject certificate
(corresponding to the information in the certification request). The
response SHOULD include other certificates which link the issuer to
higher level certification authorities and corresponding certificate-
revocation lists. Unrelated certificates and revocation information is
also acceptable.
Receiving agents MUST parse this degenerate CMS message type and TBD
handle the certificates and CRLs according to the requirements and
recommendations in Section 4.
6. 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.
When processing certificates, there are many situations where the When processing certificates, there are many situations where the
skipping to change at line 894 skipping to change at line 503
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. Object Identifiers and Syntax
Sections A.1 through A.4 are adopted from [SMIME-MSG]. Sections A.1 through A.4 are adopted from [SMIME-MSG].
A.5 Name Attributes A.5 Name Attributes
emailAddress OBJECT IDENTIFIER ::= emailAddress OBJECT IDENTIFIER ::=
{iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1} {iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9)
1}
CountryName OBJECT IDENTIFIER ::= id-at-countryName OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 6} {joint-iso-ccitt(2) ds(5) attributeType(4) 6}
StateOrProvinceName OBJECT IDENTIFIER ::= id-at-stateOrProvinceName OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 8} {joint-iso-ccitt(2) ds(5) attributeType(4) 8}
locality OBJECT IDENTIFIER ::= id-at-localityName OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 7} {joint-iso-ccitt(2) ds(5) attributeType(4) 7}
CommonName OBJECT IDENTIFIER ::= id-at-commonName OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 3} {joint-iso-ccitt(2) ds(5) attributeType(4) 3}
Title OBJECT IDENTIFIER ::= id-at-title OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 12} {joint-iso-ccitt(2) ds(5) attributeType(4) 12}
Organization OBJECT IDENTIFIER ::= id-at-organizationName OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 10} {joint-iso-ccitt(2) ds(5) attributeType(4) 10}
OrganizationalUnit OBJECT IDENTIFIER ::= id-at-organizationalUnitName OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 11} {joint-iso-ccitt(2) ds(5) attributeType(4) 11}
StreetAddress OBJECT IDENTIFIER ::= id-at-streetAddress OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 9} {joint-iso-ccitt(2) ds(5) attributeType(4) 9}
Postal Code OBJECT IDENTIFIER ::= id-at-postalCode OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 17} {joint-iso-ccitt(2) ds(5) attributeType(4) 17}
Phone Number OBJECT IDENTIFIER ::= id-at-telephoneNumber OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 20} {joint-iso-ccitt(2) ds(5) attributeType(4) 20}
A.6 Certification Request Attributes A.6 X.509 V3 Certificate Extensions
postalAddress OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 16}
challengePassword OBJECT IDENTIFIER ::=
{iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9) 7}
unstructuredAddress OBJECT IDENTIFIER ::=
{iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9) 8}
A.7 X.509 V3 Certificate Extensions
basicConstraints OBJECT IDENTIFIER ::= basicConstraints OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) 29 19 } {joint-iso-ccitt(2) ds(5) 29 19 }
The ASN.1 definition of basicConstraints certificate extension is: The ASN.1 definition of basicConstraints certificate extension is:
basicConstraints basicConstraints EXTENSION ::= { basicConstraints basicConstraints EXTENSION ::= {
SYNTAX BasicConstraintsSyntax SYNTAX BasicConstraintsSyntax
IDENTIFIED BY { id-ce 19 } } IDENTIFIED BY { id-ce 19 } }
skipping to change at line 990 skipping to change at line 589
[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 [PKCS-1], "PKCS #1: RSA Encryption", draft has been submitted for RFC
status status
[PKCS-10], "PKCS #10: Certification Request Syntax", 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 1049 skipping to change at line 645
E. Acknowledgements 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 Michael Myers, John
Pawling and Jim Schaad. Pawling and Jim Schaad.
F. Needed changes F. Needed changes
UNIVERSAL STRING for Challenge Password? Should this simply be
BMPString?
Algorithms for certs Algorithms for certs
Capitalization of OIDs
Stronger MD2 / MD5 language needed?
Names for chaining Names for chaining
Only one "official" email address?
Rewrite 5.2 for CMP and id-dsa-with-sha1 Rewrite 5.2 for CMP and id-dsa-with-sha1
Make references [PKCS-*] consistent with smime-msg spec Make references [PKCS-*] consistent with smime-msg spec
2.2.1 -- are they "proposed" revisions, or actual revisions? 2.2.1 -- are they "proposed" revisions, or actual revisions?
Section A.7 -- bit 7 is encipherOnly, bit 8 is decipherOnly. Are we Section A.7 -- bit 7 is encipherOnly, bit 8 is decipherOnly. Are we
going to use these? 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
G. Changes from last draft G. Changes from last draft
Added section G, changes from last draft Cleaned up OIDs (Phil Griffin)
Added attribute certificate definition in section 1.1, text from John MUST changed to MAY for email address in certs (section 3.1) (Elliott
Pawling Ginsburg)
Added attribute certificate SHOULD support in section 2.2 text from Added clarification for certificate chaining in 4.2 to refer to PKIX
John Pawling (John Pawling)
Added attribute certificate SHOULD support in section 2.3 text from Removed all cert request language (Paul Hoffman)
John Pawling Changed some CCITT to ITU-T
Changed 5.3 (renumbered to section 5.5) to SHOULD id-dsa-with-sha1 and
MAY sha-1WithRSAEncryption
Added [CMS]
Inserted new section 5.2, text from Michael Myers
Added some acknowledgements to section E
Added [CRMF]
Cleaned up [KEYM] reference
Section 4.4.2 now makes key usage critical if present
Added possible NULL DN language in section 3.1
Added SHOULD for email address in subjectAltName, and SHOULD NOT be in
subject DN in section 3.1
H. Editor's address H. 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/