draft-ietf-smime-cert-00.txt   draft-ietf-smime-cert-01.txt 
Internet Draft Editor: Blake Ramsdell, Internet Draft Editor: Blake Ramsdell,
draft-ietf-smime-cert-00.txt Worldtalk draft-ietf-smime-cert-01.txt Worldtalk
November 20, 1997 January 28, 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 54 skipping to change at line 54
- ''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]. - ''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 CCITT X.680-689.
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
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
public key X.509 Certificates. The X.509 AC syntax is defined in
[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 CCITT 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 CCITT
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.
skipping to change at line 137 skipping to change at line 144
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 MUST include an Internet mail address, as
described in section 3.1. described in section 3.1.
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 two formats
for public key content types: X.509 and PKCS #6 Extended Certificates. for public key content types: X.509 and PKCS #6 Extended Certificates.
The PKCS #6 format is not in widespread use. In addition, proposed The PKCS #6 format is not in widespread use. In addition, proposed
revisions of X.509 certificates address much of the same functionality revisions of X.509 certificates address much of the same functionality
and flexibility as was intended in the PKCS #6. Thus, sending and and flexibility as was intended in the PKCS #6. Thus, sending and
receiving agents MUST NOT use PKCS #6 extended certificates. receiving agents MUST NOT use PKCS #6 extended certificates.
2.3 CertificateSet 2.3 CertificateSet
skipping to change at line 186 skipping to change at line 195
Clients MAY send CA certificates, that is, certificates that are self- Clients MAY send CA certificates, that is, certificates that are self-
signed and can be considered the "root" of other chains. Note that signed and can be considered the "root" of other chains. Note that
receiving agents SHOULD NOT simply trust any self-signed certificates receiving agents SHOULD NOT simply trust any self-signed certificates
as valid CAs, but SHOULD use some other mechanism to determine if this as valid CAs, but SHOULD use some other mechanism to determine if this
is a CA that should be trusted. is a CA that should be trusted.
Receiving agents MUST support chaining based on the distinguished name Receiving agents MUST support chaining based on the distinguished name
fields. Other methods of building certificate chains may be supported fields. Other methods of building certificate chains may be supported
but are not currently recommended. but are not currently recommended.
Receiving agents SHOULD support X.509 attribute certificates. At a
minimum, receiving agents SHOULD at least support the decoding of
X.509 attribute certificates. Please note that there is no
requirement that the same CA create both the public key X.509
Certificate and X.509 attribute certificate(s) for a user. Each
organization's local policy will define how X.509 attribute
certificates are validated and used. The implications of performing
multiple certification path validations should be considered when
defining local policy. Exchanges between a subject and the CA dealing
with the generation of X.509 attribute certificates are outside the
scope of this specification.
3. Distinguished Names in Certificates 3. Distinguished Names in Certificates
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.
skipping to change at line 234 skipping to change at line 255
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 MUST 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. in Section 6.1 of that specification. The email address SHOULD be in
the subjectAltName extension, and SHOULD NOT be in the subject
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 header in a mail
message match an Internet mail address in the signer's certificate. message match an Internet mail address in the signer's certificate.
Receiving agents MUST check that the address in the From header of a Receiving agents MUST check that the address in the From header of a
mail message matches an Internet mail address in the signer's mail message matches an Internet mail address in the signer's
certificate. A receiving agent MUST provide some explicit alternate certificate. A receiving agent MUST 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. reject the message.
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-
entity) certificate MAY be NULL in which case the subjectAltName
extension will include the 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.
Sending agents MUST include the Internet mail address during Sending agents MUST include the Internet mail address during
Distinguished Name creation. Guidelines for the inclusion, omission, Distinguished Name creation. Guidelines for the inclusion, omission,
and ordering of the remaining name attributes during the creation of a and ordering of the remaining name attributes during the creation of a
distinguished name will most likely be dictated by the policies distinguished name will most likely be dictated by the policies
skipping to change at line 423 skipping to change at line 452
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
he 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
it MUST be marked as critical.
5. Generating Keys and Certification Requests 5. Generating Keys and Certification Requests
5.1 Binding Names and Keys 5.1 Binding Names and Keys
An S/MIME agent or some related administrative utility or function An S/MIME agent or some related administrative utility or function
MUST be capable of generating a certification request given a user's 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 and associated name information. In most cases, the user's
public key/private key pair will be generated simultaneously. However, public key/private key pair will be generated simultaneously. However,
there are cases where the keying information may be generated by an there are cases where the keying information may be generated by an
external process (such as when a key pair is generated on a external process (such as when a key pair is generated on a
skipping to change at line 466 skipping to change at line 497
AuthorityKeyIdentifier extension in certificates that they issue, and AuthorityKeyIdentifier extension in certificates that they issue, and
MUST have the SubjectKeyIdentifier extension in their own certificate. MUST have the SubjectKeyIdentifier extension in their own certificate.
CAs SHOULD use these extensions uniformly. CAs SHOULD use these extensions uniformly.
Clients SHOULD handle multiple valid CA certificates that certify Clients SHOULD handle multiple valid CA certificates that certify
different public keys but contain the same subject name (in this case, different public keys but contain the same subject name (in this case,
that CA's name). that CA's name).
When selecting an appropriate issuer's certificate to use to verify a When selecting an appropriate issuer's certificate to use to verify a
given certificate, clients SHOULD process the AuthorityKeyIdentifier given certificate, clients SHOULD process the AuthorityKeyIdentifier
and SubjectKeyIdentifier extensions. and SubjectKeyIdentifier extensions. Use of these extensions SHOULD
be compliant with [KEYM].
5.2 Using PKCS #10 for Certification Requests 5.2 Certificate Acquisition
PKCS #10 is a flexible and extensible message format for representing A public key certification request is formed as a CertReqMessages
the results of cryptographic operations on some data. The choice of object as defined in [CRMF]. The corresponding response is CMS
naming information is largely dictated by the policies and procedures encapsulation of the requested certificate and its associated non-Root
associated with the intended certification service. CA certificate(s) as defined in Section 5.6.
In addition to key and naming information, the PKCS #10 format Both the CertReqMessages content and the resulting response SHOULD be
supports the inclusion of optional attributes, signed by the entity encapsulated within a full CMS security envelope. This encapsulation
requesting certification. This allows for information to be conveyed enables Registration Authorities to place a signature across a
in a certification request which may be useful to the request process, certificate request. It includes other information relevant to the
but not necessarily part of the Distinguished Name being certified. 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
-- 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 Receiving agents MUST support the identification of an RSA key with
the rsa defined in X.509 and the rsaEncryption OID. Certification the rsa defined in X.509 and the rsaEncryption OID. Certification
authorities MUST support sha-1WithRSAEncryption and authorities MUST support sha-1WithRSAEncryption and
md5WithRSAEncryption and SHOULD support md2WithRSAEncryption for md5WithRSAEncryption and SHOULD support md2WithRSAEncryption for
verification of signatures on certificate requests as described in verification of signatures on certificate requests as described in
[SMIME-MSG]. [SMIME-MSG].
For the creation and submission of certification-requests, RSA keys For the creation and submission of certification-requests, RSA keys
SHOULD be identified with the rsaEncryption OID and signed with the SHOULD be identified with the rsaEncryption OID and signed with the
sha-1WithRSAEncryption signature algorithm. Certification-requests sha-1WithRSAEncryption signature algorithm. Certification-requests
MUST NOT be signed with the md2WithRSAEncryption signature algorithm. MUST NOT be signed with the md2WithRSAEncryption signature algorithm.
Certification requests MUST include a valid Internet mail address, Certification requests MUST include a valid Internet mail address,
either as part of the certificate (as described in 3.2) or as part of either as part of the certificate (as described in 3.2) associated
the PKCS #10 attribute list. Certification authorities MUST check that with the message carrying the certificate request or as part of the
the address in the "From:" header matches either of these addresses. certificate request information produced by the subscriber.
CAs SHOULD allow the CA operator to configure processing of messages Certification authorities MUST check that the address in the "From:"
whose addresses do not match. 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 Certification authorities SHOULD support parsing of zero or one
instance of each of the following set of certification-request instance of each of the following set of certification-request
attributes on incoming messages. Attributes that a particular attributes on incoming messages. Attributes that a particular
implementation does not support may generate a warning message to the implementation does not support may generate a warning message to the
requestor, or may be silently ignored. Inclusion of the following requestor, or may be silently ignored. Inclusion of the following
attributes during the creation and submission of a certification- attributes during the creation and submission of a certification-
request will most likely be dictated by the policies associated with request will most likely be dictated by the policies associated with
the certification service which will certify the corresponding name the certification service which will certify the corresponding name
and public key. and public key.
postalAddress postalAddress
challengePassword challengePassword
unstructuredAddress unstructuredAddress
postalAddress is described in [X.520]. postalAddress is described in [X.520].
5.2.1 Challenge Password 5.3.1 Challenge Password
The challenge-password attribute type specifies a password by which an The challenge-password attribute type specifies a password by which an
entity may request certificate revocation. The interpretation of the entity may request certificate revocation. The interpretation of the
password is intended to be specified by the issuer of the certificate; password is intended to be specified by the issuer of the certificate;
no particular interpretation is required. The challenge-password no particular interpretation is required. The challenge-password
attribute type is intended for PKCS #10 certification requests. attribute type is intended for PKCS #10 certification requests.
Challenge-password attribute values have ASN.1 type ChallengePassword: Challenge-password attribute values have ASN.1 type ChallengePassword:
ChallengePassword ::= CHOICE { ChallengePassword ::= CHOICE {
PrintableString, T61String } PrintableString, T61String }
A challenge-password attribute must have a single attribute value. A challenge-password attribute must have a single attribute value.
It is expected that if UCS becomes an ASN.1 type (e.g., UNIVERSAL It is expected that if UCS becomes an ASN.1 type (e.g., UNIVERSAL
STRING), ChallengePassword will become a CHOICE type: STRING), ChallengePassword will become a CHOICE type:
ChallengePassword ::= CHOICE { ChallengePassword ::= CHOICE {
PrintableString, T61String, UNIVERSAL STRING } PrintableString, T61String, UNIVERSAL STRING }
5.2.2 Unstructured Address 5.3.2 Unstructured Address
The unstructured-address attribute type specifies the address or The unstructured-address attribute type specifies the address or
addresses of the subject of a certificate as an unstructured ASCII 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 T.61 string. The interpretation of the addresses is intended to be
specified by the issuer of the certificate; no particular specified by the issuer of the certificate; no particular
interpretation is required. A likely interpretation is as an interpretation is required. A likely interpretation is as an
alternative to the X.520 postalAddress attribute type. The alternative to the X.520 postalAddress attribute type. The
unstructured-address attribute type is intended for PKCS #10 unstructured-address attribute type is intended for PKCS #10
certification requests. certification requests.
skipping to change at line 565 skipping to change at line 802
Note: T.61's newline character (hexadecimal code 0d) is recommended as Note: T.61's newline character (hexadecimal code 0d) is recommended as
a line separator in multi-line addresses. a line separator in multi-line addresses.
It is expected that if UCS becomes an ASN.1 type (e.g., UNIVERSAL It is expected that if UCS becomes an ASN.1 type (e.g., UNIVERSAL
STRING), UnstructuredAddress will become a CHOICE type: STRING), UnstructuredAddress will become a CHOICE type:
UnstructuredAddress ::= CHOICE { UnstructuredAddress ::= CHOICE {
PrintableString, T61String, UNIVERSAL STRING } PrintableString, T61String, UNIVERSAL STRING }
5.3 Fulfilling a Certification Request 5.4 Use of CRMF for Certification Requests
Certification authorities SHOULD use the sha-1WithRSAEncryption Construction of a CRMF-formatted certification request involves the
signature algorithms when signing certificates. following steps:
5.4 Using CMS for Fulfilled Certificate Response 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 [CMS] supports a degenerate case of the SignedData content type where
there are no signers on the content (and hence, the content value is there are no signers on the content (and hence, the content value is
"irrelevant"). This degenerate case is used to convey certificate and "irrelevant"). This degenerate case is used to convey certificate and
CRL information. Certification authorities MUST use this format for CRL information. Certification authorities MUST use this format for
returning certificate information resulting from the successful returning certificate information resulting from the successful
fulfillment of a certification request. At a minimum, the fulfilled fulfillment of a certification request. At a minimum, the fulfilled
certificate response MUST include the actual subject certificate certificate response MUST include the actual subject certificate
(corresponding to the information in the certification request). The (corresponding to the information in the certification request). The
response SHOULD include other certificates which link the issuer to response SHOULD include other certificates which link the issuer to
skipping to change at line 712 skipping to change at line 975
dataEncipherment (3), dataEncipherment (3),
keyAgreement (4), keyAgreement (4),
keyCertSign (5), keyCertSign (5),
cRLSign (6)} cRLSign (6)}
B. References B. References
[CERTV2] "S/MIME Certificate Handling", Internet Draft draft-dusse- [CERTV2] "S/MIME Certificate Handling", Internet Draft draft-dusse-
smime-cert smime-cert
[KEYM] PKIX Part 1. At the time of this writing, PKIX is in Internet [CMS] "Cryptographic Message Syntax", Internet Draft draft-housley-
Draft stage, but it is expected that there will be standards-track smime-cms
RFCs at some point in the future.
[CRMF] "Certificate Request Message Format", Internet Draft draft-ietf-
pkix-crmf
[KEYM] "Internet Public Key Infrastructure X.509 Certificate and CRL
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 [PKCS-10], "PKCS #10: Certification Request Syntax", draft has been
submitted for RFC status submitted for RFC status
skipping to change at line 765 skipping to change at line 1033
Reworded section 4.3 for signing algorithms to MUST id-dsa-with-sha1 Reworded section 4.3 for signing algorithms to MUST id-dsa-with-sha1
and SHOULD all others and SHOULD all others
Changed [SMIME-MSG] to draft-ietf-smime-msg Changed [SMIME-MSG] to draft-ietf-smime-msg
Changed references to PKCS #7 and [PKCS-7] to Cryptographic Message Changed references to PKCS #7 and [PKCS-7] to Cryptographic Message
Specification and [CMS] Specification and [CMS]
Section 2.2 is now "CertificateChoices" instead of Section 2.2 is now "CertificateChoices" instead of
"ExtendedCertificatesOrCertificate" "ExtendedCertificatesOrCertificate"
Section 2.3 is now "CertificateSet" instead of Section 2.3 is now "CertificateSet" instead of
"ExtendedCertificatesAndCertificates" "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 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
Pawling and Jim Schaad.
F. Needed changes F. Needed changes
UNIVERSAL STRING for Challenge Password? Should this simply be UNIVERSAL STRING for Challenge Password? Should this simply be
BMPString? BMPString?
Algorithms for certs Algorithms for certs
Capitalization of OIDs Capitalization of OIDs
Stronger MD2 / MD5 language needed? Stronger MD2 / MD5 language needed?
Names for chaining Names for chaining
Only one "official" email address? 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?
Attribute certificates? Section A.7 -- bit 7 is encipherOnly, bit 8 is decipherOnly. Are we
going to use these?
G. Editor's address G. Changes from last draft
Added section G, changes from last draft
Added attribute certificate definition in section 1.1, text from John
Pawling
Added attribute certificate SHOULD support in section 2.2 text from
John Pawling
Added attribute certificate SHOULD support in section 2.3 text from
John Pawling
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
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/