< draft-ietf-pkix-rfc3280bis-10.txt   draft-ietf-pkix-rfc3280bis-11.txt >
Network Working Group D. Cooper Network Working Group D. Cooper
Internet-Draft NIST Internet-Draft NIST
Obsoletes: 3280, 4325, 4630 (if approved) S. Santesson Obsoletes: 3280, 4325, 4630 (if approved) S. Santesson
Expires: June 2008 Microsoft Expires: August 2008 Microsoft
S. Farrell S. Farrell
Trinity College Dublin Trinity College Dublin
S. Boeyen S. Boeyen
Entrust Entrust
R. Housley R. Housley
Vigil Security Vigil Security
W. Polk W. Polk
NIST NIST
December 19, 2007 February 4, 2008
Internet X.509 Public Key Infrastructure Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile Certificate and Certificate Revocation List (CRL) Profile
draft-ietf-pkix-rfc3280bis-10.txt draft-ietf-pkix-rfc3280bis-11.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 46 skipping to change at page 1, line 46
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html. http://www.ietf.org/1id-abstracts.html.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This memo profiles the X.509 v3 certificate and X.509 v2 certificate This memo profiles the X.509 v3 certificate and X.509 v2 certificate
revocation list (CRL) for use in the Internet. An overview of this revocation list (CRL) for use in the Internet. An overview of this
approach and model are provided as an introduction. The X.509 v3 approach and model are provided as an introduction. The X.509 v3
certificate format is described in detail, with additional certificate format is described in detail, with additional
information regarding the format and semantics of Internet name information regarding the format and semantics of Internet name
forms. Standard certificate extensions are described and two forms. Standard certificate extensions are described and two
Internet-specific extensions are defined. A set of required Internet-specific extensions are defined. A set of required
skipping to change at page 2, line 34 skipping to change at page 2, line 34
3 Overview of Approach . . . . . . . . . . . . . . . . . . 8 3 Overview of Approach . . . . . . . . . . . . . . . . . . 8
3.1 X.509 Version 3 Certificate . . . . . . . . . . . . . . 9 3.1 X.509 Version 3 Certificate . . . . . . . . . . . . . . 9
3.2 Certification Paths and Trust . . . . . . . . . . . . . 11 3.2 Certification Paths and Trust . . . . . . . . . . . . . 11
3.3 Revocation . . . . . . . . . . . . . . . . . . . . . . 13 3.3 Revocation . . . . . . . . . . . . . . . . . . . . . . 13
3.4 Operational Protocols . . . . . . . . . . . . . . . . . 14 3.4 Operational Protocols . . . . . . . . . . . . . . . . . 14
3.5 Management Protocols . . . . . . . . . . . . . . . . . 14 3.5 Management Protocols . . . . . . . . . . . . . . . . . 14
4 Certificate and Certificate Extensions Profile . . . . . 16 4 Certificate and Certificate Extensions Profile . . . . . 16
4.1 Basic Certificate Fields . . . . . . . . . . . . . . . 16 4.1 Basic Certificate Fields . . . . . . . . . . . . . . . 16
4.1.1 Certificate Fields . . . . . . . . . . . . . . . . . 17 4.1.1 Certificate Fields . . . . . . . . . . . . . . . . . 17
4.1.1.1 tbsCertificate . . . . . . . . . . . . . . . . . . 17 4.1.1.1 tbsCertificate . . . . . . . . . . . . . . . . . . 17
4.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . 17 4.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . 18
4.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . 18 4.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . 18
4.1.2 TBSCertificate . . . . . . . . . . . . . . . . . . . 18 4.1.2 TBSCertificate . . . . . . . . . . . . . . . . . . . 18
4.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . 18 4.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . 19
4.1.2.2 Serial number . . . . . . . . . . . . . . . . . . . 19 4.1.2.2 Serial number . . . . . . . . . . . . . . . . . . . 19
4.1.2.3 Signature . . . . . . . . . . . . . . . . . . . . . 19 4.1.2.3 Signature . . . . . . . . . . . . . . . . . . . . . 19
4.1.2.4 Issuer . . . . . . . . . . . . . . . . . . . . . . 19 4.1.2.4 Issuer . . . . . . . . . . . . . . . . . . . . . . 20
4.1.2.5 Validity . . . . . . . . . . . . . . . . . . . . . 22 4.1.2.5 Validity . . . . . . . . . . . . . . . . . . . . . 22
4.1.2.5.1 UTCTime . . . . . . . . . . . . . . . . . . . . . 22 4.1.2.5.1 UTCTime . . . . . . . . . . . . . . . . . . . . . 23
4.1.2.5.2 GeneralizedTime . . . . . . . . . . . . . . . . . 23 4.1.2.5.2 GeneralizedTime . . . . . . . . . . . . . . . . . 23
4.1.2.6 Subject . . . . . . . . . . . . . . . . . . . . . . 23 4.1.2.6 Subject . . . . . . . . . . . . . . . . . . . . . . 23
4.1.2.7 Subject Public Key Info . . . . . . . . . . . . . . 25 4.1.2.7 Subject Public Key Info . . . . . . . . . . . . . . 25
4.1.2.8 Unique Identifiers . . . . . . . . . . . . . . . . 25 4.1.2.8 Unique Identifiers . . . . . . . . . . . . . . . . 25
4.1.2.9 Extensions . . . . . . . . . . . . . . . . . . . . 25 4.1.2.9 Extensions . . . . . . . . . . . . . . . . . . . . 25
4.2 Certificate Extensions . . . . . . . . . . . . . . . . 25 4.2 Certificate Extensions . . . . . . . . . . . . . . . . 26
4.2.1 Standard Extensions . . . . . . . . . . . . . . . . . 26 4.2.1 Standard Extensions . . . . . . . . . . . . . . . . . 27
4.2.1.1 Authority Key Identifier . . . . . . . . . . . . . 27 4.2.1.1 Authority Key Identifier . . . . . . . . . . . . . 27
4.2.1.2 Subject Key Identifier . . . . . . . . . . . . . . 28 4.2.1.2 Subject Key Identifier . . . . . . . . . . . . . . 28
4.2.1.3 Key Usage . . . . . . . . . . . . . . . . . . . . . 29 4.2.1.3 Key Usage . . . . . . . . . . . . . . . . . . . . . 29
4.2.1.4 Certificate Policies . . . . . . . . . . . . . . . 31 4.2.1.4 Certificate Policies . . . . . . . . . . . . . . . 31
4.2.1.5 Policy Mappings . . . . . . . . . . . . . . . . . . 34 4.2.1.5 Policy Mappings . . . . . . . . . . . . . . . . . . 34
4.2.1.6 Subject Alternative Name . . . . . . . . . . . . . 34 4.2.1.6 Subject Alternative Name . . . . . . . . . . . . . 35
4.2.1.7 Issuer Alternative Name . . . . . . . . . . . . . . 37 4.2.1.7 Issuer Alternative Name . . . . . . . . . . . . . . 38
4.2.1.8 Subject Directory Attributes . . . . . . . . . . . 38 4.2.1.8 Subject Directory Attributes . . . . . . . . . . . 38
4.2.1.9 Basic Constraints . . . . . . . . . . . . . . . . . 38 4.2.1.9 Basic Constraints . . . . . . . . . . . . . . . . . 38
4.2.1.10 Name Constraints . . . . . . . . . . . . . . . . . 39 4.2.1.10 Name Constraints . . . . . . . . . . . . . . . . . 39
4.2.1.11 Policy Constraints . . . . . . . . . . . . . . . . 42 4.2.1.11 Policy Constraints . . . . . . . . . . . . . . . . 42
4.2.1.12 Extended Key Usage . . . . . . . . . . . . . . . . 43 4.2.1.12 Extended Key Usage . . . . . . . . . . . . . . . . 43
4.2.1.13 CRL Distribution Points . . . . . . . . . . . . . 44 4.2.1.13 CRL Distribution Points . . . . . . . . . . . . . 45
4.2.1.14 Inhibit anyPolicy . . . . . . . . . . . . . . . . 47 4.2.1.14 Inhibit anyPolicy . . . . . . . . . . . . . . . . 47
4.2.1.15 Freshest CRL . . . . . . . . . . . . . . . . . . . 47 4.2.1.15 Freshest CRL . . . . . . . . . . . . . . . . . . . 47
4.2.2 Private Internet Extensions . . . . . . . . . . . . . 47 4.2.2 Private Internet Extensions . . . . . . . . . . . . . 48
4.2.2.1 Authority Information Access . . . . . . . . . . . 48 4.2.2.1 Authority Information Access . . . . . . . . . . . 48
4.2.2.2 Subject Information Access . . . . . . . . . . . . 50 4.2.2.2 Subject Information Access . . . . . . . . . . . . 51
5 CRL and CRL Extensions Profile . . . . . . . . . . . . . 52 5 CRL and CRL Extensions Profile . . . . . . . . . . . . . 53
5.1 CRL Fields . . . . . . . . . . . . . . . . . . . . . . 54 5.1 CRL Fields . . . . . . . . . . . . . . . . . . . . . . 54
5.1.1 CertificateList Fields . . . . . . . . . . . . . . . 55 5.1.1 CertificateList Fields . . . . . . . . . . . . . . . 55
5.1.1.1 tbsCertList . . . . . . . . . . . . . . . . . . . . 55 5.1.1.1 tbsCertList . . . . . . . . . . . . . . . . . . . . 55
5.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . 55 5.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . 56
5.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . 55 5.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . 56
5.1.2 Certificate List "To Be Signed" . . . . . . . . . . . 56 5.1.2 Certificate List "To Be Signed" . . . . . . . . . . . 56
5.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . 56 5.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . 57
5.1.2.2 Signature . . . . . . . . . . . . . . . . . . . . . 56 5.1.2.2 Signature . . . . . . . . . . . . . . . . . . . . . 57
5.1.2.3 Issuer Name . . . . . . . . . . . . . . . . . . . . 57 5.1.2.3 Issuer Name . . . . . . . . . . . . . . . . . . . . 57
5.1.2.4 This Update . . . . . . . . . . . . . . . . . . . . 57 5.1.2.4 This Update . . . . . . . . . . . . . . . . . . . . 57
5.1.2.5 Next Update . . . . . . . . . . . . . . . . . . . . 57 5.1.2.5 Next Update . . . . . . . . . . . . . . . . . . . . 58
5.1.2.6 Revoked Certificates . . . . . . . . . . . . . . . 58 5.1.2.6 Revoked Certificates . . . . . . . . . . . . . . . 58
5.1.2.7 Extensions . . . . . . . . . . . . . . . . . . . . 58 5.1.2.7 Extensions . . . . . . . . . . . . . . . . . . . . 58
5.2 CRL Extensions . . . . . . . . . . . . . . . . . . . . 58 5.2 CRL Extensions . . . . . . . . . . . . . . . . . . . . 59
5.2.1 Authority Key Identifier . . . . . . . . . . . . . . 58 5.2.1 Authority Key Identifier . . . . . . . . . . . . . . 59
5.2.2 Issuer Alternative Name . . . . . . . . . . . . . . . 59 5.2.2 Issuer Alternative Name . . . . . . . . . . . . . . . 59
5.2.3 CRL Number . . . . . . . . . . . . . . . . . . . . . 59 5.2.3 CRL Number . . . . . . . . . . . . . . . . . . . . . 60
5.2.4 Delta CRL Indicator . . . . . . . . . . . . . . . . . 60 5.2.4 Delta CRL Indicator . . . . . . . . . . . . . . . . . 60
5.2.5 Issuing Distribution Point . . . . . . . . . . . . . 63 5.2.5 Issuing Distribution Point . . . . . . . . . . . . . 63
5.2.6 Freshest CRL . . . . . . . . . . . . . . . . . . . . 65 5.2.6 Freshest CRL . . . . . . . . . . . . . . . . . . . . 65
5.2.7 Authority Information Access . . . . . . . . . . . . 65 5.2.7 Authority Information Access . . . . . . . . . . . . 66
5.3 CRL Entry Extensions . . . . . . . . . . . . . . . . . 66 5.3 CRL Entry Extensions . . . . . . . . . . . . . . . . . 67
5.3.1 Reason Code . . . . . . . . . . . . . . . . . . . . . 67 5.3.1 Reason Code . . . . . . . . . . . . . . . . . . . . . 68
5.3.2 Invalidity Date . . . . . . . . . . . . . . . . . . . 68 5.3.2 Invalidity Date . . . . . . . . . . . . . . . . . . . 68
5.3.3 Certificate Issuer . . . . . . . . . . . . . . . . . 68 5.3.3 Certificate Issuer . . . . . . . . . . . . . . . . . 69
6 Certification Path Validation . . . . . . . . . . . . . . 69 6 Certification Path Validation . . . . . . . . . . . . . . 69
6.1 Basic Path Validation . . . . . . . . . . . . . . . . . 69 6.1 Basic Path Validation . . . . . . . . . . . . . . . . . 70
6.1.1 Inputs . . . . . . . . . . . . . . . . . . . . . . . 72 6.1.1 Inputs . . . . . . . . . . . . . . . . . . . . . . . 73
6.1.2 Initialization . . . . . . . . . . . . . . . . . . . 74 6.1.2 Initialization . . . . . . . . . . . . . . . . . . . 75
6.1.3 Basic Certificate Processing . . . . . . . . . . . . 77 6.1.3 Basic Certificate Processing . . . . . . . . . . . . 77
6.1.4 Preparation for Certificate i+1 . . . . . . . . . . . 81 6.1.4 Preparation for Certificate i+1 . . . . . . . . . . . 82
6.1.5 Wrap-up procedure . . . . . . . . . . . . . . . . . . 84 6.1.5 Wrap-up procedure . . . . . . . . . . . . . . . . . . 85
6.1.6 Outputs . . . . . . . . . . . . . . . . . . . . . . . 86 6.1.6 Outputs . . . . . . . . . . . . . . . . . . . . . . . 87
6.2 Using the Path Validation Algorithm . . . . . . . . . . 86 6.2 Using the Path Validation Algorithm . . . . . . . . . . 87
6.3 CRL Validation . . . . . . . . . . . . . . . . . . . . 87 6.3 CRL Validation . . . . . . . . . . . . . . . . . . . . 88
6.3.1 Revocation Inputs . . . . . . . . . . . . . . . . . . 87 6.3.1 Revocation Inputs . . . . . . . . . . . . . . . . . . 88
6.3.2 Initialization and Revocation State Variables . . . . 87 6.3.2 Initialization and Revocation State Variables . . . . 88
6.3.3 CRL Processing . . . . . . . . . . . . . . . . . . . 88 6.3.3 CRL Processing . . . . . . . . . . . . . . . . . . . 89
7 Processing Rules for Internationalized Names . . . . . . 91 7 Processing Rules for Internationalized Names . . . . . . 92
7.1 Internationalized Names in Distinguished Names . . . . 92 7.1 Internationalized Names in Distinguished Names . . . . 93
7.2 Internationalized Domain Names in GeneralName . . . . . 93 7.2 Internationalized Domain Names in GeneralName . . . . . 94
7.3 Internationalized Domain Names in Distinguished Names . 94 7.3 Internationalized Domain Names in Distinguished Names . 95
7.4 Internationalized Resource Identifiers . . . . . . . . 94 7.4 Internationalized Resource Identifiers . . . . . . . . 95
7.5 Internationalized Electronic Mail Addresses . . . . . . 96 7.5 Internationalized Electronic Mail Addresses . . . . . . 97
8 References . . . . . . . . . . . . . . . . . . . . . . . 96 8 References . . . . . . . . . . . . . . . . . . . . . . . 97
9 Intellectual Property Rights . . . . . . . . . . . . . . 101 9 Intellectual Property Rights . . . . . . . . . . . . . . 102
10 Security Considerations . . . . . . . . . . . . . . . . 101 10 Security Considerations . . . . . . . . . . . . . . . . 102
11 IANA Considerations . . . . . . . . . . . . . . . . . . 106 11 IANA Considerations . . . . . . . . . . . . . . . . . . 107
12 Authors' Addresses . . . . . . . . . . . . . . . . . . . 106 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . 107
13 Acknowledgments . . . . . . . . . . . . . . . . . . . . 107 13 Acknowledgments . . . . . . . . . . . . . . . . . . . . 108
Appendix A. Pseudo-ASN.1 Structures and OIDs . . . . . . . 107 Appendix A. Pseudo-ASN.1 Structures and OIDs . . . . . . . 108
A.1 Explicitly Tagged Module, 1988 Syntax . . . . . . . . . 107 A.1 Explicitly Tagged Module, 1988 Syntax . . . . . . . . . 108
A.2 Implicitly Tagged Module, 1988 Syntax . . . . . . . . . 121 A.2 Implicitly Tagged Module, 1988 Syntax . . . . . . . . . 122
Appendix B. ASN.1 Notes . . . . . . . . . . . . . . . . . . 128 Appendix B. ASN.1 Notes . . . . . . . . . . . . . . . . . . 129
Appendix C. Examples . . . . . . . . . . . . . . . . . . . 131 Appendix C. Examples . . . . . . . . . . . . . . . . . . . 132
C.1 RSA Self-Signed Certificate . . . . . . . . . . . . . . 132 C.1 RSA Self-Signed Certificate . . . . . . . . . . . . . . 133
C.2 End Entity Certificate Using RSA . . . . . . . . . . . 135 C.2 End Entity Certificate Using RSA . . . . . . . . . . . 136
C.3 End Entity Certificate Using DSA . . . . . . . . . . . 138 C.3 End Entity Certificate Using DSA . . . . . . . . . . . 139
C.4 Certificate Revocation List . . . . . . . . . . . . . . 142 C.4 Certificate Revocation List . . . . . . . . . . . . . . 143
Full Copyright Statement . . . . . . . . . . . . . . . . . . 144 Full Copyright Statement . . . . . . . . . . . . . . . . . . 145
1 Introduction 1 Introduction
This specification is one part of a family of standards for the X.509 This specification is one part of a family of standards for the X.509
Public Key Infrastructure (PKI) for the Internet. Public Key Infrastructure (PKI) for the Internet.
This specification profiles the format and semantics of certificates This specification profiles the format and semantics of certificates
and certificate revocation lists (CRLs) for the Internet PKI. and certificate revocation lists (CRLs) for the Internet PKI.
Procedures are described for processing of certification paths in the Procedures are described for processing of certification paths in the
Internet environment. Finally, ASN.1 modules are provided in the Internet environment. Finally, ASN.1 modules are provided in the
skipping to change at page 17, line 32 skipping to change at page 17, line 32
SubjectPublicKeyInfo ::= SEQUENCE { SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier, algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING } subjectPublicKey BIT STRING }
Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
Extension ::= SEQUENCE { Extension ::= SEQUENCE {
extnID OBJECT IDENTIFIER, extnID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE, critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING } extnValue OCTET STRING
-- contains the DER encoding of an ASN.1 value
-- corresponding to the extension type identified
-- by extnID
}
The following items describe the X.509 v3 certificate for use in the The following items describe the X.509 v3 certificate for use in the
Internet. Internet.
4.1.1 Certificate Fields 4.1.1 Certificate Fields
The Certificate is a SEQUENCE of three required fields. The fields The Certificate is a SEQUENCE of three required fields. The fields
are described in detail in the following subsections. are described in detail in the following subsections.
4.1.1.1 tbsCertificate 4.1.1.1 tbsCertificate
skipping to change at page 24, line 48 skipping to change at page 25, line 7
(c) TeletexString, BMPString, and UniversalString are included (c) TeletexString, BMPString, and UniversalString are included
for backward compatibility, and SHOULD NOT be used for for backward compatibility, and SHOULD NOT be used for
certificates for new subjects. However, these types MAY be used certificates for new subjects. However, these types MAY be used
in certificates where the name was previously established, in certificates where the name was previously established,
including cases in which a new certificate is being issued to an including cases in which a new certificate is being issued to an
existing subject or a certificate is being issued to a new subject existing subject or a certificate is being issued to a new subject
where the attributes being encoded have been previously where the attributes being encoded have been previously
established in certificates issued to other subjects. Certificate established in certificates issued to other subjects. Certificate
users SHOULD be prepared to receive certificates with these types. users SHOULD be prepared to receive certificates with these types.
Legacy implementations exist where an RFC 822 name is embedded in the Legacy implementations exist where an electronic mail address is
subject distinguished name as an emailAddress attribute [RFC 2985]. embedded in the subject distinguished name as an emailAddress
The attribute value for emailAddress is of type IA5String to permit attribute [RFC 2985]. The attribute value for emailAddress is of
inclusion of the character '@', which is not part of the type IA5String to permit inclusion of the character '@', which is not
PrintableString character set. emailAddress attribute values are not part of the PrintableString character set. emailAddress attribute
case-sensitive (e.g., "subscriber@example.com" is the same as values are not case-sensitive (e.g., "subscriber@example.com" is the
"SUBSCRIBER@EXAMPLE.COM"). same as "SUBSCRIBER@EXAMPLE.COM").
Conforming implementations generating new certificates with Conforming implementations generating new certificates with
electronic mail addresses MUST use the rfc822Name in the subject electronic mail addresses MUST use the rfc822Name in the subject
alternative name extension (section 4.2.1.6) to describe such alternative name extension (section 4.2.1.6) to describe such
identities. Simultaneous inclusion of the emailAddress attribute in identities. Simultaneous inclusion of the emailAddress attribute in
the subject distinguished name to support legacy implementations is the subject distinguished name to support legacy implementations is
deprecated but permitted. deprecated but permitted.
4.1.2.7 Subject Public Key Info 4.1.2.7 Subject Public Key Info
skipping to change at page 26, line 18 skipping to change at page 26, line 26
extension MAY be ignored if it is not recognized, but MUST be extension MAY be ignored if it is not recognized, but MUST be
processed if it is recognized. The following sections present processed if it is recognized. The following sections present
recommended extensions used within Internet certificates and standard recommended extensions used within Internet certificates and standard
locations for information. Communities may elect to use additional locations for information. Communities may elect to use additional
extensions; however, caution ought to be exercised in adopting any extensions; however, caution ought to be exercised in adopting any
critical extensions in certificates that might prevent use in a critical extensions in certificates that might prevent use in a
general context. general context.
Each extension includes an OID and an ASN.1 structure. When an Each extension includes an OID and an ASN.1 structure. When an
extension appears in a certificate, the OID appears as the field extension appears in a certificate, the OID appears as the field
extnID and the corresponding ASN.1 encoded structure is the value of extnID and the corresponding ASN.1 DER encoded structure is the value
the octet string extnValue. A certificate MUST NOT include more than of the octet string extnValue. A certificate MUST NOT include more
one instance of a particular extension. For example, a certificate than one instance of a particular extension. For example, a
may contain only one authority key identifier extension (section certificate may contain only one authority key identifier extension
4.2.1.1). An extension includes the boolean critical, with a default (section 4.2.1.1). An extension includes the boolean critical, with
value of FALSE. The text for each extension specifies the acceptable a default value of FALSE. The text for each extension specifies the
values for the critical field for CAs conforming to this profile. acceptable values for the critical field for CAs conforming to this
profile.
Conforming CAs MUST support key identifiers (sections 4.2.1.1 and Conforming CAs MUST support key identifiers (sections 4.2.1.1 and
4.2.1.2), basic constraints (section 4.2.1.9), key usage (section 4.2.1.2), basic constraints (section 4.2.1.9), key usage (section
4.2.1.3), and certificate policies (section 4.2.1.4) extensions. If 4.2.1.3), and certificate policies (section 4.2.1.4) extensions. If
the CA issues certificates with an empty sequence for the subject the CA issues certificates with an empty sequence for the subject
field, the CA MUST support the subject alternative name extension field, the CA MUST support the subject alternative name extension
(section 4.2.1.6). Support for the remaining extensions is OPTIONAL. (section 4.2.1.6). Support for the remaining extensions is OPTIONAL.
Conforming CAs MAY support extensions that are not identified within Conforming CAs MAY support extensions that are not identified within
this specification; certificate issuers are cautioned that marking this specification; certificate issuers are cautioned that marking
such extensions as critical may inhibit interoperability. such extensions as critical may inhibit interoperability.
skipping to change at page 32, line 43 skipping to change at page 33, line 4
implementation, the application software will have a notice file implementation, the application software will have a notice file
containing the current set of notices for CertsRUs; the containing the current set of notices for CertsRUs; the
application will extract the notice text from the file and display application will extract the notice text from the file and display
it. Messages MAY be multilingual, allowing the software to select it. Messages MAY be multilingual, allowing the software to select
the particular language message for its own environment. the particular language message for its own environment.
An explicitText field includes the textual statement directly in An explicitText field includes the textual statement directly in
the certificate. The explicitText field is a string with a the certificate. The explicitText field is a string with a
maximum size of 200 characters. Conforming CAs SHOULD use the maximum size of 200 characters. Conforming CAs SHOULD use the
UTF8String encoding for explicitText, but MAY use IA5String. UTF8String encoding for explicitText, but MAY use IA5String.
Conforming CAs MUST NOT encode explicitText as VisibleString or Conforming CAs MUST NOT encode explicitText as VisibleString or
BMPString. BMPString. The explicitText string SHOULD NOT include any control
characters (e.g., U+0000 to U+001F and U+007F to U+009F). When
the UTF8String encoding is used, all character sequences SHOULD be
normalized according to Unicode normalization form C (NFC) [NFC].
If both the noticeRef and explicitText options are included in the If both the noticeRef and explicitText options are included in the
one qualifier and if the application software can locate the notice one qualifier and if the application software can locate the notice
text indicated by the noticeRef option, then that text SHOULD be text indicated by the noticeRef option, then that text SHOULD be
displayed; otherwise, the explicitText string SHOULD be displayed. displayed; otherwise, the explicitText string SHOULD be displayed.
Note: While the explicitText has a maximum size of 200 characters, Note: While the explicitText has a maximum size of 200 characters,
some non-conforming CAs exceed this limit. Therefore, certificate some non-conforming CAs exceed this limit. Therefore, certificate
users SHOULD gracefully handle explicitText with more than 200 users SHOULD gracefully handle explicitText with more than 200
characters. characters.
skipping to change at page 35, line 9 skipping to change at page 35, line 25
The subject alternative name extension allows identities to be bound The subject alternative name extension allows identities to be bound
to the subject of the certificate. These identities may be included to the subject of the certificate. These identities may be included
in addition to or in place of the identity in the subject field of in addition to or in place of the identity in the subject field of
the certificate. Defined options include an Internet electronic mail the certificate. Defined options include an Internet electronic mail
address, a DNS name, an IP address, and a uniform resource identifier address, a DNS name, an IP address, and a uniform resource identifier
(URI). Other options exist, including completely local definitions. (URI). Other options exist, including completely local definitions.
Multiple name forms, and multiple instances of each name form, MAY be Multiple name forms, and multiple instances of each name form, MAY be
included. Whenever such identities are to be bound into a included. Whenever such identities are to be bound into a
certificate, the subject alternative name (or issuer alternative certificate, the subject alternative name (or issuer alternative
name) extension MUST be used; however, a DNS name MAY be represented name) extension MUST be used; however, a DNS name MAY also be
in the subject field using the domainComponent attribute as described represented in the subject field using the domainComponent attribute
in section 4.1.2.4. as described in section 4.1.2.4. Note that where such names are
represented in the subject field implementations are not required to
convert them into DNS names.
Because the subject alternative name is considered to be definitively Because the subject alternative name is considered to be definitively
bound to the public key, all parts of the subject alternative name bound to the public key, all parts of the subject alternative name
MUST be verified by the CA. MUST be verified by the CA.
Further, if the only subject identity included in the certificate is Further, if the only subject identity included in the certificate is
an alternative name form (e.g., an electronic mail address), then the an alternative name form (e.g., an electronic mail address), then the
subject distinguished name MUST be empty (an empty sequence), and the subject distinguished name MUST be empty (an empty sequence), and the
subjectAltName extension MUST be present. If the subject field subjectAltName extension MUST be present. If the subject field
contains an empty sequence, then the issuing CA MUST include a contains an empty sequence, then the issuing CA MUST include a
subjectAltName extension that is marked as critical. When including subjectAltName extension that is marked as critical. When including
the subjectAltName extension in a certificate that has a non-empty the subjectAltName extension in a certificate that has a non-empty
subject distinguished name, conforming CAs SHOULD mark the subject distinguished name, conforming CAs SHOULD mark the
subjectAltName extension as non-critical. subjectAltName extension as non-critical.
When the subjectAltName extension contains an Internet mail address, When the subjectAltName extension contains an Internet mail address,
the address MUST be stored in the rfc822Name. The format of an the address MUST be stored in the rfc822Name. The format of an
rfc822Name is an "addr-spec" as defined in [RFC 2822]. An addr-spec rfc822Name is a "Mailbox" as defined in section 4.1.2 of [RFC 2821].
has the form "local-part@domain". Note that an addr-spec has no A Mailbox has the form "Local-part@Domain". Note that a Mailbox has
phrase (such as a common name) before it, has no comment (text no phrase (such as a common name) before it, has no comment (text
surrounded in parentheses) after it, and is not surrounded by "<" and surrounded in parentheses) after it, and is not surrounded by "<" and
">". Rules for encoding Internet mail addresses that include ">". Rules for encoding Internet mail addresses that include
internationalized domain names are specified in section 7.5. internationalized domain names are specified in section 7.5.
When the subjectAltName extension contains a iPAddress, the address When the subjectAltName extension contains a iPAddress, the address
MUST be stored in the octet string in "network byte order," as MUST be stored in the octet string in "network byte order," as
specified in [RFC 791]. The least significant bit (LSB) of each specified in [RFC 791]. The least significant bit (LSB) of each
octet is the LSB of the corresponding byte in the network address. octet is the LSB of the corresponding byte in the network address.
For IP Version 4, as specified in RFC 791, the octet string MUST For IP Version 4, as specified in RFC 791, the octet string MUST
contain exactly four octets. For IP Version 6, as specified in contain exactly four octets. For IP Version 6, as specified in
[RFC 2460], the octet string MUST contain exactly sixteen octets. [RFC 2460], the octet string MUST contain exactly sixteen octets.
When the subjectAltName extension contains a domain name system When the subjectAltName extension contains a domain name system
label, the domain name MUST be stored in the dNSName (an IA5String). label, the domain name MUST be stored in the dNSName (an IA5String).
The name MUST be in the "preferred name syntax," as specified by The name MUST be in the "preferred name syntax," as specified by
[RFC 1034]. Note that while upper and lower case letters are allowed section 3.5 of [RFC 1034] and as modified by section 2.1 of
[RFC 1123]. Note that while upper and lower case letters are allowed
in domain names, no significance is attached to the case. In in domain names, no significance is attached to the case. In
addition, while the string " " is a legal domain name, subjectAltName addition, while the string " " is a legal domain name, subjectAltName
extensions with a dNSName of " " MUST NOT be used. Finally, the use extensions with a dNSName of " " MUST NOT be used. Finally, the use
of the DNS representation for Internet mail addresses of the DNS representation for Internet mail addresses
(subscriber.example.com instead of subscriber@example.com) MUST NOT (subscriber.example.com instead of subscriber@example.com) MUST NOT
be used; such identities are to be encoded as rfc822Name. Rules for be used; such identities are to be encoded as rfc822Name. Rules for
encoding internationalized domain names are specified in section 7.2. encoding internationalized domain names are specified in section 7.2.
When the subjectAltName extension contains a URI, the name MUST be When the subjectAltName extension contains a URI, the name MUST be
stored in the uniformResourceIdentifier (an IA5String). The name stored in the uniformResourceIdentifier (an IA5String). The name
skipping to change at page 40, line 50 skipping to change at page 41, line 17
URIs). For example, ".example.com" indicates all the Internet mail URIs). For example, ".example.com" indicates all the Internet mail
addresses in the domain "example.com", but not Internet mail addresses in the domain "example.com", but not Internet mail
addresses on the host "example.com". addresses on the host "example.com".
DNS name restrictions are expressed as host.example.com. Any DNS DNS name restrictions are expressed as host.example.com. Any DNS
name that can be constructed by simply adding zero or more subdomains name that can be constructed by simply adding zero or more subdomains
to the left hand side of the name satisfies the name constraint. For to the left hand side of the name satisfies the name constraint. For
example, www.host.example.com would satisfy the constraint but example, www.host.example.com would satisfy the constraint but
host1.example.com would not. host1.example.com would not.
Legacy implementations exist where an RFC 822 name is embedded in the Legacy implementations exist where an electronic mail address is
subject distinguished name in an attribute of type emailAddress embedded in the subject distinguished name in an attribute of type
(section 4.1.2.6). When RFC 822 names are constrained, but the emailAddress (section 4.1.2.6). When constraints are imposed on the
certificate does not include a subject alternative name, the RFC 822 rfc822Name name form, but the certificate does not include a subject
name constraint MUST be applied to the attribute of type emailAddress alternative name, the rfc822Name constraint MUST be applied to the
in the subject distinguished name. The ASN.1 syntax for emailAddress attribute of type emailAddress in the subject distinguished name.
and the corresponding OID are supplied in appendix A. The ASN.1 syntax for emailAddress and the corresponding OID are
supplied in appendix A.
Restrictions of the form directoryName MUST be applied to the subject Restrictions of the form directoryName MUST be applied to the subject
field in the certificate (when the certificate includes a non-empty field in the certificate (when the certificate includes a non-empty
subject field) and to any names of type directoryName in the subject field) and to any names of type directoryName in the
subjectAltName extension. Restrictions of the form x400Address MUST subjectAltName extension. Restrictions of the form x400Address MUST
be applied to any names of type x400Address in the subjectAltName be applied to any names of type x400Address in the subjectAltName
extension. extension.
When applying restrictions of the form directoryName, an When applying restrictions of the form directoryName, an
implementation MUST compare DN attributes. At a minimum, implementation MUST compare DN attributes. At a minimum,
skipping to change at page 59, line 16 skipping to change at page 59, line 45
Conforming CRL issuers MUST use the key identifier method, and MUST Conforming CRL issuers MUST use the key identifier method, and MUST
include this extension in all CRLs issued. include this extension in all CRLs issued.
The syntax for this CRL extension is defined in section 4.2.1.1. The syntax for this CRL extension is defined in section 4.2.1.1.
5.2.2 Issuer Alternative Name 5.2.2 Issuer Alternative Name
The issuer alternative name extension allows additional identities to The issuer alternative name extension allows additional identities to
be associated with the issuer of the CRL. Defined options include an be associated with the issuer of the CRL. Defined options include an
RFC 822 name (electronic mail address), a DNS name, an IP address, electronic mail address (rfc822Name), a DNS name, an IP address, and
and a URI. Multiple instances of a name form and multiple name forms a URI. Multiple instances of a name form and multiple name forms may
may be included. Whenever such identities are used, the issuer be included. Whenever such identities are used, the issuer
alternative name extension MUST be used; however, a DNS name MAY be alternative name extension MUST be used; however, a DNS name MAY be
represented in the issuer field using the domainComponent attribute represented in the issuer field using the domainComponent attribute
as described in section 4.1.2.4. as described in section 4.1.2.4.
Conforming CRL issuers SHOULD mark the issuerAltName extension non- Conforming CRL issuers SHOULD mark the issuerAltName extension non-
critical. critical.
The OID and syntax for this CRL extension are defined in section The OID and syntax for this CRL extension are defined in section
4.2.1.7. 4.2.1.7.
skipping to change at page 78, line 4 skipping to change at page 78, line 48
policy information by performing the following steps in order: policy information by performing the following steps in order:
(1) For each policy P not equal to anyPolicy in the (1) For each policy P not equal to anyPolicy in the
certificate policies extension, let P-OID denote the OID for certificate policies extension, let P-OID denote the OID for
policy P and P-Q denote the qualifier set for policy P. policy P and P-Q denote the qualifier set for policy P.
Perform the following steps in order: Perform the following steps in order:
(i) For each node of depth i-1 in the valid_policy_tree (i) For each node of depth i-1 in the valid_policy_tree
where P-OID is in the expected_policy_set, create a child where P-OID is in the expected_policy_set, create a child
node as follows: set the valid_policy to P-OID; set the node as follows: set the valid_policy to P-OID; set the
qualifier_set to P-Q, and set the expected_policy_set to {P- qualifier_set to P-Q, and set the expected_policy_set to
OID}. {P-OID}.
For example, consider a valid_policy_tree with a node of For example, consider a valid_policy_tree with a node of
depth i-1 where the expected_policy_set is {Gold, White}. depth i-1 where the expected_policy_set is {Gold, White}.
Assume the certificate policies Gold and Silver appear in Assume the certificate policies Gold and Silver appear in
the certificate policies extension of certificate i. The the certificate policies extension of certificate i. The
Gold policy is matched but the Silver policy is not. This Gold policy is matched but the Silver policy is not. This
rule will generate a child node of depth i for the Gold rule will generate a child node of depth i for the Gold
policy. The result is shown as Figure 4. policy. The result is shown as Figure 4.
+-----------------+ +-----------------+
skipping to change at page 96, line 6 skipping to change at page 97, line 8
* Step 5: If recognized, the implementation MUST perform scheme- * Step 5: If recognized, the implementation MUST perform scheme-
based normalization as specified in section 5.3.3 of [RFC 3987]. based normalization as specified in section 5.3.3 of [RFC 3987].
Conforming implementations MUST recognize and perform scheme-based Conforming implementations MUST recognize and perform scheme-based
normalization for the following schemes: ldap, http, https, and ftp. normalization for the following schemes: ldap, http, https, and ftp.
If the scheme is not recognized, Step (5) is omitted. If the scheme is not recognized, Step (5) is omitted.
When comparing URIs for equivalence, conforming implementations shall When comparing URIs for equivalence, conforming implementations shall
perform a case-sensitive exact match. perform a case-sensitive exact match.
Implementations should convert IRIs to Unicode before display. Implementations should convert URIs to Unicode before display.
Specifically, conforming implementations should perform the Specifically, conforming implementations should perform the
conversion operation specified in section 3.2 of [RFC 3987]. conversion operation specified in section 3.2 of [RFC 3987].
7.5 Internationalized Electronic Mail Addresses 7.5 Internationalized Electronic Mail Addresses
Electronic Mail addresses may be included in certificates and CRLs in Electronic Mail addresses may be included in certificates and CRLs in
the subjectAltName and issuerAltName extensions, the name constraints the subjectAltName and issuerAltName extensions, the name constraints
extension, authority information access extension, subject extension, authority information access extension, subject
information access extension, issuing distribution point extension, information access extension, issuing distribution point extension,
or CRL distribution points extension. Each of these extensions uses or CRL distribution points extension. Each of these extensions uses
the GeneralName construct; GeneralName includes the rfc822Name the GeneralName construct; GeneralName includes the rfc822Name
choice, which is defined as type IA5String. To accommodate email choice, which is defined as type IA5String. To accommodate email
addresses with internationalized domain names using the current addresses with internationalized domain names using the current
structure, conforming implementations MUST convert the addresses into structure, conforming implementations MUST convert the addresses into
an ASCII representation. an ASCII representation.
Where the host-part (the domain of the addr-spec) contains an Where the host-part (the Domain of the Mailbox) contains an
internationalized name, the domain name MUST be converted from an IDN internationalized name, the domain name MUST be converted from an IDN
to the ASCII Compatible Encoding (ACE) format as specified in section to the ASCII Compatible Encoding (ACE) format as specified in section
7.2. 7.2.
Two email addresses are considered to match if: Two email addresses are considered to match if:
1) the local-part of each name is an exact match, AND 1) the local-part of each name is an exact match, AND
2) the host-part of each name matches using a case-insensitive 2) the host-part of each name matches using a case-insensitive
ASCII comparison. ASCII comparison.
Implementations should convert the host-part of internationalized Implementations should convert the host-part of internationalized
email addresses specified in these extensions to Unicode before email addresses specified in these extensions to Unicode before
display. Specifically, conforming implementations should perform the display. Specifically, conforming implementations should perform the
conversion of the host-part in the addr-spec as described in section conversion of the host-part of the Mailbox as described in section
7.2. 7.2.
8 References 8 References
Normative References Normative References
[RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
[RFC 1034] Mockapetris, P., "Domain Names - Concepts and [RFC 1034] Mockapetris, P., "Domain Names - Concepts and
Facilities", STD 13, RFC 1034, November 1987. Facilities", STD 13, RFC 1034, November 1987.
[RFC 1123] Braden, R., Ed., "Requirements for Internet Hosts --
Application and Support", STD 3, RFC 1123, October 1989.
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC 2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC 2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key [RFC 2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure: Operational Protocols: FTP and HTTP", RFC Infrastructure: Operational Protocols: FTP and HTTP", RFC
2585, May 1999. 2585, May 1999.
[RFC 2616] Fielding, R., J. Gettys, J. Mogul, H. Frystyk, L. [RFC 2616] Fielding, R., J. Gettys, J. Mogul, H. Frystyk, L.
Masinter, P. Leach and T. Berners-Lee, "Hypertext Masinter, P. Leach and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC 2797] Myers, M., X. Liu, J. Schaad and J. Weinstein, [RFC 2797] Myers, M., X. Liu, J. Schaad and J. Weinstein,
"Certificate Management Messages over CMS", RFC 2797, "Certificate Management Messages over CMS", RFC 2797,
April 2000. April 2000.
[RFC 2822] Resnick, P., "Internet Message Format", RFC 2822, April [RFC 2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC
2001. 2821, April 2001.
[RFC 3454] Hoffman, P. and M. Blanchet, "Preparation of [RFC 3454] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings (stringprep)", RFC 3454, Internationalized Strings (stringprep)", RFC 3454,
December 2002. December 2002.
[RFC 3490] Falstrom, P., P. Hoffman and A. Costello, [RFC 3490] Falstrom, P., P. Hoffman and A. Costello,
"Internationalizing Domain Names In Applications (IDNA)", "Internationalizing Domain Names In Applications (IDNA)",
RFC 3490, March 2003. RFC 3490, March 2003.
[RFC 3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC 3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC 3986] Berners-Lee, T., R. Fielding and L. Masinter, "Uniform [RFC 3986] Berners-Lee, T., R. Fielding and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", RFC 3986, Resource Identifier (URI): Generic Syntax", STD 66, RFC
January 2005. 3986, January 2005.
[RFC 3987] Duerst, M. and M. Suigard, "Internationalized Resource [RFC 3987] Duerst, M. and M. Suigard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005. Identifiers (IRIs)", RFC 3987, January 2005.
[RFC 4516] Smith, M. and T. Howes, "Lightweight Directory Access [RFC 4516] Smith, M. and T. Howes, "Lightweight Directory Access
Protocol (LDAP): Uniform Resource Locator", RFC 4516, Protocol (LDAP): Uniform Resource Locator", RFC 4516,
June 2006. June 2006.
[RFC 4518] Zeilenga, K., "Lightweight Directory Access Protocol [RFC 4518] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Internationalized String Preparation", RFC 4518, (LDAP): Internationalized String Preparation", RFC 4518,
June 2006. June 2006.
[RFC 4523] Zeilenga, K., "Lightweight Directory Access Protocol [RFC 4523] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP) Schema Definitions for X.509 Certificates", June (LDAP) Schema Definitions for X.509 Certificates", June
2006. 2006.
[RFC 4632] Fuller, V. and T. Li, "Classless Inter-domain Routing [RFC 4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation (CIDR): The Internet Address Assignment and Aggregation
Plan", RFC 4632, August 2006. Plan", BCP 122, RFC 4632, August 2006.
[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
Information technology - Abstract Syntax Notation One Information technology - Abstract Syntax Notation One
(ASN.1): Specification of basic notation. (ASN.1): Specification of basic notation.
[X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
Information technology - ASN.1 encoding rules: Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules Encoding Rules (CER) and Distinguished Encoding Rules
(DER). (DER).
Informative References Informative References
[ISO 8859] ISO/IEC 8859-1:1998. Information technology -- 8-bit [ISO 8859] ISO/IEC 8859-1:1998. Information technology -- 8-bit
single-byte coded graphic character sets -- Part 1: Latin single-byte coded graphic character sets -- Part 1: Latin
alphabet No. 1. alphabet No. 1.
[ISO 10646] ISO/IEC 10646:2003. Information technology -- Universal [ISO 10646] ISO/IEC 10646:2003. Information technology -- Universal
Multiple-Octet Coded Character Set (UCS). Multiple-Octet Coded Character Set (UCS).
[NFC] Davis, M. and M. Duerst, "Unicode Standard Annex #15:
Unicode Normalization Forms", October 2006,
<http://www.unicode.org/reports/tr15/>.
[RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic [RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic
Mail: Part II: Certificate-Based Key Management," RFC Mail: Part II: Certificate-Based Key Management," RFC
1422, February 1993. 1422, February 1993.
[RFC 2277] Alvestrand, H., "IETF Policy on Character Sets and [RFC 2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998. Languages", BCP 18, RFC 2277, January 1998.
[RFC 2459] Housley, R., W. Ford, W. Polk and D. Solo, "Internet [RFC 2459] Housley, R., W. Ford, W. Polk and D. Solo, "Internet
X.509 Public Key Infrastructure: Certificate and CRL X.509 Public Key Infrastructure: Certificate and CRL
Profile", RFC 2459, January 1999. Profile", RFC 2459, January 1999.
[RFC 2560] Myers, M., R. Ankney, A. Malpani, S. Galperin and C. [RFC 2560] Myers, M., R. Ankney, A. Malpani, S. Galperin and C.
Adams, "Online Certificate Status Protocol - OCSP", June Adams, "Online Certificate Status Protocol - OCSP", June
1999. 1999.
[RFC 2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC 2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object [RFC 2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
Classes and Attribute Types Version 2.0", RFC 2985, Classes and Attribute Types Version 2.0", RFC 2985,
November 2000. November 2000.
[RFC 3161] Adams, C., P. Cain, D. Pinkas and R. Zuccherato, [RFC 3161] Adams, C., P. Cain, D. Pinkas and R. Zuccherato,
"Internet X.509 Public Key Infrastructure Time-Stamp "Internet X.509 Public Key Infrastructure Time-Stamp
Protocol (TSP)", RFC 3161, August 2001. Protocol (TSP)", RFC 3161, August 2001.
[RFC 3279] Bassham, L., W. Polk and R. Housley, "Algorithms and [RFC 3279] Bassham, L., W. Polk and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key Identifiers for the Internet X.509 Public Key
skipping to change at page 99, line 38 skipping to change at page 100, line 46
[RFC 4210] Adams, C., S. Farrell, T. Kause and T. Mononen, "Internet [RFC 4210] Adams, C., S. Farrell, T. Kause and T. Mononen, "Internet
X.509 Public Key Infrastructure Certificate Management X.509 Public Key Infrastructure Certificate Management
Protocol (CMP)", RFC 4210, September 2005. Protocol (CMP)", RFC 4210, September 2005.
[RFC 4325] Santesson, S. and R. Housley, "Internet X.509 Public Key [RFC 4325] Santesson, S. and R. Housley, "Internet X.509 Public Key
Infrastructure Authority Information Access Certificate Infrastructure Authority Information Access Certificate
Revocation List (CRL) Extension", RFC 4325, December Revocation List (CRL) Extension", RFC 4325, December
2005. 2005.
[RFC 4491] Leontiev, S. and D. Shefanovski, "Using the GOST R [RFC 4491] Leontiev, S., Ed., and D. Shefanovski, Ed., "Using the
34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
Algorithms with the Internet X.509 Public Key Algorithms with the Internet X.509 Public Key
Infrastructure Certificate and CRL Profile", RFC 4491, Infrastructure Certificate and CRL Profile", RFC 4491,
May 2006. May 2006.
[RFC 4510] Zeilenga, K., "Lightweight Directory Access Protocol [RFC 4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
(LDAP): Technical Specification Road Map", RFC 4510, June (LDAP): Technical Specification Road Map", RFC 4510, June
2006. 2006.
[RFC 4512] Zeilenga, K., "Lightweight Directory Access Protocol [RFC 4512] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
(LDAP): Directory Information Models", RFC 4512, June (LDAP): Directory Information Models", RFC 4512, June
2006. 2006.
[RFC 4514] Zeilenga, K., "Lightweight Directory Access Protocol [RFC 4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
(LDAP): String Representation of Distinguished Names", (LDAP): String Representation of Distinguished Names",
RFC 4514, June 2006. RFC 4514, June 2006.
[RFC 4519] Sciberras, A., "Lightweight Directory Access Protocol [RFC 4519] Sciberras, A., Ed., "Lightweight Directory Access
(LDAP): Schema for User Applications", RFC 4519, June Protocol (LDAP): Schema for User Applications", RFC 4519,
2006. June 2006.
[RFC 4630] Housley, R. and S. Santesson, "Update to DirectoryString [RFC 4630] Housley, R. and S. Santesson, "Update to DirectoryString
Processing in the Internet X.509 Public Key Processing in the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 4630, August 2006. List (CRL) Profile", RFC 4630, August 2006.
[X.500] ITU-T Recommendation X.500 (2005) | ISO/IEC 9594-1:2005, [X.500] ITU-T Recommendation X.500 (2005) | ISO/IEC 9594-1:2005,
Information technology - Open Systems Interconnection - Information technology - Open Systems Interconnection -
The Directory: Overview of concepts, models and services. The Directory: Overview of concepts, models and services.
skipping to change at page 101, line 26 skipping to change at page 102, line 31
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at
ipr@ietf.org. ietf-ipr@ietf.org.
10 Security Considerations 10 Security Considerations
The majority of this specification is devoted to the format and The majority of this specification is devoted to the format and
content of certificates and CRLs. Since certificates and CRLs are content of certificates and CRLs. Since certificates and CRLs are
digitally signed, no additional integrity service is necessary. digitally signed, no additional integrity service is necessary.
Neither certificates nor CRLs need be kept secret, and unrestricted Neither certificates nor CRLs need be kept secret, and unrestricted
and anonymous access to certificates and CRLs has no security and anonymous access to certificates and CRLs has no security
implications. implications.
skipping to change at page 104, line 32 skipping to change at page 105, line 37
the same issuer name. As a means of reducing problems and security the same issuer name. As a means of reducing problems and security
issues related to issuer name collisions, CA and CRL issuer names issues related to issuer name collisions, CA and CRL issuer names
SHOULD be formed in a way that reduces the likelihood of name SHOULD be formed in a way that reduces the likelihood of name
collisions. Implementers should take into account the possible collisions. Implementers should take into account the possible
existence of multiple unrelated CAs and CRL issuers with the same existence of multiple unrelated CAs and CRL issuers with the same
name. At a minimum, implementations validating CRLs MUST ensure that name. At a minimum, implementations validating CRLs MUST ensure that
the certification path of a certificate and the CRL issuer the certification path of a certificate and the CRL issuer
certification path used to validate the certificate terminate at the certification path used to validate the certificate terminate at the
same trust anchor. same trust anchor.
While the local-part of an RFC 822 name is case-sensitive [RFC 2821], While the local-part of an electronic mail address is case-sensitive
emailAddress attribute values are not case-sensitive [RFC 2985]. As [RFC 2821], emailAddress attribute values are not case-sensitive
a result, there is a risk that two different email addresses will be [RFC 2985]. As a result, there is a risk that two different email
treated as the same address when the matching rule for the addresses will be treated as the same address when the matching rule
emailAddress attribute is used, if the email server exploits the case for the emailAddress attribute is used, if the email server exploits
sensitivity of mailbox local-parts. Implementers should not include the case sensitivity of mailbox local-parts. Implementers should not
an email address in the emailAddress attribute if the email server include an email address in the emailAddress attribute if the email
that hosts the email address treats the local-part of email addresses server that hosts the email address treats the local-part of email
as case-sensitive. addresses as case-sensitive.
Implementers should be aware of risks involved if the CRL Implementers should be aware of risks involved if the CRL
distribution points or authority information access extensions of distribution points or authority information access extensions of
corrupted certificates or CRLs contain links to malicious code. corrupted certificates or CRLs contain links to malicious code.
Implementers should always take the steps of validating the retrieved Implementers should always take the steps of validating the retrieved
data to ensure that the data is properly formed. data to ensure that the data is properly formed.
When certificates include a cRLDistributionPoints extension with an When certificates include a cRLDistributionPoints extension with an
https URI or similar scheme, circular dependencies can be introduced. https URI or similar scheme, circular dependencies can be introduced.
The relying party is forced to perform an additional path validation The relying party is forced to perform an additional path validation
skipping to change at page 114, line 4 skipping to change at page 115, line 6
utcTime UTCTime, utcTime UTCTime,
generalTime GeneralizedTime } generalTime GeneralizedTime }
UniqueIdentifier ::= BIT STRING UniqueIdentifier ::= BIT STRING
SubjectPublicKeyInfo ::= SEQUENCE { SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier, algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING } subjectPublicKey BIT STRING }
Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
Extension ::= SEQUENCE { Extension ::= SEQUENCE {
extnID OBJECT IDENTIFIER, extnID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE, critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING } extnValue OCTET STRING
-- contains the DER encoding of an ASN.1 value
-- corresponding to the extension type identified
-- by extnID
}
-- CRL structures -- CRL structures
CertificateList ::= SEQUENCE { CertificateList ::= SEQUENCE {
tbsCertList TBSCertList, tbsCertList TBSCertList,
signatureAlgorithm AlgorithmIdentifier, signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING } signature BIT STRING }
TBSCertList ::= SEQUENCE { TBSCertList ::= SEQUENCE {
version Version OPTIONAL, version Version OPTIONAL,
skipping to change at page 131, line 46 skipping to change at page 133, line 9
Section C.4 contains an annotated hex dump of a CRL. The CRL is Section C.4 contains an annotated hex dump of a CRL. The CRL is
issued by the CA whose distinguished name is issued by the CA whose distinguished name is
cn=Example CA,dc=example,dc=com and the list of revoked certificates cn=Example CA,dc=example,dc=com and the list of revoked certificates
includes the end entity certificate presented in C.2. includes the end entity certificate presented in C.2.
The certificates were processed using Peter Gutmann's dumpasn1 The certificates were processed using Peter Gutmann's dumpasn1
utility to generate the output. The source for the dumpasn1 utility utility to generate the output. The source for the dumpasn1 utility
is available at <http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c>. is available at <http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c>.
The binaries for the certificates and CRLs are available at The binaries for the certificates and CRLs are available at
<http://csrc.nist.gov/pki/pkixtools>. http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/pkixtools.
In places in this appendix where a distinguished name is specified In places in this appendix where a distinguished name is specified
using a string representation, the strings are formatted using the using a string representation, the strings are formatted using the
rules specified in [RFC 4514]. rules specified in [RFC 4514].
C.1 RSA Self-Signed Certificate C.1 RSA Self-Signed Certificate
This section contains an annotated hex dump of a 578 byte version 3 This section contains an annotated hex dump of a 578 byte version 3
certificate. The certificate contains the following information: certificate. The certificate contains the following information:
skipping to change at page 135, line 25 skipping to change at page 136, line 35
(d) the subject's distinguished name is (d) the subject's distinguished name is
cn=End Entity,dc=example,dc=com; cn=End Entity,dc=example,dc=com;
(e) the certificate was valid from September 15, 2004 through March (e) the certificate was valid from September 15, 2004 through March
15, 2005; 15, 2005;
(f) the certificate contains a 1024 bit RSA public key; (f) the certificate contains a 1024 bit RSA public key;
(g) the certificate is an end entity certificate, as the basic (g) the certificate is an end entity certificate, as the basic
constraints extension is not present; constraints extension is not present;
(h) the certificate contains an authority key identifier extension (h) the certificate contains an authority key identifier extension
matching the subject key identifier of the certificate in matching the subject key identifier of the certificate in
appendix C.1; and appendix C.1; and
(i) the certificate includes one alternative name - an RFC 822 (i) the certificate includes one alternative name - an electronic
address of "end.entity@example.com". mail address (rfc822Name) of "end.entity@example.com".
0 625: SEQUENCE { 0 625: SEQUENCE {
4 474: SEQUENCE { 4 474: SEQUENCE {
8 3: [0] { 8 3: [0] {
10 1: INTEGER 2 10 1: INTEGER 2
: } : }
13 1: INTEGER 18 13 1: INTEGER 18
16 13: SEQUENCE { 16 13: SEQUENCE {
18 9: OBJECT IDENTIFIER 18 9: OBJECT IDENTIFIER
: sha1withRSAEncryption (1 2 840 113549 1 1 5) : sha1withRSAEncryption (1 2 840 113549 1 1 5)
skipping to change at page 144, line 30 skipping to change at page 145, line 42
: 1F EE 90 17 A2 6F 60 E4 BD AA 8C 55 DE 8E 84 6F : 1F EE 90 17 A2 6F 60 E4 BD AA 8C 55 DE 8E 84 6F
: 92 F8 9F 10 12 27 AF 4A D4 2F 85 E2 36 44 7D AA : 92 F8 9F 10 12 27 AF 4A D4 2F 85 E2 36 44 7D AA
: A3 4C 25 38 15 FF 00 FD 3E 7E EE 3D 26 12 EB D8 : A3 4C 25 38 15 FF 00 FD 3E 7E EE 3D 26 12 EB D8
: E7 2B 62 E2 2B C3 46 80 EF 78 82 D1 15 C6 D0 9C : E7 2B 62 E2 2B C3 46 80 EF 78 82 D1 15 C6 D0 9C
: 72 6A CB CE 7A ED 67 99 8B 6E 70 81 7D 43 42 74 : 72 6A CB CE 7A ED 67 99 8B 6E 70 81 7D 43 42 74
: C1 A6 AF C1 55 17 A2 33 4C D6 06 98 2B A4 FC 2E : C1 A6 AF C1 55 17 A2 33 4C D6 06 98 2B A4 FC 2E
: } : }
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 55 change blocks. 
132 lines changed or deleted 154 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/