< draft-ietf-pkix-new-part1-07.txt   draft-ietf-pkix-new-part1-08.txt >
PKIX Working Group R. Housley (RSA Laboratories) PKIX Working Group R. Housley (RSA Laboratories)
Internet Draft W. Ford (VeriSign) Internet Draft W. Ford (VeriSign)
W. Polk (NIST) W. Polk (NIST)
D. Solo (Citigroup) D. Solo (Citigroup)
expires in six months June 2001 expires in six months July 2001
Internet X.509 Public Key Infrastructure Internet X.509 Public Key Infrastructure
Certificate and CRL Profile Certificate and CRL Profile
<draft-ietf-pkix-new-part1-07.txt> <draft-ietf-pkix-new-part1-08.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 1, line 44 skipping to change at page 1, line 44
To view the entire list of current Internet-Drafts, please check the To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
This is the seventh draft of a specification based upon RFC 2459. This is the eighth draft of a specification based upon RFC 2459.
When complete, this specification will obsolete RFC 2459. This When complete, this specification will obsolete RFC 2459.
specification includes minor edits and clarifications. The most
notable departures from RFC 2459 are found in Section 6, Path
Validation. In RFC 2459, the reader was expected to augment the path
validation algorithm, which concentrated upon policy processing, with
information embedded in other sections. For example, parameter
inheritance is discussed in Section 7, Algorithm Support, and can
certainly affect the validity of a certification path. However,
parameter inheritance was omitted from the path validation algorithm
in RFC 2459. In this document, the path validation algorithm has a
comprehensive and extremely detailed description. Details such as
parameter inheritance are covered thoroughly. In addition, this
document anticipates certain corrections proposed in the X.509
standard for the policy processing aspects of path validation.
A new section 6.3, CRL validation, has been added. This section
provides a supplement to the path validation algorithm that
determines whether a particular CRL may be used to verify the status
of a particular certificate. The basic certification path validation
algorithm is, by design, independent of the type and format of status
information.
Significant corrections have been made to the ASN.1 modules contained Please send comments on this document to the ietf-pkix@imc.org mail
in the appendices. list.
This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use
in the Internet. An overview of the approach and model are provided in the Internet. An overview of the approach and model are provided
as an introduction. The X.509 v3 certificate format is described in as an introduction. The X.509 v3 certificate format is described in
detail, with additional information regarding the format and detail, with additional information regarding the format and
semantics of Internet name forms (e.g., IP addresses). Standard semantics of Internet name forms (e.g., IP addresses). Standard
certificate extensions are described and one new Internet-specific certificate extensions are described and one new Internet-specific
extension is defined. A required set of certificate extensions is extension is defined. A required set of certificate extensions is
specified. The X.509 v2 CRL format is described, including a specified. The X.509 v2 CRL format is described and a required
required set of extensions. An algorithm for X.509 certification extension set is defined as well. An algorithm for X.509 certificate
path validation is described. Supplemental information describing path validation is described. Supplemental information is provided
the format of public keys and digital signatures in X.509 describing the format of public keys and digital signatures in X.509
certificates for common Internet public key algorithms. ASN.1 certificates for common Internet public key encryption algorithms
modules and examples are provided in the appendices. (i.e., RSA, DSA, and Diffie-Hellman). ASN.1 modules and examples are
provided in the appendices.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
Please send comments on this document to the ietf-pkix@imc.org mail
list.
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Requirements and Assumptions . . . . . . . . . . . . . . . . . . 7 2 Requirements and Assumptions . . . . . . . . . . . . . . . . . . 7
2.1 Communication and Topology . . . . . . . . . . . . . . . . . . 7 2.1 Communication and Topology . . . . . . . . . . . . . . . . . . 7
2.2 Acceptability Criteria . . . . . . . . . . . . . . . . . . . . 8 2.2 Acceptability Criteria . . . . . . . . . . . . . . . . . . . . 8
2.3 User Expectations . . . . . . . . . . . . . . . . . . . . . . . 8 2.3 User Expectations . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Administrator Expectations . . . . . . . . . . . . . . . . . . 8 2.4 Administrator Expectations . . . . . . . . . . . . . . . . . . 8
3 Overview of Approach . . . . . . . . . . . . . . . . . . . . . . 8 3 Overview of Approach . . . . . . . . . . . . . . . . . . . . . . 8
3.1 X.509 Version 3 Certificate . . . . . . . . . . . . . . . . . . 10 3.1 X.509 Version 3 Certificate . . . . . . . . . . . . . . . . . . 10
skipping to change at page 3, line 40 skipping to change at page 3, line 40
4.1.2.5 Validity . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.1.2.5 Validity . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.2.5.1 UTCTime . . . . . . . . . . . . . . . . . . . . . . . . . 23 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.1.2.6 Subject . . . . . . . . . . . . . . . . . . . . . . . . . . 24
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 . . . . . . . . . . . . . . . . . . . . 25
4.2.1 Standard Extensions . . . . . . . . . . . . . . . . . . . . . 26 4.2.1 Standard Extensions . . . . . . . . . . . . . . . . . . . . . 26
4.2.1.1 Authority Key Identifier . . . . . . . . . . . . . . . . . 27 4.2.1.1 Authority Key Identifier . . . . . . . . . . . . . . . . . 27
4.2.1.2 Subject Key Identifier . . . . . . . . . . . . . . . . . . 27 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 Private Key Usage Period . . . . . . . . . . . . . . . . . 30 4.2.1.4 Private Key Usage Period . . . . . . . . . . . . . . . . . 30
4.2.1.5 Certificate Policies . . . . . . . . . . . . . . . . . . . 31 4.2.1.5 Certificate Policies . . . . . . . . . . . . . . . . . . . 31
4.2.1.6 Policy Mappings . . . . . . . . . . . . . . . . . . . . . . 33 4.2.1.6 Policy Mappings . . . . . . . . . . . . . . . . . . . . . . 33
4.2.1.7 Subject Alternative Name . . . . . . . . . . . . . . . . . 34 4.2.1.7 Subject Alternative Name . . . . . . . . . . . . . . . . . 34
4.2.1.8 Issuer Alternative Name . . . . . . . . . . . . . . . . . . 36 4.2.1.8 Issuer Alternative Name . . . . . . . . . . . . . . . . . . 37
4.2.1.9 Subject Directory Attributes . . . . . . . . . . . . . . . 37 4.2.1.9 Subject Directory Attributes . . . . . . . . . . . . . . . 37
4.2.1.10 Basic Constraints . . . . . . . . . . . . . . . . . . . . 37 4.2.1.10 Basic Constraints . . . . . . . . . . . . . . . . . . . . 37
4.2.1.11 Name Constraints . . . . . . . . . . . . . . . . . . . . . 38 4.2.1.11 Name Constraints . . . . . . . . . . . . . . . . . . . . . 38
4.2.1.12 Policy Constraints . . . . . . . . . . . . . . . . . . . . 40 4.2.1.12 Policy Constraints . . . . . . . . . . . . . . . . . . . . 40
4.2.1.13 Extended key usage field . . . . . . . . . . . . . . . . . 41 4.2.1.13 Extended key usage field . . . . . . . . . . . . . . . . . 41
4.2.1.14 CRL Distribution Points . . . . . . . . . . . . . . . . . 42 4.2.1.14 CRL Distribution Points . . . . . . . . . . . . . . . . . 43
4.2.1.15 Inhibit Any-Policy . . . . . . . . . . . . . . . . . . . . 43 4.2.1.15 Inhibit Any-Policy . . . . . . . . . . . . . . . . . . . . 44
4.2.1.16 Freshest CRL . . . . . . . . . . . . . . . . . . . . . . . 43 4.2.1.16 Freshest CRL . . . . . . . . . . . . . . . . . . . . . . . 45
4.2.2 Internet Certificate Extensions . . . . . . . . . . . . . . . 44 4.2.2 Internet Certificate Extensions . . . . . . . . . . . . . . . 45
4.2.2.1 Authority Information Access . . . . . . . . . . . . . . . 44 4.2.2.1 Authority Information Access . . . . . . . . . . . . . . . 45
4.2.2.2 Subject Information Access . . . . . . . . . . . . . . . . 45 4.2.2.2 Subject Information Access . . . . . . . . . . . . . . . . 47
5 CRL and CRL Extensions Profile . . . . . . . . . . . . . . . . . 47 5 CRL and CRL Extensions Profile . . . . . . . . . . . . . . . . . 48
5.1 CRL Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.1 CRL Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1.1 CertificateList Fields . . . . . . . . . . . . . . . . . . . 48 5.1.1 CertificateList Fields . . . . . . . . . . . . . . . . . . . 50
5.1.1.1 tbsCertList . . . . . . . . . . . . . . . . . . . . . . . . 48 5.1.1.1 tbsCertList . . . . . . . . . . . . . . . . . . . . . . . . 50
5.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . . . . . 49 5.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . . . . . 50
5.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . . . . . 49 5.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . . . . . 51
5.1.2 Certificate List "To Be Signed" . . . . . . . . . . . . . . . 49 5.1.2 Certificate List "To Be Signed" . . . . . . . . . . . . . . . 51
5.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.1.2.2 Signature . . . . . . . . . . . . . . . . . . . . . . . . . 49 5.1.2.2 Signature . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.1.2.3 Issuer Name . . . . . . . . . . . . . . . . . . . . . . . . 50 5.1.2.3 Issuer Name . . . . . . . . . . . . . . . . . . . . . . . . 52
5.1.2.4 This Update . . . . . . . . . . . . . . . . . . . . . . . . 50 5.1.2.4 This Update . . . . . . . . . . . . . . . . . . . . . . . . 52
5.1.2.5 Next Update . . . . . . . . . . . . . . . . . . . . . . . . 50 5.1.2.5 Next Update . . . . . . . . . . . . . . . . . . . . . . . . 52
5.1.2.6 Revoked Certificates . . . . . . . . . . . . . . . . . . . 51 5.1.2.6 Revoked Certificates . . . . . . . . . . . . . . . . . . . 53
5.1.2.7 Extensions . . . . . . . . . . . . . . . . . . . . . . . . 51 5.1.2.7 Extensions . . . . . . . . . . . . . . . . . . . . . . . . 53
5.2 CRL Extensions . . . . . . . . . . . . . . . . . . . . . . . . 51 5.2 CRL Extensions . . . . . . . . . . . . . . . . . . . . . . . . 53
5.2.1 Authority Key Identifier . . . . . . . . . . . . . . . . . . 51 5.2.1 Authority Key Identifier . . . . . . . . . . . . . . . . . . 54
5.2.2 Issuer Alternative Name . . . . . . . . . . . . . . . . . . . 52 5.2.2 Issuer Alternative Name . . . . . . . . . . . . . . . . . . . 54
5.2.3 CRL Number . . . . . . . . . . . . . . . . . . . . . . . . . 52 5.2.3 CRL Number . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.2.4 Delta CRL Indicator . . . . . . . . . . . . . . . . . . . . . 52 5.2.4 Delta CRL Indicator . . . . . . . . . . . . . . . . . . . . . 55
5.2.5 Issuing Distribution Point . . . . . . . . . . . . . . . . . 54 5.2.5 Issuing Distribution Point . . . . . . . . . . . . . . . . . 58
5.2.6 Freshest CRL . . . . . . . . . . . . . . . . . . . . . . . . 55 5.2.6 Freshest CRL . . . . . . . . . . . . . . . . . . . . . . . . 59
5.3 CRL Entry Extensions . . . . . . . . . . . . . . . . . . . . . 55 5.3 CRL Entry Extensions . . . . . . . . . . . . . . . . . . . . . 59
5.3.1 Reason Code . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.3.1 Reason Code . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.3.2 Hold Instruction Code . . . . . . . . . . . . . . . . . . . . 56 5.3.2 Hold Instruction Code . . . . . . . . . . . . . . . . . . . . 60
5.3.3 Invalidity Date . . . . . . . . . . . . . . . . . . . . . . . 57 5.3.3 Invalidity Date . . . . . . . . . . . . . . . . . . . . . . . 61
5.3.4 Certificate Issuer . . . . . . . . . . . . . . . . . . . . . 57 5.3.4 Certificate Issuer . . . . . . . . . . . . . . . . . . . . . 61
6 Certificate Path Validation . . . . . . . . . . . . . . . . . . . 58 6 Certificate Path Validation . . . . . . . . . . . . . . . . . . . 62
6.1 Basic Path Validation . . . . . . . . . . . . . . . . . . . . . 58 6.1 Basic Path Validation . . . . . . . . . . . . . . . . . . . . . 63
6.1.1 Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 6.1.1 Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.1.2 Initialization . . . . . . . . . . . . . . . . . . . . . . . . 62 6.1.2 Initialization . . . . . . . . . . . . . . . . . . . . . . . 66
6.1.3 Basic Certificate Processing . . . . . . . . . . . . . . . . . 65 6.1.3 Basic Certificate Processing . . . . . . . . . . . . . . . . 69
6.1.4 Preparation for Certificate i+1 . . . . . . . . . . . . . . . 70 6.1.4 Preparation for Certificate i+1 . . . . . . . . . . . . . . . 74
6.1.5 Wrap-up procedure . . . . . . . . . . . . . . . . . . . . . . 73 6.1.5 Wrap-up procedure . . . . . . . . . . . . . . . . . . . . . . 77
6.1.6 Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 6.1.6 Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.2 Extending Path Validation . . . . . . . . . . . . . . . . . . . 75 6.2 Extending Path Validation . . . . . . . . . . . . . . . . . . . 79
6.3 CRL Validation . . . . . . . . . . . . . . . . . . . . . . . . 75 6.3 CRL Validation . . . . . . . . . . . . . . . . . . . . . . . . 80
6.3.1 Revocation Inputs . . . . . . . . . . . . . . . . . . . . . . 76 6.3.1 Revocation Inputs . . . . . . . . . . . . . . . . . . . . . . 80
6.3.2 Initialization and Revocation State Variables . . . . . . . . 76 6.3.2 Initialization and Revocation State Variables . . . . . . . . 81
6.3.3 CRL Processing . . . . . . . . . . . . . . . . . . . . . . . 77 6.3.3 CRL Processing . . . . . . . . . . . . . . . . . . . . . . . 81
7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
8 Intellectual Property Rights . . . . . . . . . . . . . . . . . . 81 8 Intellectual Property Rights . . . . . . . . . . . . . . . . . . 87
9 Security Considerations . . . . . . . . . . . . . . . . . . . . . 81 9 Security Considerations . . . . . . . . . . . . . . . . . . . . . 87
Appendix A. ASN.1 Structures and OIDs . . . . . . . . . . . . . . . 85 Appendix A. ASN.1 Structures and OIDs . . . . . . . . . . . . . . . 91
A.1 Explicitly Tagged Module, 1988 Syntax . . . . . . . . . . . . . 85 A.1 Explicitly Tagged Module, 1988 Syntax . . . . . . . . . . . . . 91
A.2 Implicitly Tagged Module, 1988 Syntax . . . . . . . . . . . . . 98 A.2 Implicitly Tagged Module, 1988 Syntax . . . . . . . . . . . . . 104
Appendix B. ASN.1 Notes . . . . . . . . . . . . . . . . . . . . . . 105 Appendix B. ASN.1 Notes . . . . . . . . . . . . . . . . . . . . . . 111
Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . . 106 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . . 113
C.1 Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . 107 C.1 DSA Self-Signed Certificate . . . . . . . . . . . . . . . . . . 114
C.2 Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . 110 C.2 End Entity Certificate Using DSA . . . . . . . . . . . . . . . 117
C.3 End Entity Certificate Using RSA . . . . . . . . . . . . . . . 113 C.3 End Entity Certificate Using RSA . . . . . . . . . . . . . . . 120
C.4 Certificate Revocation List . . . . . . . . . . . . . . . . . . 116 C.4 Certificate Revocation List . . . . . . . . . . . . . . . . . . 124
Appendix D. Author Addresses . . . . . . . . . . . . . . . . . . . 118 Appendix D. Author Addresses . . . . . . . . . . . . . . . . . . . 127
Appendix E. Full Copyright Statement . . . . . . . . . . . . . . . 118 Appendix E. Full Copyright Statement . . . . . . . . . . . . . . . 127
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. This specification Public Key Infrastructure (PKI) for the Internet. This specification
is a standalone document; implementations of this standard may is a standalone document; implementations of this standard may
proceed independent from the other parts. proceed independent from the other parts.
This specification profiles the format and semantics of certificates This specification profiles the format and semantics of certificates
and certificate revocation lists for the Internet PKI. Procedures and certificate revocation lists for the Internet PKI. Procedures
are described for processing of certification paths in the Internet are described for processing of certification paths in the Internet
skipping to change at page 12, line 22 skipping to change at page 12, line 22
can certify (e.g., a CA for an organization can only certify entities can certify (e.g., a CA for an organization can only certify entities
in that organization's name tree). Certificate user systems are able in that organization's name tree). Certificate user systems are able
to mechanically check that the name subordination rule has been to mechanically check that the name subordination rule has been
followed. followed.
The RFC 1422 uses the X.509 v1 certificate formats. The limitations The RFC 1422 uses the X.509 v1 certificate formats. The limitations
of X.509 v1 required imposition of several structural restrictions to of X.509 v1 required imposition of several structural restrictions to
clearly associate policy information or restrict the utility of clearly associate policy information or restrict the utility of
certificates. These restrictions included: certificates. These restrictions included:
(a) a pure top-down hierarchy, with all certification paths (a) a pure top-down hierarchy, with all certification paths
starting from IPRA; starting from IPRA;
(b) a naming subordination rule restricting the names of a CA's (b) a naming subordination rule restricting the names of a CA's
subjects; and subjects; and
(c) use of the PCA concept, which requires knowledge of individual (c) use of the PCA concept, which requires knowledge of
PCAs to be built into certificate chain verification logic. individual PCAs to be built into certificate chain verification
Knowledge of individual PCAs was required to determine if a chain logic. Knowledge of individual PCAs was required to determine if
could be accepted. a chain could be accepted.
With X.509 v3, most of the requirements addressed by RFC 1422 can be With X.509 v3, most of the requirements addressed by RFC 1422 can be
addressed using certificate extensions, without a need to restrict addressed using certificate extensions, without a need to restrict
the CA structures used. In particular, the certificate extensions the CA structures used. In particular, the certificate extensions
relating to certificate policies obviate the need for PCAs and the relating to certificate policies obviate the need for PCAs and the
constraint extensions obviate the need for the name subordination constraint extensions obviate the need for the name subordination
rule. As a result, this document supports a more flexible rule. As a result, this document supports a more flexible
architecture, including: architecture, including:
(a) Certification paths start with a public key of a CA in a (a) Certification paths start with a public key of a CA in a
user's own domain, or with the public key of the top of a user's own domain, or with the public key of the top of a
hierarchy. Starting with the public key of a CA in a user's own hierarchy. Starting with the public key of a CA in a user's own
domain has certain advantages. In some environments, the local domain has certain advantages. In some environments, the local
domain is the most trusted. domain is the most trusted.
(b) Name constraints may be imposed through explicit inclusion of (b) Name constraints may be imposed through explicit inclusion of
a name constraints extension in a certificate, but are not a name constraints extension in a certificate, but are not
required. required.
(c) Policy extensions and policy mappings replace the PCA concept, (c) Policy extensions and policy mappings replace the PCA
which permits a greater degree of automation. The application can concept, which permits a greater degree of automation. The
determine if the certification path is acceptable based on the application can determine if the certification path is acceptable
contents of the certificates instead of a priori knowledge of based on the contents of the certificates instead of a priori
PCAs. This permits automation of certificate chain processing. knowledge of PCAs. This permits automation of certificate chain
processing.
3.3 Revocation 3.3 Revocation
When a certificate is issued, it is expected to be in use for its When a certificate is issued, it is expected to be in use for its
entire validity period. However, various circumstances may cause a entire validity period. However, various circumstances may cause a
certificate to become invalid prior to the expiration of the validity certificate to become invalid prior to the expiration of the validity
period. Such circumstances include change of name, change of period. Such circumstances include change of name, change of
association between subject and CA (e.g., an employee terminates association between subject and CA (e.g., an employee terminates
employment with an organization), and compromise or suspected employment with an organization), and compromise or suspected
compromise of the corresponding private key. Under such compromise of the corresponding private key. Under such
skipping to change at page 19, line 14 skipping to change at page 19, line 14
implementations based on this profile. implementations based on this profile.
4.1.2.2 Serial number 4.1.2.2 Serial number
The serial number MUST be a positive integer assigned by the CA to The serial number MUST be a positive integer assigned by the CA to
each certificate. It MUST be unique for each certificate issued by a each certificate. It MUST be unique for each certificate issued by a
given CA (i.e., the issuer name and serial number identify a unique given CA (i.e., the issuer name and serial number identify a unique
certificate). CAs MUST force the serialNumber to be a non-negative certificate). CAs MUST force the serialNumber to be a non-negative
integer. integer.
Given the uniqueness requirements above serial numbers can be Given the uniqueness requirements above, serial numbers can be
expected to contain long integers. Certificate users MUST be able to expected to contain long integers. Certificate users MUST be able to
handle serialNumber values up to 20 octets. Conformant CAs MUST NOT handle serialNumber values up to 20 octets. Conformant CAs MUST NOT
use serialNumber values longer than 20 octets. use serialNumber values longer than 20 octets.
Note: Non-conforming CAs MAY issue certificates with serial numbers Note: Non-conforming CAs MAY issue certificates with serial numbers
that are negative, or zero. Certificate users SHOULD be prepared to that are negative, or zero. Certificate users SHOULD be prepared to
handle such certificates. handle such certificates.
4.1.2.3 Signature 4.1.2.3 Signature
skipping to change at page 20, line 23 skipping to change at page 20, line 23
utf8String UTF8String (SIZE (1..MAX)), utf8String UTF8String (SIZE (1..MAX)),
bmpString BMPString (SIZE (1..MAX)) } bmpString BMPString (SIZE (1..MAX)) }
The Name describes a hierarchical name composed of attributes, such The Name describes a hierarchical name composed of attributes, such
as country name, and corresponding values, such as US. The type of as country name, and corresponding values, such as US. The type of
the component AttributeValue is determined by the AttributeType; in the component AttributeValue is determined by the AttributeType; in
general it will be a DirectoryString. general it will be a DirectoryString.
The DirectoryString type is defined as a choice of PrintableString, The DirectoryString type is defined as a choice of PrintableString,
TeletexString, BMPString, UTF8String, and UniversalString. The TeletexString, BMPString, UTF8String, and UniversalString. The
UTF8String encoding is the preferred encoding, and all certificates UTF8String encoding [RFC 2279] is the preferred encoding, and all
issued after December 31, 2003 MUST use the UTF8String encoding of certificates issued after December 31, 2003 MUST use the UTF8String
DirectoryString (except as noted below). Until that date, conforming encoding of DirectoryString (except as noted below). Until that
CAs MUST choose from the following options when creating a date, conforming CAs MUST choose from the following options when
distinguished name, including their own: creating a distinguished name, including their own:
(a) if the character set is sufficient, the string MAY be (a) if the character set is sufficient, the string MAY be
represented as a PrintableString; represented as a PrintableString;
(b) failing (a), if the BMPString character set is sufficient the (b) failing (a), if the BMPString character set is sufficient the
string MAY be represented as a BMPString; and string MAY be represented as a BMPString; and
(c) failing (a) and (b), the string MUST be represented as a (c) failing (a) and (b), the string MUST be represented as a
UTF8String. If (a) or (b) is satisfied, the CA MAY still choose UTF8String. If (a) or (b) is satisfied, the CA MAY still choose
to represent the string as a UTF8String. to represent the string as a UTF8String.
Exceptions to the December 31, 2003 UTF8 encoding requirements are as Exceptions to the December 31, 2003 UTF8 encoding requirements are as
follows: follows:
(a) CAs MAY issue "name rollover" certificates to support an (a) CAs MAY issue "name rollover" certificates to support an
orderly migration to UTF8String encoding. Such certificates would orderly migration to UTF8String encoding. Such certificates would
include the CA's UTF8String encoded name as issuer and and the old include the CA's UTF8String encoded name as issuer and and the old
name encoding as subject, or vice-versa. name encoding as subject, or vice-versa.
(b) As stated in section 4.1.2.6, the subject field MUST be (b) As stated in section 4.1.2.6, the subject field MUST be
populated with a non-empty distinguished name matching the populated with a non-empty distinguished name matching the
contents of the issuer field in all certificates issued by the contents of the issuer field in all certificates issued by the
subject CA regardless of encoding. subject CA regardless of encoding.
The TeletexString and UniversalString are included for backward The TeletexString and UniversalString are included for backward
compatibility, and SHOULD NOT be used for certificates for new compatibility, and SHOULD NOT be used for certificates for new
subjects. However, these types MAY be used in certificates where the subjects. However, these types MAY be used in certificates where the
name was previously established. Certificate users SHOULD be name was previously established. Certificate users SHOULD be
prepared to receive certificates with these types. prepared to receive certificates with these types.
skipping to change at page 22, line 8 skipping to change at page 22, line 8
* initials, * initials,
* pseudonym, and * pseudonym, and
* generation qualifier (e.g., "Jr.", "3rd", or "IV"). * generation qualifier (e.g., "Jr.", "3rd", or "IV").
The syntax and associated object identifiers (OIDs) for these The syntax and associated object identifiers (OIDs) for these
attribute types are provided in the ASN.1 modules in Appendix A. attribute types are provided in the ASN.1 modules in Appendix A.
In addition, implementations of this specification MUST be prepared In addition, implementations of this specification MUST be prepared
to receive the domainComponent attribute, as defined in [RFC 2247]. to receive the domainComponent attribute, as defined in [RFC 2247].
The Domain (Nameserver) System (DNS) provides a hierarchical resource The Domain (Nameserver) System (DNS) provides a hierarchical resource
labeling system. This attribute provides is a convenient mechanism labeling system. This attribute provides a convenient mechanism for
for organizations that wish to use DNs that parallel their DNS names. organizations that wish to use DNs that parallel their DNS names.
This is not a replacement for the dNSName component of the This is not a replacement for the dNSName component of the
alternative name field. Implementations are not required to convert alternative name field. Implementations are not required to convert
such names into DNS names. The syntax and associated OID for this such names into DNS names. The syntax and associated OID for this
attribute type is provided in the ASN.1 modules in Appendix A. attribute type is provided in the ASN.1 modules in Appendix A.
Certificate users MUST be prepared to process the issuer Certificate users MUST be prepared to process the issuer
distinguished name and subject distinguished name (section 4.1.2.6) distinguished name and subject distinguished name (section 4.1.2.6)
fields to perform name chaining for certification path validation fields to perform name chaining for certification path validation
(section 6). Name chaining is performed by matching the issuer (section 6). Name chaining is performed by matching the issuer
distinguished name in one certificate with the subject name in a CA distinguished name in one certificate with the subject name in a CA
certificate. certificate.
This specification requires only a subset of the name comparison This specification requires only a subset of the name comparison
functionality specified in the X.500 series of specifications. The functionality specified in the X.500 series of specifications. The
requirements for conforming implementations are as follows: requirements for conforming implementations are as follows:
(a) attribute values encoded in different types (e.g., (a) attribute values encoded in different types (e.g.,
PrintableString and BMPString) MAY be assumed to represent PrintableString and BMPString) MAY be assumed to represent
different strings; different strings;
(b) attribute values in types other than PrintableString are case (b) attribute values in types other than PrintableString are case
sensitive (this permits matching of attribute values as binary sensitive (this permits matching of attribute values as binary
objects); objects);
(c) attribute values in PrintableString are not case sensitive (c) attribute values in PrintableString are not case sensitive
(e.g., "Marianne Swanson" is the same as "MARIANNE SWANSON"); and (e.g., "Marianne Swanson" is the same as "MARIANNE SWANSON"); and
(d) attribute values in PrintableString are compared after (d) attribute values in PrintableString are compared after
removing leading and trailing white space and converting internal removing leading and trailing white space and converting internal
substrings of one or more consecutive white space characters to a substrings of one or more consecutive white space characters to a
single space. single space.
These name comparison rules permit a certificate user to validate These name comparison rules permit a certificate user to validate
certificates issued using languages or encodings unfamiliar to the certificates issued using languages or encodings unfamiliar to the
certificate user. certificate user.
In addition, implementations of this specification MAY use these In addition, implementations of this specification MAY use these
comparison rules to process unfamiliar attribute types for name comparison rules to process unfamiliar attribute types for name
skipping to change at page 25, line 16 skipping to change at page 25, line 16
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 field (section 4.2.1.7) to describe such identities. alternative name field (section 4.2.1.7) to describe such identities.
Simultaneous inclusion of the EmailAddress attribute in the subject Simultaneous inclusion of the EmailAddress attribute in the subject
distinguished name to support legacy implementations is deprecated distinguished name to support legacy implementations is deprecated
but permitted. but permitted.
4.1.2.7 Subject Public Key Info 4.1.2.7 Subject Public Key Info
This field is used to carry the public key and identify the algorithm This field is used to carry the public key and identify the algorithm
with which the key is used. The algorithm is identified using the with which the key is used (e.g., RSA, DSA, or Diffie-Hellman). The
AlgorithmIdentifier structure specified in section 4.1.1.2. The algorithm is identified using the AlgorithmIdentifier structure
object identifiers for the supported algorithms and the methods for specified in section 4.1.1.2. The object identifiers for the
encoding the public key materials (public key and parameters) are supported algorithms and the methods for encoding the public key
specified in [PKIXALGS]. materials (public key and parameters) are specified in [PKIXALGS].
4.1.2.8 Unique Identifiers 4.1.2.8 Unique Identifiers
These fields MUST only appear if the version is 2 or 3 (section These fields MUST only appear if the version is 2 or 3 (section
4.1.2.1). These fields MUST NOT appear if the version is 1. The 4.1.2.1). These fields MUST NOT appear if the version is 1. The
subject and issuer unique identifiers are present in the certificate subject and issuer unique identifiers are present in the certificate
to handle the possibility of reuse of subject and/or issuer names to handle the possibility of reuse of subject and/or issuer names
over time. This profile RECOMMENDS that names not be reused for over time. This profile RECOMMENDS that names not be reused for
different entities and that Internet certificates not make use of different entities and that Internet certificates not make use of
unique identifiers. CAs conforming to this profile SHOULD NOT unique identifiers. CAs conforming to this profile SHOULD NOT
skipping to change at page 25, line 42 skipping to change at page 25, line 42
conforming to this profile SHOULD be capable of parsing unique conforming to this profile SHOULD be capable of parsing unique
identifiers and making comparisons. identifiers and making comparisons.
4.1.2.9 Extensions 4.1.2.9 Extensions
This field MUST only appear if the version is 3 (section 4.1.2.1). This field MUST only appear if the version is 3 (section 4.1.2.1).
If present, this field is a SEQUENCE of one or more certificate If present, this field is a SEQUENCE of one or more certificate
extensions. The format and content of certificate extensions in the extensions. The format and content of certificate extensions in the
Internet PKI is defined in section 4.2. Internet PKI is defined in section 4.2.
4.2 Standard Certificate Extensions 4.2 Certificate Extensions
The extensions defined for X.509 v3 certificates provide methods for The extensions defined for X.509 v3 certificates provide methods for
associating additional attributes with users or public keys and for associating additional attributes with users or public keys and for
managing the certification hierarchy. The X.509 v3 certificate managing the certification hierarchy. The X.509 v3 certificate
format also allows communities to define private extensions to carry format also allows communities to define private extensions to carry
information unique to those communities. Each extension in a information unique to those communities. Each extension in a
certificate is designated as either critical or non-critical. A certificate is designated as either critical or non-critical. A
certificate using system MUST reject the certificate if it encounters certificate using system MUST reject the certificate if it encounters
a critical extension it does not recognize; however, a non-critical a critical extension it does not recognize; however, a non-critical
extension MAY be ignored if it is not recognized. The following extension MAY be ignored if it is not recognized. The following
skipping to change at page 27, line 19 skipping to change at page 27, line 19
sign a certificate. This extension is used where an issuer has sign a certificate. This extension is used where an issuer has
multiple signing keys (either due to multiple concurrent key pairs or multiple signing keys (either due to multiple concurrent key pairs or
due to changeover). The identification MAY be based on either the due to changeover). The identification MAY be based on either the
key identifier (the subject key identifier in the issuer's key identifier (the subject key identifier in the issuer's
certificate) or on the issuer name and serial number. certificate) or on the issuer name and serial number.
The keyIdentifier field of the authorityKeyIdentifier extension MUST The keyIdentifier field of the authorityKeyIdentifier extension MUST
be included in all certificates generated by conforming CAs to be included in all certificates generated by conforming CAs to
facilitate chain building. There is one exception; where a CA facilitate chain building. There is one exception; where a CA
distributes its public key in the form of a "self-signed" distributes its public key in the form of a "self-signed"
certificate, the authority key identifier MAY be omitted. In this certificate, the authority key identifier MAY be omitted. The
case, the subject and authority key identifiers would be identical. signature on a self-signed certificate is generated with the private
key associated with the certificate's subject public key. (This
proves that the issuer possesses both the public and private keys.)
In this case, the subject and authority key identifiers would be
identical, but only the subject key identifier is needed for
certification path building.
The value of the keyIdentifier field SHOULD be derived from the The value of the keyIdentifier field SHOULD be derived from the
public key used to verify the certificate's signature or a method public key used to verify the certificate's signature or a method
that generates unique values. Two common methods for generating key that generates unique values. Two common methods for generating key
identifiers from the public key are described in (sec. 4.2.1.2). One identifiers from the public key are described in (sec. 4.2.1.2). One
common method for generating unique values is described in (sec. common method for generating unique values is described in (sec.
4.2.1.2). Where a key identifier has not been previously 4.2.1.2). Where a key identifier has not been previously
established, this specification recommends use of one of these established, this specification recommends use of one of these
methods for generating keyIdentifiers. methods for generating keyIdentifiers.
skipping to change at page 28, line 21 skipping to change at page 28, line 30
identifier is an explicit value placed in the certificate by the identifier is an explicit value placed in the certificate by the
issuer, not a value generated by a certificate user. Two common issuer, not a value generated by a certificate user. Two common
methods for generating key identifiers from the public key are: methods for generating key identifiers from the public key are:
(1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
value of the BIT STRING subjectPublicKey (excluding the tag, value of the BIT STRING subjectPublicKey (excluding the tag,
length, and number of unused bits). length, and number of unused bits).
(2) The keyIdentifier is composed of a four bit type field with (2) The keyIdentifier is composed of a four bit type field with
the value 0100 followed by the least significant 60 bits of the the value 0100 followed by the least significant 60 bits of the
SHA-1 hash of the value of the BIT STRING subjectPublicKey. SHA-1 hash of the value of the BIT STRING subjectPublicKey
(excluding the tag, length, and number of unused bit string bits).
One common method for generating unique values is a monotonically One common method for generating unique values is a monotonically
increasing sequence of integers. increasing sequence of integers.
For end entity certificates, the subject key identifier extension For end entity certificates, the subject key identifier extension
provides a means for identifying certificates containing the provides a means for identifying certificates containing the
particular public key used in an application. Where an end entity particular public key used in an application. Where an end entity
has obtained multiple certificates, especially from multiple CAs, the has obtained multiple certificates, especially from multiple CAs, the
subject key identifier provides a means to quickly identify the set subject key identifier provides a means to quickly identify the set
of certificates containing a particular public key. To assist of certificates containing a particular public key. To assist
skipping to change at page 30, line 45 skipping to change at page 30, line 51
used only for deciphering data while performing key agreement. used only for deciphering data while performing key agreement.
This profile does not restrict the combinations of bits that may be This profile does not restrict the combinations of bits that may be
set in an instantiation of the keyUsage extension. However, set in an instantiation of the keyUsage extension. However,
appropriate values for keyUsage extensions for particular algorithms appropriate values for keyUsage extensions for particular algorithms
are specified in [PKIXALGS]. are specified in [PKIXALGS].
4.2.1.4 Private Key Usage Period 4.2.1.4 Private Key Usage Period
This profile RECOMMENDS against the use of this extension. CAs This profile RECOMMENDS against the use of this extension. CAs
conforming to this profile MUST NOT generate certificates with conforming to this profile MUST NOT generate certificates that
critical private key usage period extensions. include a critical private key usage period extension.
The private key usage period extension allows the certificate issuer The private key usage period extension allows the certificate issuer
to specify a different validity period for the private key than the to specify a different validity period for the private key than the
certificate. This extension is intended for use with digital certificate. This extension is intended for use with digital
signature keys. This extension consists of two optional components, signature keys. This extension consists of two optional components,
notBefore and notAfter. The private key associated with the notBefore and notAfter. The private key associated with the
certificate SHOULD NOT be used to sign objects before or after the certificate SHOULD NOT be used to sign objects before or after the
times specified by the two components, respectively. CAs conforming times specified by the two components, respectively. CAs conforming
to this profile MUST NOT generate certificates with private key usage to this profile MUST NOT generate certificates with private key usage
period extensions unless at least one of the two components is period extensions unless at least one of the two components is
skipping to change at page 33, line 50 skipping to change at page 34, line 8
utf8String UTF8String (SIZE (1..200)) } utf8String UTF8String (SIZE (1..200)) }
4.2.1.6 Policy Mappings 4.2.1.6 Policy Mappings
This extension is used in CA certificates. It lists one or more This extension is used in CA certificates. It lists one or more
pairs of OIDs; each pair includes an issuerDomainPolicy and a pairs of OIDs; each pair includes an issuerDomainPolicy and a
subjectDomainPolicy. The pairing indicates the issuing CA considers subjectDomainPolicy. The pairing indicates the issuing CA considers
its issuerDomainPolicy equivalent to the subject CA's its issuerDomainPolicy equivalent to the subject CA's
subjectDomainPolicy. subjectDomainPolicy.
The issuing CA's users MAY accept an issuerDomainPolicy for certain The issuing CA's users might accept an issuerDomainPolicy for certain
applications. The policy mapping tells the issuing CA's users which applications. The policy mapping defines the list of policies
policies associated with the subject CA are comparable to the policy associated with the subject CA that may be accepted as comparable to
they accept. the issuerDomainPolicy.
Each issuerDomainPolicy named in the policy mapping extension SHOULD Each issuerDomainPolicy named in the policy mapping extension SHOULD
also be asserted in a certificate policies extension in the same also be asserted in a certificate policies extension in the same
certificate. Policies SHOULD NOT be mapped either to or from the certificate. Policies SHOULD NOT be mapped either to or from the
special value anyPolicy (section 4.2.1.5). special value anyPolicy (section 4.2.1.5).
This extension MAY be supported by CAs and/or applications, and it This extension MAY be supported by CAs and/or applications, and it
MUST be non-critical. MUST be non-critical.
id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 }
skipping to change at page 34, line 30 skipping to change at page 34, line 36
4.2.1.7 Subject Alternative Name 4.2.1.7 Subject Alternative Name
The subject alternative names extension allows additional identities The subject alternative names extension allows additional identities
to be bound to the subject of the certificate. Defined options to be bound to the subject of the certificate. Defined options
include an Internet electronic mail address, a DNS name, an IP include an Internet electronic mail address, a DNS name, an IP
address, and a uniform resource identifier (URI). Other options address, and a uniform resource identifier (URI). Other options
exist, including completely local definitions. Multiple name forms, exist, including completely local definitions. Multiple name forms,
and multiple instances of each name form, MAY be included. Whenever and multiple instances of each name form, MAY be included. Whenever
such identities are to be bound into a certificate, the subject such identities are to be bound into a certificate, the subject
alternative name (or issuer alternative name) extension MUST be used. alternative name (or issuer alternative name) extension MUST be used;
however, a DNS name MAY be represented in the subject field using the
domainComponent attribute as described in section 4.1.2.4.
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, the subjectAltName extension MUST be contains an empty sequence, the subjectAltName extension MUST be
marked critical. marked critical.
When the subjectAltName extension contains an Internet mail address, When the subjectAltName extension contains an Internet mail address,
the address MUST be included as an rfc822Name. The format of an the address MUST be included as an rfc822Name. The format of an
rfc822Name is an "addr-spec" as defined in RFC 822 [RFC 822]. An rfc822Name is an "addr-spec" as defined in RFC 822 [RFC 822]. An
addr-spec has the form "local-part@domain". Note that an addr-spec addr-spec has the form "local-part@domain". Note that an addr-spec
has no phrase (such as a common name) before it, has no comment (text has 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
">". Note that while upper and lower case letters are allowed in an ">". Note that while upper and lower case letters are allowed in an
RFC 822 addr-spec, no significance is attached to the case. RFC 822 addr-spec, no significance is attached to the case.
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 [RFC 791]. The least significant bit (LSB) of specified in RFC 791 [RFC 791]. The least significant bit (LSB) of
each octet is the LSB of the corresponding byte in the network each octet is the LSB of the corresponding byte in the network
address. For IP Version 4, as specified in RFC 791, the octet string address. For IP Version 4, as specified in RFC 791, the octet string
skipping to change at page 37, line 20 skipping to change at page 37, line 28
Where present, this extension SHOULD NOT be marked critical. Where present, this extension SHOULD NOT be marked critical.
id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 }
IssuerAltName ::= GeneralNames IssuerAltName ::= GeneralNames
4.2.1.9 Subject Directory Attributes 4.2.1.9 Subject Directory Attributes
The subject directory attributes extension is used to convey The subject directory attributes extension is used to convey
identification attributes (e.g.,nationality) of the subject. The identification attributes (e.g., nationality) of the subject. The
extension is defined as a sequence of one or more attributes. This extension is defined as a sequence of one or more attributes. This
extension MUST be non-critical. extension MUST be non-critical.
id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 }
SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute
4.2.1.10 Basic Constraints 4.2.1.10 Basic Constraints
The basic constraints extension identifies whether the subject of the The basic constraints extension identifies whether the subject of the
certificate is a CA and the maximum depth of valid certification certificate is a CA and the maximum depth of valid certification
paths that include this certificate. paths that include this certificate.
The cA bit indicates whether the certified public key belongs to a The cA boolean indicates whether the certified public key belongs to
CA. If the cA bit is not asserted, then the keyCertSign bit in the a CA. If the cA boolean is not asserted, then the keyCertSign bit in
key usage extension MUST NOT be asserted. the key usage extension MUST NOT be asserted.
The pathLenConstraint field is meaningful only if the cA bit is The pathLenConstraint field is meaningful only if the cA boolean is
asserted and the key usage extension asserts the keyCertSign bit asserted and the key usage extension asserts the keyCertSign bit
(section 4.2.1.3). In this case, it gives the maximum number of non- (section 4.2.1.3). In this case, it gives the maximum number of non-
self-issued intermediate certificates that may follow this self-issued intermediate certificates that may follow this
certificate in a valid certification path. A certificate is self- certificate in a valid certification path. A certificate is self-
issued if the DNs that appear in the subject and issuer fields are issued if the DNs that appear in the subject and issuer fields are
identical and are not empty. (Note: The last certificate in the identical and are not empty. (Note: The last certificate in the
certification path is not an intermediate certificate, and is not certification path is not an intermediate certificate, and is not
included in this limit. Usually, the last certificate is an end included in this limit. Usually, the last certificate is an end
entity certificate, but it can be a CA certificate.) A entity certificate, but it can be a CA certificate.) A
pathLenConstraint of zero indicates that only one more certificate pathLenConstraint of zero indicates that only one more certificate
skipping to change at page 38, line 17 skipping to change at page 38, line 24
signatures on certificates. This extension MAY appear as a critical signatures on certificates. This extension MAY appear as a critical
or non-critical extension in CA certificates that contain public keys or non-critical extension in CA certificates that contain public keys
used exclusively for purposes other than validating digital used exclusively for purposes other than validating digital
signatures on certificates. Such CA certificates include ones that signatures on certificates. Such CA certificates include ones that
contain public keys used exclusively for validating digital contain public keys used exclusively for validating digital
signatures on CRLs and ones that contain key management public keys signatures on CRLs and ones that contain key management public keys
used with certificate enrollment protocols. This extension MAY used with certificate enrollment protocols. This extension MAY
appear as a critical or non-critical extension in end entity appear as a critical or non-critical extension in end entity
certificates. certificates.
CAs MUST NOT include the pathLenConstraint field unless the cA bit is CAs MUST NOT include the pathLenConstraint field unless the cA
asserted and the key usage extension asserts the keyCertSign bit. boolean is asserted and the key usage extension asserts the
keyCertSign bit.
id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 }
BasicConstraints ::= SEQUENCE { BasicConstraints ::= SEQUENCE {
cA BOOLEAN DEFAULT FALSE, cA BOOLEAN DEFAULT FALSE,
pathLenConstraint INTEGER (0..MAX) OPTIONAL } pathLenConstraint INTEGER (0..MAX) OPTIONAL }
4.2.1.11 Name Constraints 4.2.1.11 Name Constraints
The name constraints extension, which MUST be used only in a CA The name constraints extension, which MUST be used only in a CA
certificate, indicates a name space within which all subject names in certificate, indicates a name space within which all subject names in
subsequent certificates in a certification path MUST be located. subsequent certificates in a certification path MUST be located.
Restrictions apply to the subject distinguished name and apply to Restrictions apply to the subject distinguished name and apply to
subject alternative names. Restrictions apply only when the subject alternative names. Restrictions apply only when the
specified name form is present. If no name of the type is in the specified name form is present. If no name of the type is in the
certificate, the certificate is acceptable. certificate, the certificate is acceptable.
Name constraints are not applied to certificates whose issuer and Name constraints are not applied to certificates whose issuer and
subject are identical (unless the certificate is the final subject are identical (unless the certificate is the final
certificate in the path). (This could prevent CAs that use name certificate in the path). (This could prevent CAs that use name
constraints from issuing self-signed certificates to implement key constraints from employing self-issued certificates to implement key
rollover.) rollover.)
Restrictions are defined in terms of permitted or excluded name Restrictions are defined in terms of permitted or excluded name
subtrees. Any name matching a restriction in the excludedSubtrees subtrees. Any name matching a restriction in the excludedSubtrees
field is invalid regardless of information appearing in the field is invalid regardless of information appearing in the
permittedSubtrees. This extension MUST be critical. permittedSubtrees. This extension MUST be critical.
Within this profile, the minimum and maximum fields are not used with Within this profile, the minimum and maximum fields are not used with
any name forms, thus minimum is always zero, and maximum is always any name forms, thus minimum is always zero, and maximum is always
absent. absent.
skipping to change at page 41, line 8 skipping to change at page 41, line 17
If the requireExplicitPolicy field is present, subsequent If the requireExplicitPolicy field is present, subsequent
certificates MUST include an acceptable policy identifier. The value certificates MUST include an acceptable policy identifier. The value
of requireExplicitPolicy indicates the number of additional of requireExplicitPolicy indicates the number of additional
certificates that may appear in the path before an explicit policy is certificates that may appear in the path before an explicit policy is
required. An acceptable policy identifier is the identifier of a required. An acceptable policy identifier is the identifier of a
policy required by the user of the certification path or the policy required by the user of the certification path or the
identifier of a policy which has been declared equivalent through identifier of a policy which has been declared equivalent through
policy mapping. policy mapping.
Conforming CAs MUST NOT issue certificates where policy constraints Conforming CAs MUST NOT issue certificates where policy constraints
is a null sequence. That is, at least one of the inhibitPolicyMapping is a empty sequence. That is, at least one of the
field or the requireExplicitPolicy field MUST be present. The inhibitPolicyMapping field or the requireExplicitPolicy field MUST be
behavior of clients that encounter a null policy constraints field is present. The behavior of clients that encounter a empty policy
not addressed in this profile. constraints field is not addressed in this profile.
This extension MAY be critical or non-critical. This extension MAY be critical or non-critical.
id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 }
PolicyConstraints ::= SEQUENCE { PolicyConstraints ::= SEQUENCE {
requireExplicitPolicy [0] SkipCerts OPTIONAL, requireExplicitPolicy [0] SkipCerts OPTIONAL,
inhibitPolicyMapping [1] SkipCerts OPTIONAL } inhibitPolicyMapping [1] SkipCerts OPTIONAL }
SkipCerts ::= INTEGER (0..MAX) SkipCerts ::= INTEGER (0..MAX)
skipping to change at page 41, line 39 skipping to change at page 41, line 48
field is defined as follows: field is defined as follows:
id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 } id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 }
ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
KeyPurposeId ::= OBJECT IDENTIFIER KeyPurposeId ::= OBJECT IDENTIFIER
Key purposes may be defined by any organization with a need. Object Key purposes may be defined by any organization with a need. Object
identifiers used to identify key purposes MUST be assigned in identifiers used to identify key purposes MUST be assigned in
accordance with IANA or ITU-T Recommendation X.660 | ISO/IEC/ITU accordance with IANA or ITU-T Recommendation X.660.
9834-1.
This extension MAY, at the option of the certificate issuer, be This extension MAY, at the option of the certificate issuer, be
either critical or non-critical. either critical or non-critical.
If the extension is flagged critical, then the certificate MUST only If the extension is flagged critical, then the certificate MUST only
be used for one of the purposes indicated. If multiple purposes are be used for one of the purposes indicated. If multiple purposes are
indicated the application need not recognize all purposes indicated, indicated the application need not recognize all purposes indicated,
as long as the intended purpose is present and recognized. as long as the intended purpose is present and recognized.
If the extension is flagged non-critical, then it indicates the If the extension is flagged non-critical, then it indicates the
skipping to change at page 45, line 4 skipping to change at page 45, line 10
policy is no longer permitted. For example, a value of one indicates policy is no longer permitted. For example, a value of one indicates
that any-policy may be processed in certificates issued by the that any-policy may be processed in certificates issued by the
subject of this certificate, but not in additional certificates in subject of this certificate, but not in additional certificates in
the path. the path.
This extension MUST be critical. This extension MUST be critical.
id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 } id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 }
InhibitAnyPolicy ::= SkipCerts InhibitAnyPolicy ::= SkipCerts
SkipCerts ::= INTEGER (0..MAX) SkipCerts ::= INTEGER (0..MAX)
4.2.1.16 Freshest CRL (a.k.a. Delta CRL Distribution Point) 4.2.1.16 Freshest CRL (a.k.a. Delta CRL Distribution Point)
The freshest CRL extension identifies how delta CRL information is The freshest CRL extension identifies how delta CRL information is
obtained. The extension MUST be non-critical. Further discussion of obtained. The extension MUST be non-critical. Further discussion of
CRL management is contained in section 5. CRL management is contained in section 5.
The same syntax is used for this extension and the The same syntax is used for this extension and the
cRLDistributionPoints extension, and is described in section cRLDistributionPoints extension, and is described in section
4.2.1.14. The same conventions apply to both extensions. 4.2.1.14. The same conventions apply to both extensions.
id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 }
FreshestCRL ::= CRLDistributionPoints FreshestCRL ::= CRLDistributionPoints
4.2.2 Private Internet Extensions 4.2.2 Private Internet Extensions
This section defines one new extension for use in the Internet Public This section defines two extensions for use in the Internet Public
Key Infrastructure. This extension may be used to direct Key Infrastructure. These extensions may be used to direct
applications to identify an on-line validation service supporting the applications to on-line information about the issuing CA or the
issuing CA. As the information may be available in multiple forms, subject. As the information may be available in multiple forms, each
each extension is a sequence of IA5String values, each of which extension is a sequence of IA5String values, each of which represents
represents a URI. The URI implicitly specifies the location and a URI. The URI implicitly specifies the location and format of the
format of the information and the method for obtaining the information and the method for obtaining the information.
information.
An object identifier is defined for the private extension. The An object identifier is defined for the private extension. The
object identifier associated with the private extension is defined object identifier associated with the private extension is defined
under the arc id-pe within the id-pkix name space. Any future under the arc id-pe within the arc id-pkix. Any future extensions
extensions defined for the Internet PKI will also be defined under defined for the Internet PKI are also expected to be defined under
the arc id-pe. the arc id-pe.
id-pkix OBJECT IDENTIFIER ::= id-pkix OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) } security(5) mechanisms(5) pkix(7) }
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
4.2.2.1 Authority Information Access 4.2.2.1 Authority Information Access
skipping to change at page 47, line 47 skipping to change at page 48, line 4
the protocol specifications for other services. the protocol specifications for other services.
The id-ad-caRepository OID is used when the subject is a CA, and The id-ad-caRepository OID is used when the subject is a CA, and
publishes its certificates and CRLs (if issued) in a repository. The publishes its certificates and CRLs (if issued) in a repository. The
accessLocation field is defined as a GeneralName, which can take accessLocation field is defined as a GeneralName, which can take
several forms. Where the information is available via http, ftp, or several forms. Where the information is available via http, ftp, or
ldap, accessLocation MUST be a uniformResourceIdentifier. Where the ldap, accessLocation MUST be a uniformResourceIdentifier. Where the
information is available via the directory access protocol (dap), information is available via the directory access protocol (dap),
accessLocation MUST be a directoryName. When the information is accessLocation MUST be a directoryName. When the information is
available via electronic mail, accessLocation MUST be an rfc822Name. available via electronic mail, accessLocation MUST be an rfc822Name.
The semantics of other name forms of of accessLocation (when The semantics of other name forms of of accessLocation (when
accessMethod is id-ad-caRepository) are not defined by this accessMethod is id-ad-caRepository) are not defined by this
specification. specification.
The id-ad-timeStamping OID is used when the subject offers The id-ad-timeStamping OID is used when the subject offers
timestamping services using the Time Stamp Protocol defined in timestamping services using the Time Stamp Protocol defined in
[PKIXTSA]. Where the timestamping services are available via http or [PKIXTSA]. Where the timestamping services are available via http or
ftp, accessLocation MUST be a uniformResourceIdentifier. Where the ftp, accessLocation MUST be a uniformResourceIdentifier. Where the
timestamping services are available via electronic mail, timestamping services are available via electronic mail,
accessLocation MUST be an rfc822Name. Where timestamping services accessLocation MUST be an rfc822Name. Where timestamping services
are available using TCP/IP, the dNSName and ipAddress name forms may are available using TCP/IP, the dNSName or ipAddress name forms may
be used. The semantics of other name forms of accessLocation (when be used. The semantics of other name forms of accessLocation (when
accessMethod is id-ad-timeStamping) are not defined by this accessMethod is id-ad-timeStamping) are not defined by this
specification. specification.
Additional access descriptors may be defined in other PKIX Additional access descriptors may be defined in other PKIX
specifications. specifications.
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 } id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 }
skipping to change at page 49, line 28 skipping to change at page 49, line 35
Environments with additional or special purpose requirements may Environments with additional or special purpose requirements may
build on this profile or may replace it. build on this profile or may replace it.
Conforming CAs are not required to issue CRLs if other revocation or Conforming CAs are not required to issue CRLs if other revocation or
certificate status mechanisms are provided. Conforming CAs that certificate status mechanisms are provided. Conforming CAs that
issue CRLs MUST issue version 2 CRLs, include the date by which the issue CRLs MUST issue version 2 CRLs, include the date by which the
next CRL will be issued in the nextUpdate field (section 5.1.2.5), next CRL will be issued in the nextUpdate field (section 5.1.2.5),
include the CRL number extension (section 5.2.3), and include the include the CRL number extension (section 5.2.3), and include the
authority key identifier extension (section 5.2.1). Conforming authority key identifier extension (section 5.2.1). Conforming
applications that support CRLs are required to process both version 1 applications that support CRLs are required to process both version 1
and 2 CRLs that are complete for a given scope. Conforming and version 2 complete CRLs that provide revocation information for
applications are not required to support processing of delta CRLs or all certificates issued by one CA. Conforming applications are not
indirect CRLs. required to support processing of delta CRLs, indirect CRLs, or CRLs
with a scope other than all certificates issued by the CA.
5.1 CRL Fields 5.1 CRL Fields
The X.509 v2 CRL syntax is as follows. For signature calculation, The X.509 v2 CRL syntax is as follows. For signature calculation,
the data that is to be signed is ASN.1 DER encoded. ASN.1 DER the data that is to be signed is ASN.1 DER encoded. ASN.1 DER
encoding is a tag, length, value encoding system for each element. encoding is a tag, length, value encoding system for each element.
CertificateList ::= SEQUENCE { CertificateList ::= SEQUENCE {
tbsCertList TBSCertList, tbsCertList TBSCertList,
signatureAlgorithm AlgorithmIdentifier, signatureAlgorithm AlgorithmIdentifier,
skipping to change at page 54, line 31 skipping to change at page 54, line 31
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 names extension allows additional identities The issuer alternative names extension allows additional identities
to be associated with the issuer of the CRL. Defined options include to be associated with the issuer of the CRL. Defined options include
an rfc822 name (electronic mail address), a DNS name, an IP address, an rfc822 name (electronic mail address), a DNS name, an IP address,
and a URI. Multiple instances of a name and multiple name forms may and a URI. Multiple instances of a name and multiple name forms 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. alternative name extension MUST be used; however, a DNS name MAY be
represented in the issuer field using the domainComponent attribute
as described in section 4.1.2.4.
The issuerAltName extension SHOULD NOT be marked critical. The issuerAltName extension SHOULD NOT be marked 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.8. 4.2.1.8.
5.2.3 CRL Number 5.2.3 CRL Number
The CRL number is a non-critical CRL extension which conveys a The CRL number is a non-critical CRL extension which conveys a
monotonically increasing sequence number for a given CRL scope and monotonically increasing sequence number for a given CRL scope and
skipping to change at page 55, line 33 skipping to change at page 55, line 35
that would appear in a complete CRL. The use of delta CRLs can that would appear in a complete CRL. The use of delta CRLs can
significantly reduce network load and processing time in some significantly reduce network load and processing time in some
environments. Delta CRLs are generally smaller than the CRLs they environments. Delta CRLs are generally smaller than the CRLs they
update, so applications that obtain delta CRLs consume less network update, so applications that obtain delta CRLs consume less network
bandwidth than applications that obtain the corresponding complete bandwidth than applications that obtain the corresponding complete
CRLs. Applications which store revocation information in a format CRLs. Applications which store revocation information in a format
other than the CRL structure can add new revocation information to other than the CRL structure can add new revocation information to
the local database without reprocessing information. the local database without reprocessing information.
The delta CRL indicator extension contains the single value of type The delta CRL indicator extension contains the single value of type
BaseCRLNumber. This value identifies the CRL number of the complete BaseCRLNumber. The CRL number identifies the CRL, complete for a
CRL that was used as the foundation in the generation of this delta given scope, that was used as the starting point in the generation of
CRL. The referenced base CRL is a CRL that was explicitly issued as this delta CRL. A conforming CRL issuer MUST publish the referenced
a CRL that is complete for a given scope. The CRL containing the base CRL as a complete CRL. The delta CRL contains all updates to
delta CRL indicator extension contains all updates to the revocation the revocation status for that same scope. The combination of a
status for that same scope. The combination of a CRL containing the delta CRL plus the referenced base CRL is equivalent to a complete
delta CRL indicator extension plus the CRL referenced in the
BaseCRLNumber component of this extension is equivalent to a complete
CRL, for the applicable scope, at the time of publication of the CRL, for the applicable scope, at the time of publication of the
delta CRL. delta CRL.
When a conforming CRL issuer generates a delta CRL, the delta CRL When a conforming CRL issuer generates a delta CRL, the delta CRL
MUST include a critical delta CRL indicator extension. MUST include a critical delta CRL indicator extension.
When a delta CRL is issued, it MUST cover the same set of reasons and When a delta CRL is issued, it MUST cover the same set of reasons and
the same set of certificates that were covered by the base CRL it the same set of certificates that were covered by the base CRL it
references. That is, the scope of the delta CRL MUST be the same as references. That is, the scope of the delta CRL MUST be the same as
the scope of the complete CRL referenced as the base. The referenced the scope of the complete CRL referenced as the base. The referenced
skipping to change at page 56, line 38 skipping to change at page 56, line 38
CRLs have the same scope if either of the following conditions are CRLs have the same scope if either of the following conditions are
met: met:
(1) The issuingDistributionPoint extension is omitted from (1) The issuingDistributionPoint extension is omitted from
both the complete CRL and the delta CRL. both the complete CRL and the delta CRL.
(2) The issuingDistributionPoint extension is present in both (2) The issuingDistributionPoint extension is present in both
the complete CRL and the delta CRL, and the values for each of the complete CRL and the delta CRL, and the values for each of
the fields in the extensions are the same in both CRLs. the fields in the extensions are the same in both CRLs.
(c) The CRL number of the complete CRL is greater than or equal (c) The CRL number of the complete CRL is equal to or greater
to the BaseCRLNumber specified in the delta CRL. That is, the than the BaseCRLNumber specified in the delta CRL. That is, the
complete CRL contains (at a minimum) all the revocation complete CRL contains (at a minimum) all the revocation
information held by the referenced base CRL. information held by the referenced base CRL.
(d) The CRL number of the complete CRL is less than the CRL (d) The CRL number of the complete CRL is less than the CRL
number of the delta CRL. That is, the delta CRL follows the number of the delta CRL. That is, the delta CRL follows the
complete CRL in the numbering sequence. complete CRL in the numbering sequence.
CRL issuers MUST ensure that the combination of a delta CRL and any CRL issuers MUST ensure that the combination of a delta CRL and any
appropriate complete CRL accurately reflects the current revocation appropriate complete CRL accurately reflects the current revocation
status. The CRL issuer MUST include an entry in the delta CRL for status. The CRL issuer MUST include an entry in the delta CRL for
each certificate within the scope of the delta CRL whose status has each certificate within the scope of the delta CRL whose status has
changed since the generation of the referenced base CRL: changed since the generation of the referenced base CRL:
(a) If the certificate is revoked for a reason included in the (a) If the certificate is revoked for a reason included in the
scope of the CRL, list the certificate as revoked. scope of the CRL, list the certificate as revoked.
(b) If not (a), list the certificate with the reason code (b) If the certificate is valid and was listed on the referenced
removeFromCRL. base CRL or any subsequent CRL with reason code certificateHold,
and the reason code certificateHold is included in the scope of
the CRL, list the certificate with the reason code removeFromCRL.
(c) If the certificate is revoked for a reason outside the scope
of the CRL, but the certificate was listed on the referenced base
CRL or any subsequent CRL with a reason code included in the scope
of this CRL, list the certificate as revoked but omit the reason
code.
(d) If the certificate is revoked for a reason outside the scope
of the CRL and the certificate was neither listed on the
referenced base CRL nor any subsequent CRL with a reason code
included in the scope of this CRL, do not list the certificate on
this CRL.
The status of a certificate is considered to have changed if it is The status of a certificate is considered to have changed if it is
revoked, placed on hold, released from hold, or if its revocation revoked, placed on hold, released from hold, or if its revocation
reason changes. reason changes.
It is appropriate to list a certificate with reason code It is appropriate to list a certificate with reason code
removeFromCRL on a delta CRL even if the certificate was not on hold removeFromCRL on a delta CRL even if the certificate was not on hold
in the referenced base CRL. If the certificate was placed on hold in in the referenced base CRL. If the certificate was placed on hold in
any CRL issued after the base but before this delta CRL and then any CRL issued after the base but before this delta CRL and then
released from hold, it MUST be listed on the delta CRL with released from hold, it MUST be listed on the delta CRL with
skipping to change at page 57, line 35 skipping to change at page 57, line 49
and the certificate was listed on the referenced base CRL or in any and the certificate was listed on the referenced base CRL or in any
CRL issued after the base but before this delta CRL. CRL issued after the base but before this delta CRL.
If a certificate revocation notice first appears on a delta CRL, then If a certificate revocation notice first appears on a delta CRL, then
it is possible for the certificate validity period to expire before it is possible for the certificate validity period to expire before
the next complete CRL for the same scope is issued. In this case, the next complete CRL for the same scope is issued. In this case,
the revocation notice MUST be included in all subsequent delta CRLs the revocation notice MUST be included in all subsequent delta CRLs
until the revocation notice is included on at least one explicitly until the revocation notice is included on at least one explicitly
issued complete CRL for this scope. issued complete CRL for this scope.
Applications that support delta CRLs are not required to support An application that supports delta CRLs MUST be able to construct a
local construction of CRLs. Since the delta CRLs are required to current complete CRL by combining a previously issued complete CRL
reference a base CRL that was explicitly issued as a complete CRL, and the most current delta CRL. An application that supports delta
the information required to process delta CRLs is always available in CRLs MAY also be able to construct a current complete CRL by
a complete CRL. combining a previously locally constructed complete CRL and the
current delta CRL. A delta CRL is considered to be the current one
if the current time is between the times contained in the thisUpdate
and nextUpdate fields. Under some circumstances, the CRL issuer may
publish one or more delta CRLs before indicated by the nextUpdate
field. If more than one current delta CRL for a given scope is
encountered, the application SHOULD consider the one with the latest
value in thisUpdate to be the most current one.
id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }
BaseCRLNumber ::= CRLNumber BaseCRLNumber ::= CRLNumber
5.2.5 Issuing Distribution Point 5.2.5 Issuing Distribution Point
The issuing distribution point is a critical CRL extension that The issuing distribution point is a critical CRL extension that
identifies the CRL distribution point and scope for a particular CRL, identifies the CRL distribution point and scope for a particular CRL,
and it indicates whether the CRL covers revocation for end entity and it indicates whether the CRL covers revocation for end entity
skipping to change at page 59, line 4 skipping to change at page 59, line 25
onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE,
onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE,
onlySomeReasons [3] ReasonFlags OPTIONAL, onlySomeReasons [3] ReasonFlags OPTIONAL,
indirectCRL [4] BOOLEAN DEFAULT FALSE, indirectCRL [4] BOOLEAN DEFAULT FALSE,
onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE } onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
5.2.6 Freshest CRL (a.k.a. Delta CRL Distribution Point) 5.2.6 Freshest CRL (a.k.a. Delta CRL Distribution Point)
The freshest CRL extension identifies how delta CRL information for The freshest CRL extension identifies how delta CRL information for
this complete CRL is obtained. The extension MUST be non-critical. this complete CRL is obtained. The extension MUST be non-critical.
This extension MUST NOT appear in delta CRLs. This extension MUST NOT appear in delta CRLs.
The same syntax is used for this extension as the The same syntax is used for this extension as the
cRLDistributionPoints certificate extension, and is described in cRLDistributionPoints certificate extension, and is described in
section 4.2.1.14. The same conventions apply to both extensions. section 4.2.1.14. However, only the distribution point field is
meaningful in this context. The reasons and CRLIssuer fields MUST be
omitted from this CRL extension.
Each distribution point name provides the location at which a delta
CRL for this complete CRL can be found. The scope of these delta
CRLs MUST be the same as the scope of this complete CRL. The
contents of this CRL extension are only used to locate delta CRLs;
the contents are not used to validate the CRL or the referenced delta
CRLs. The encoding conventions defined for distribution points in
section 4.2.1.14 apply to this extension.
id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 }
FreshestCRL ::= CRLDistributionPoints FreshestCRL ::= CRLDistributionPoints
5.3 CRL Entry Extensions 5.3 CRL Entry Extensions
The CRL entry extensions already defined by ANSI X9 and ISO/IEC/ITU The CRL entry extensions already defined by ANSI X9 and ISO/IEC/ITU
for X.509 v2 CRLs provide methods for associating additional for X.509 v2 CRLs provide methods for associating additional
attributes with CRL entries [X.509] [X9.55]. The X.509 v2 CRL format attributes with CRL entries [X.509] [X9.55]. The X.509 v2 CRL format
skipping to change at page 61, line 20 skipping to change at page 61, line 50
in Greenwich Mean Time (Zulu), and MUST be specified and interpreted in Greenwich Mean Time (Zulu), and MUST be specified and interpreted
as defined in section 4.1.2.5.2. as defined in section 4.1.2.5.2.
id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 }
invalidityDate ::= GeneralizedTime invalidityDate ::= GeneralizedTime
5.3.4 Certificate Issuer 5.3.4 Certificate Issuer
This CRL entry extension identifies the certificate issuer associated This CRL entry extension identifies the certificate issuer associated
with an entry in an indirect CRL, i.e. a CRL that has the indirectCRL with an entry in an indirect CRL, that is, a CRL that has the
indicator set in its issuing distribution point extension. If this indirectCRL indicator set in its issuing distribution point
extension is not present on the first entry in an indirect CRL, the extension. If this extension is not present on the first entry in an
certificate issuer defaults to the CRL issuer. On subsequent entries indirect CRL, the certificate issuer defaults to the CRL issuer. On
in an indirect CRL, if this extension is not present, the certificate subsequent entries in an indirect CRL, if this extension is not
issuer for the entry is the same as that for the preceding entry. present, the certificate issuer for the entry is the same as that for
This field is defined as follows: the preceding entry. This field is defined as follows:
id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 }
certificateIssuer ::= GeneralNames certificateIssuer ::= GeneralNames
If used by conforming CRL issuers, this extension MUST always be If used by conforming CRL issuers, this extension MUST always be
critical. If an implementation ignored this extension it could not critical. If an implementation ignored this extension it could not
correctly attribute CRL entries to certificates. This specification correctly attribute CRL entries to certificates. This specification
RECOMMENDS that implementations recognize this extension. RECOMMENDS that implementations recognize this extension.
skipping to change at page 62, line 21 skipping to change at page 63, line 4
constraints upon the set of paths which may be validated using this constraints upon the set of paths which may be validated using this
key. key.
The selection of a "most-trusted CA" is a matter of policy: it could The selection of a "most-trusted CA" is a matter of policy: it could
be the top CA in a hierarchical PKI; the CA that issued the be the top CA in a hierarchical PKI; the CA that issued the
verifier's own certificate(s); or any other CA in a network PKI. The verifier's own certificate(s); or any other CA in a network PKI. The
path validation procedure is the same regardless of the choice of path validation procedure is the same regardless of the choice of
"most-trusted CA." In addition, different applications may rely on "most-trusted CA." In addition, different applications may rely on
different "most-trusted CA", or may accept paths that begin with any different "most-trusted CA", or may accept paths that begin with any
of a set of "most-trusted CAs." of a set of "most-trusted CAs."
Section 6.2 describes methods for using the path validation algorithm Section 6.2 describes methods for using the path validation algorithm
in specific implementations. Two specific cases are discussed: the in specific implementations. Two specific cases are discussed: the
case where paths may begin with one of several trusted CAs; and where case where paths may begin with one of several trusted CAs; and where
compatibility with the PEM architecture is required. compatibility with the PEM architecture is required.
Section 6.3 describes the steps necessary to determine if a Section 6.3 describes the steps necessary to determine if a
certificate is revoked or on hold status when CRLs are the revocation certificate is revoked or on hold status when CRLs are the revocation
mechanism used by the certificate issuer. mechanism used by the certificate issuer.
6.1 Basic Path Validation 6.1 Basic Path Validation
This text describes an algorithm for X.509 path processing. A This text describes an algorithm for X.509 path processing. A
conformant implementation MUST include an X.509 path processing conformant implementation MUST include an X.509 path processing
procedure that is functionally equivalent to the external behavior of procedure that is functionally equivalent to the external behavior of
this algorithm. However, support for some of the certificate this algorithm. However, support for some of the certificate
extensions processed in this algorithm are OPTIONAL for compliant extensions processed in this algorithm are OPTIONAL for compliant
implementations. Clients that do not support these extensions MAY implementations. Clients that do not support these extensions MAY
omit the corresponding steps in the path validation algorithm. omit the corresponding steps in the path validation algorithm.
For example, clients are NOT REQUIRED to support the policy mapping For example, clients are NOT REQUIRED to support the policy mapping
extension. Clients that do not support this extension MAY omit the extension. Clients that do not support this extension MAY omit the
path validation steps where policy mappings are processed. Note that path validation steps where policy mappings are processed. Note that
clients MUST reject the certificate if it contains an unsupported clients MUST reject the certificate if it contains an unsupported
critical extension. critical extension.
The algorithm presented in this section validates the certificate
with respect to the current date and time. A conformant
implementation MAY also support validation with respect to some point
in the past. Note that mechanisms are not available for validating a
certificate with respect to a time outside the certificate validity
period.
The trust anchor is an input to the algorithm. There is no The trust anchor is an input to the algorithm. There is no
requirement that the same trust anchor be used to validate all requirement that the same trust anchor be used to validate all
certification paths. Different trust anchors MAY be used to validate certification paths. Different trust anchors MAY be used to validate
different paths, as discussed further in Section 6.2. different paths, as discussed further in Section 6.2.
The primary goal of path validation is to verify the binding between The primary goal of path validation is to verify the binding between
a subject distinguished name or subject alternative name and subject a subject distinguished name or a subject alternative name and
public key, as represented in the end entity certificate, based on subject public key, as represented in the end entity certificate,
the public key of the trust anchor. This requires obtaining a based on the public key of the trust anchor. This requires obtaining
sequence of certificates that support that binding. The procedure a sequence of certificates that support that binding. The procedure
performed to obtain this sequence of certificates is outside the performed to obtain this sequence of certificates is outside the
scope of this specification. scope of this specification.
To meet this goal, the path validation process verifies, among other To meet this goal, the path validation process verifies, among other
things, that a prospective certification path (a sequence of n things, that a prospective certification path (a sequence of n
certificates) satisfies the following conditions: certificates) satisfies the following conditions:
(a) for all x in {1, ..., n-1}, the subject of certificate x is (a) for all x in {1, ..., n-1}, the subject of certificate x is
the issuer of certificate x+1; the issuer of certificate x+1;
(b) certificate 1 is issued by the trust anchor; (b) certificate 1 is issued by the trust anchor;
(c) certificate n is the end entity certificate; and (c) certificate n is the certificate to be validated; and
(d) for all x in {1, ..., n}, the certificate was valid at the (d) for all x in {1, ..., n}, the certificate was valid at the
time in question. time in question.
A particular certification path may not, however, be appropriate for A particular certification path may not, however, be appropriate for
all applications. Therefore, an application MAY augment this all applications. Therefore, an application MAY augment this
algorithm to further limit the set of valid paths. The path algorithm to further limit the set of valid paths. The path
validation process also determines the set of certificate policies validation process also determines the set of certificate policies
that are valid for this path, based on the certificate policies that are valid for this path, based on the certificate policies
extension, policy mapping extension, policy constraints extension, extension, policy mapping extension, policy constraints extension,
and inhibit any-policy extension. To achieve this, the path and inhibit any-policy extension. To achieve this, the path
validation algorithm constructs a valid policy tree. If the set of validation algorithm constructs a valid policy tree. If the set of
skipping to change at page 64, line 46 skipping to change at page 65, line 35
| STOP | | STOP |
+-------+ +-------+
Figure 2. Certification Path Processing Flowchart Figure 2. Certification Path Processing Flowchart
6.1.1 Inputs 6.1.1 Inputs
This algorithm assumes the following seven inputs are provided to the This algorithm assumes the following seven inputs are provided to the
path processing logic: path processing logic:
(a) a prospective certification path of length n; (a) a prospective certification path of length n.
(b) the time, T, for which the validity of the path should be (b) the current date/time.
determined. This may be the current date/time, or some point in
the past.
(c) user-initial-policy-set: A set of certificate policy (c) user-initial-policy-set: A set of certificate policy
identifiers naming the policies that are acceptable to the identifiers naming the policies that are acceptable to the
certificate user. The user-initial-policy-set contains the special certificate user. The user-initial-policy-set contains the special
value any-policy if the user is not concerned about certificate value any-policy if the user is not concerned about certificate
policy. policy.
(d) trust anchor information, describing a CA that serves as a (d) trust anchor information, describing a CA that serves as a
trust anchor for the certification path. The trust anchor trust anchor for the certification path. The trust anchor
information includes: information includes:
(1) the trusted issuer name, (1) the trusted issuer name,
(2) the trusted public key algorithm,
(2) the trusted public key algorithm,
(3) the trusted public key, and (3) the trusted public key, and
(4) optionally, the trusted public key parameters associated (4) optionally, the trusted public key parameters associated
with the public key. with the public key.
The trust anchor information may be provided to the path The trust anchor information may be provided to the path
processing procedure in the form of a self-signed certificate. processing procedure in the form of a self-signed certificate.
The trusted anchor information is trusted because it was delivered The trusted anchor information is trusted because it was delivered
to the path processing procedure by some trustworthy out-of-band to the path processing procedure by some trustworthy out-of-band
procedure. If the trusted public key algorithm requires procedure. If the trusted public key algorithm requires
parameters, then the parameters are provided along with the parameters, then the parameters are provided along with the
trusted public key. trusted public key.
skipping to change at page 65, line 48 skipping to change at page 66, line 34
initial-policy-set. initial-policy-set.
(g) initial-any-policy-inhibit, which indicates whether the any- (g) initial-any-policy-inhibit, which indicates whether the any-
policy OID should be processed if it is included in a certificate. policy OID should be processed if it is included in a certificate.
6.1.2 Initialization 6.1.2 Initialization
The initialization phase establishes eleven state variables based The initialization phase establishes eleven state variables based
upon the seven inputs: upon the seven inputs:
(a) valid_policy_tree: A tree of certificate policies with their (a) valid_policy_tree: A tree of certificate policies with their
optional qualifiers; each of the leaves of the tree represents a optional qualifiers; each of the leaves of the tree represents a
valid policy at this stage in the certification path validation. valid policy at this stage in the certification path validation.
If valid policies exist at this stage in the certification path If valid policies exist at this stage in the certification path
validation, the depth of the tree is equal to the number of validation, the depth of the tree is equal to the number of
certificates in the chain that have been processed. If valid certificates in the chain that have been processed. If valid
policies do not exist at this stage in the certification path policies do not exist at this stage in the certification path
validation, the tree is set to NULL. Once the tree is set to NULL, validation, the tree is set to NULL. Once the tree is set to NULL,
policy processing ceases. policy processing ceases.
Each node in the valid_policy_tree includes four data objects: the Each node in the valid_policy_tree includes four data objects: the
valid policy, a set of associated policy qualifiers, a set of one valid policy, a set of associated policy qualifiers, a set of one
or more expected policy values, and a criticality indicator. If or more expected policy values, and a criticality indicator. If
the node is at depth x, the components of the node have the the node is at depth x, the components of the node have the
following semantics: following semantics:
(1) The valid_policy is a single policy OID representing a (1) The valid_policy is a single policy OID representing a
valid policy for the path of length x. valid policy for the path of length x.
(2) The qualifier_set is a set of policy qualifiers associated (2) The qualifier_set is a set of policy qualifiers associated
with the valid policy in certificate x. with the valid policy in certificate x.
(3) The criticality_indicator indicates whether the certificate (3) The criticality_indicator indicates whether the
policy extension in certificate x was marked as critical. certificate policy extension in certificate x was marked as
critical.
(4) The expected_policy_set contains one or more policy OIDs (4) The expected_policy_set contains one or more policy OIDs
that would satisfy this policy in the certificate x+1. that would satisfy this policy in the certificate x+1.
The initial value of the valid_policy_tree is a single node with The initial value of the valid_policy_tree is a single node with
valid_policy any-policy, an empty qualifier_set, an valid_policy any-policy, an empty qualifier_set, an
expected_policy_set with the single value any-policy, and a expected_policy_set with the single value any-policy, and a
criticality_indicator of FALSE. This node is considered to be at criticality_indicator of FALSE. This node is considered to be at
depth zero. depth zero.
Figure 3 is a graphic representation of the initial state of the Figure 3 is a graphic representation of the initial state of the
valid_policy_tree. Additional figures will use this format to valid_policy_tree. Additional figures will use this format to
skipping to change at page 68, line 9 skipping to change at page 68, line 44
used to verify the signature of a certificate. The used to verify the signature of a certificate. The
working_public_key_algorithm is initialized from the trusted working_public_key_algorithm is initialized from the trusted
public key algorithm provided in the trust anchor information. public key algorithm provided in the trust anchor information.
(h) working_public_key: the public key used to verify the (h) working_public_key: the public key used to verify the
signature of a certificate. The working_public_key is initialized signature of a certificate. The working_public_key is initialized
from the trusted public key provided in the trust anchor from the trusted public key provided in the trust anchor
information. information.
(i) working_public_key_parameters: parameters associated with the (i) working_public_key_parameters: parameters associated with the
current public key, that may required to verify a signature current public key, that may be required to verify a signature
(depending upon the algorithm). The working_public_key_parameters (depending upon the algorithm). The working_public_key_parameters
variable is initialized from the trusted public key parameters variable is initialized from the trusted public key parameters
provided in the trust anchor information. provided in the trust anchor information.
(j) working_issuer_name: the issuer distinguished name expected (j) working_issuer_name: the issuer distinguished name expected
in the next certificate in the chain. The working_issuer_name is in the next certificate in the chain. The working_issuer_name is
initialized to the trusted issuer provided in the trust anchor initialized to the trusted issuer provided in the trust anchor
information. information.
(k) max_path_length: this integer is initialized to n, and is (k) max_path_length: this integer is initialized to n, is
reset by the path length constraint field within the basic decremented for each non-self-issued certificate in the path, and
constraints extension of a CA certificate. may be reduced to the value in the path length constraint field
within the basic constraints extension of a CA certificate.
Upon completion of the initialization steps, perform the basic Upon completion of the initialization steps, perform the basic
certificate processing steps specified in 6.1.3. certificate processing steps specified in 6.1.3.
6.1.3 Basic Certificate Processing 6.1.3 Basic Certificate Processing
The basic path processing actions to be performed for certificate i The basic path processing actions to be performed for certificate i
are listed below. are listed below.
(a) Verify the basic certificate information. The certificate (a) Verify the basic certificate information. The certificate
MUST satisfy each of the following: MUST satisfy each of the following:
(1) The certificate was signed with the (1) The certificate was signed with the
working_public_key_algorithm using the working_public_key and working_public_key_algorithm using the working_public_key and
the working_public_key_parameters. the working_public_key_parameters.
(2) The certificate validity period includes time T. (2) The certificate validity period includes the current time.
(3) At time T, the certificate is not revoked and is not on (3) At the current time, the certificate is not revoked and is
hold status. This may be determined by obtaining the not on hold status. This may be determined by obtaining the
appropriate CRL (section 6.3), status information, or by out- appropriate CRL (section 6.3), status information, or by out-
of-band mechanisms. of-band mechanisms.
(4) The certificate issuer name is the working_issuer_name. (4) The certificate issuer name is the working_issuer_name.
(b) If certificate i is self-issued and it is not the final (b) If certificate i is self-issued and it is not the final
certificate in the path, skip this step for certificate i. certificate in the path, skip this step for certificate i.
Otherwise, verify that the subject name is within one of the Otherwise, verify that the subject name is within one of the
permitted_subtrees for X.500 distinguished names, and verify that permitted_subtrees for X.500 distinguished names, and verify that
each of the alternative names in the subjectAltName extension each of the alternative names in the subjectAltName extension
(critical or non-critical) is within one of the permitted_subtrees (critical or non-critical) is within one of the permitted_subtrees
for that name type. for that name type.
(c) If certificate i is self-issued and it is not the final (c) If certificate i is self-issued and it is not the final
certificate in the path, skip this step for certificate i. certificate in the path, skip this step for certificate i.
Otherwise, verify that the subject name is not within one of the Otherwise, verify that the subject name is not within one of the
excluded_subtrees for X.500 distinguished names, and verify that excluded_subtrees for X.500 distinguished names, and verify that
each of the alternative names in the subjectAltName extension each of the alternative names in the subjectAltName extension
(critical or non-critical) is not within one of the (critical or non-critical) is not within one of the
excluded_subtrees for that name type. excluded_subtrees for that name type.
(d) If the certificate policies extension is present in the (d) If the certificate policies extension is present in the
certificiate and the valid_policy_tree is not NULL, process the certificiate and the valid_policy_tree is not NULL, process the
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 any-policy in the (1) For each policy P not equal to any-policy in the
certificate policies extension, let P-OID denote the OID in certificate policies extension, let P-OID denote the OID in
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) If the valid_policy_tree includes a node of depth i-1 (i) If the valid_policy_tree includes a node of depth i-1
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 OID-P; set the node as follows: set the valid_policy to OID-P; 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 {P-
OID}. 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
skipping to change at page 70, line 30 skipping to change at page 71, line 30
|-----------------| |-----------------|
| {} | | {} |
|-----------------| node of depth i |-----------------| node of depth i
| uninitialized | | uninitialized |
|-----------------| |-----------------|
| {Gold} | | {Gold} |
|-----------------| |-----------------|
Figure 4. Processing an exact match Figure 4. Processing an exact match
(ii) If there was no match in step (i) and the (ii) If there was no match in step (i) and the
valid_policy_tree includes a node of depth i-1 with the valid_policy_tree includes a node of depth i-1 with the
valid policy any-policy, generate a child node with the valid policy any-policy, generate a child node with the
following values: set the valid_policy to P-OID; set the following values: 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 {P-
OID}. 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 valid_policy is any-policy. Assume the depth i-1 where the valid_policy is any-policy. Assume the
certificate policies Gold and Silver appear in the certificate policies Gold and Silver appear in the
certificate policies extension of certificate i. The Gold certificate policies extension of certificate i. The Gold
skipping to change at page 71, line 31 skipping to change at page 72, line 31
| {} | | {Q-Silver} | | {} | | {Q-Silver} |
|-----------------| nodes of |-----------------| |-----------------| nodes of |-----------------|
| uninitialized | depth i | uninitialized | | uninitialized | depth i | uninitialized |
|-----------------| |-----------------| |-----------------| |-----------------|
| {Gold} | | {Silver} | | {Gold} | | {Silver} |
|-----------------| |-----------------| |-----------------| |-----------------|
Figure 5. Processing unmatched policies when a leaf node Figure 5. Processing unmatched policies when a leaf node
specifies any-policy specifies any-policy
(2) If the certificate policies extension includes the policy (2) If the certificate policies extension includes the policy
any-policy with the qualifier set AP-Q and inhibit_any-policy any-policy with the qualifier set AP-Q and inhibit_any-policy
is greater than 0, then: is greater than 0, then:
For each node in the valid_policy_tree of depth i-1, for each For each node in the valid_policy_tree of depth i-1, for each
value in the expected_policy_set (including any-policy) that value in the expected_policy_set (including any-policy) that
does not appear in a child node, create a child node with the does not appear in a child node, create a child node with the
following values: set the valid_policy to the value from the following values: set the valid_policy to the value from the
expected_policy_set in the parent node; set the qualifier_set expected_policy_set in the parent node; set the qualifier_set
to AP-Q, and set the expected_policy_set to the value in the to AP-Q, and set the expected_policy_set to the value in the
valid_policy from this node. valid_policy from this node.
skipping to change at page 72, line 31 skipping to change at page 73, line 31
| {} | | {} | | {} | | {} |
|-----------------| nodes of |-----------------| |-----------------| nodes of |-----------------|
| uninitialized | depth i | uninitialized | | uninitialized | depth i | uninitialized |
|-----------------| |-----------------| |-----------------| |-----------------|
| {Gold} | | {Silver} | | {Gold} | | {Silver} |
|-----------------| |-----------------| |-----------------| |-----------------|
Figure 6. Processing unmatched policies when the certificate Figure 6. Processing unmatched policies when the certificate
policies extension specifies any-policy policies extension specifies any-policy
(3) If there is a node in the valid_policy_tree of depth i-1 or (3) If there is a node in the valid_policy_tree of depth i-1
less without any child nodes, delete that node. Repeat this or less without any child nodes, delete that node. Repeat this
step until there are no nodes of depth i-1 or less without step until there are no nodes of depth i-1 or less without
children. children.
For example, consider the valid_policy_tree shown in Figure 7 For example, consider the valid_policy_tree shown in Figure 7
below. The two nodes at depth i-1 that are marked with an 'X' below. The two nodes at depth i-1 that are marked with an 'X'
have no children, and are deleted. Applying this rule to the have no children, and are deleted. Applying this rule to the
resulting tree will cause the node at depth i-2 that is marked resulting tree will cause the node at depth i-2 that is marked
with an 'Y' to be deleted. The following application of the with an 'Y' to be deleted. The following application of the
rule does not cause any nodes to be deleted, and this step is rule does not cause any nodes to be deleted, and this step is
complete. complete.
+-----------+ +-----------+
| | node of depth i-3 | | node of depth i-3
+-----------+ +-----------+
/ | \ / | \
/ | \ / | \
/ | \ / | \
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
| | | | | Y | nodes of | | | | | Y | nodes of
+-----------+ +-----------+ +-----------+ depth i-2 +-----------+ +-----------+ +-----------+ depth i-2
/ \ || || / \ | |
/ \ || || / \ | |
/ \ || || / \ | |
+-----------+ +-----------+ +-----------+ +-----------+ nodes of +-----------+ +-----------+ +-----------+ +-----------+ nodes of
| | | X | | | | X | depth | | | X | | | | X | depth
+-----------+ +-----------+ +-----------+ +-----------+ i-1 +-----------+ +-----------+ +-----------+ +-----------+ i-1
| / | \ | / | \
| / | \ | / | \
| / | \ | / | \
+-----------+ +-----------+ +-----------+ +-----------+ nodes of +-----------+ +-----------+ +-----------+ +-----------+ nodes of
| | | | | | | | depth | | | | | | | | depth
+-----------+ +-----------+ +-----------+ +-----------+ i +-----------+ +-----------+ +-----------+ +-----------+ i
Figure 7. Pruning the valid_policy_tree Figure 7. Pruning the valid_policy_tree
(4) If the certificate policies extension was marked as (4) If the certificate policies extension was marked as
critical, set the criticality_indicator in all nodes of depth i critical, set the criticality_indicator in all nodes of depth i
to TRUE. If the certificate policies extension was not marked to TRUE. If the certificate policies extension was not marked
critical, set the criticality_indicator in all nodes of depth i critical, set the criticality_indicator in all nodes of depth i
to FALSE. to FALSE.
(e) If the certificate policies extension is not present, set the (e) If the certificate policies extension is not present, set the
valid_policy_tree to NULL. valid_policy_tree to NULL.
(f) verify that either explicit_policy is greater than 0 or the (f) Verify that either explicit_policy is greater than 0 or the
valid_policy_tree is not equal to NULL; valid_policy_tree is not equal to NULL;
If any of steps (a), (b), (c), or (f) fails, the procedure If any of steps (a), (b), (c), or (f) fails, the procedure
terminates, returning a failure indication and an appropriate reason. terminates, returning a failure indication and an appropriate reason.
If i is not equal to n, continue by performing the preparatory steps If i is not equal to n, continue by performing the preparatory steps
listed in 6.1.4. If i is equal to n, perform the wrap-up steps listed in 6.1.4. If i is equal to n, perform the wrap-up steps
listed in 6.1.5. listed in 6.1.5.
6.1.4 Preparation for Certificate i+1 6.1.4 Preparation for Certificate i+1
To prepare for processing of certificate i+1, perform the following To prepare for processing of certificate i+1, perform the following
steps for certificate i: steps for certificate i:
(a) If a policy mapping extension is present, verify that the (a) If a policy mapping extension is present, verify that the
special value any-policy does not appear as an issuerDomainPolicy special value any-policy does not appear as an issuerDomainPolicy
or a subjectDomainPolicy. or a subjectDomainPolicy.
(b) If a policy mapping extension is present, then for each (b) If a policy mapping extension is present, then for each
issuerDomainPolicy ID-P in the policy mapping extension: issuerDomainPolicy ID-P in the policy mapping extension:
(1) If the policy_mapping variable is greater than 0, for each (1) If the policy_mapping variable is greater than 0, for each
node in the valid_policy_tree of depth i where ID-P is the node in the valid_policy_tree of depth i where ID-P is the
valid_policy, set expected_policy_set to the set of valid_policy, set expected_policy_set to the set of
subjectDomainPolicy values that are specified as equivalent to subjectDomainPolicy values that are specified as equivalent to
ID-P by the policy mapping extension. ID-P by the policy mapping extension.
If no node of depth i in the valid_policy_tree has a If no node of depth i in the valid_policy_tree has a
valid_policy of ID-P but there is a node of depth i with a valid_policy of ID-P but there is a node of depth i with a
valid_policy of any-policy, then generate a child node of the valid_policy of any-policy, then generate a child node of the
node of depth i-1 that has a valid_policy of any-policy as node of depth i-1 that has a valid_policy of any-policy as
follows: follows:
(i) set the valid_policy to ID-P; (i) set the valid_policy to ID-P;
(ii) set the qualifier_set to the qualifier set of the (ii) set the qualifier_set to the qualifier set of the
policy any-policy in the certificate policies extension of policy any-policy in the certificate policies extension of
certificate i; certificate i;
(iii) set the criticality_indicator to the criticality of (iii) set the criticality_indicator to the criticality of
the certificate policies extension of certificate i; the certificate policies extension of certificate i;
(iv) and set the expected_policy_set to the set of (iv) and set the expected_policy_set to the set of
subjectDomainPolicy values that are specified as equivalent subjectDomainPolicy values that are specified as equivalent
to ID-P by the policy mappings extension. to ID-P by the policy mappings extension.
(2) If the policy_mapping variable is equal to 0: (2) If the policy_mapping variable is equal to 0:
(i) delete each node of depth i in the valid_policy_tree (i) delete each node of depth i in the valid_policy_tree
where ID-P is the valid_policy. where ID-P is the valid_policy.
(ii) If there is a node in the valid_policy_tree of depth (ii) If there is a node in the valid_policy_tree of depth
i-1 or less without any child nodes, delete that node. i-1 or less without any child nodes, delete that node.
Repeat this step until there are no nodes of depth i-1 or Repeat this step until there are no nodes of depth i-1 or
less without children. less without children.
(c) Assign the certificate subject name to working_issuer_name. (c) Assign the certificate subject name to working_issuer_name.
(d) Assign the certificate subjectPublicKey to working_public_key. (d) Assign the certificate subjectPublicKey to
working_public_key.
(e) If the subjectPublicKeyInfo field of the certificate contains (e) If the subjectPublicKeyInfo field of the certificate contains
an algorithm field with non-null parameters, assign the parameters an algorithm field with non-null parameters, assign the parameters
to the working_public_key_parameters variable. to the working_public_key_parameters variable.
If the subjectPublicKeyInfo field of the certificate contains an If the subjectPublicKeyInfo field of the certificate contains an
algorithm field with null parameters or parameters are omitted, algorithm field with null parameters or parameters are omitted,
compare the certificate subjectPublicKey algorithm to the compare the certificate subjectPublicKey algorithm to the
working_public_key_algorithm. If the certificate subjectPublicKey working_public_key_algorithm. If the certificate subjectPublicKey
algorithm and the working_public_key_algorithm are different, set algorithm and the working_public_key_algorithm are different, set
the working_public_key_parameters to null. the working_public_key_parameters to null.
(f) Assign the certificate subjectPublicKey algorithm to the (f) Assign the certificate subjectPublicKey algorithm to the
working_public_key_algorithm variable. working_public_key_algorithm variable.
(g) If a name constraints extension is included in the (g) If a name constraints extension is included in the
certificate, modify the permitted_subtrees and excluded_subtrees certificate, modify the permitted_subtrees and excluded_subtrees
state variables as follows: state variables as follows:
(1) If permittedSubtrees is present in the certificate, set the (1) If permittedSubtrees is present in the certificate, set
permitted_subtrees state variable to the intersection of its the permitted_subtrees state variable to the intersection of
previous value and the value indicated in the extension field. its previous value and the value indicated in the extension
If permittedSubtrees does not include a particular name type, field. If permittedSubtrees does not include a particular name
the permitted_subtrees state variable is unchanged for that type, the permitted_subtrees state variable is unchanged for
name type. that name type. For example, the intersection of the name
spaces nist.gov and csrc.nist.gov is csrc.nist.gov. And, the
intersection of nist.gov and rsasecurity.com is the empty set.
(2) If excludedSubtrees is present in the certificate, set the (2) If excludedSubtrees is present in the certificate, set the
excluded_subtrees state variable to the union of its previous excluded_subtrees state variable to the union of its previous
value and the value indicated in the extension field. If value and the value indicated in the extension field. If
excludedSubtrees does not include a particular name type, the excludedSubtrees does not include a particular name type, the
excluded_subtrees state variable is unchanged for that name excluded_subtrees state variable is unchanged for that name
type. type. For example, the union of the name spaces nist.gov and
csrc.nist.gov is nist.gov. And, the union of nist.gov and
rsasecurity.com is both name spaces.
(h) If the issuer and subject names are not identical: (h) If the issuer and subject names are not identical:
(1) If explicit_policy is not 0, decrement explicit_policy by (1) If explicit_policy is not 0, decrement explicit_policy by
1. 1.
(2) If policy_mapping is not 0, decrement policy_mapping by 1. (2) If policy_mapping is not 0, decrement policy_mapping by 1.
(3) If inhibit_any-policy is not 0, decrement inhibit_any- (3) If inhibit_any-policy is not 0, decrement inhibit_any-
policy by 1. policy by 1.
(i) If a policy constraints extension is included in the (i) If a policy constraints extension is included in the
certificate, modify the explicit_policy and policy_mapping state certificate, modify the explicit_policy and policy_mapping state
variables as follows: variables as follows:
(1) If requireExplicitPolicy is present and is less than (1) If requireExplicitPolicy is present and is less than
explicit_policy, set explicit_policy to the value of explicit_policy, set explicit_policy to the value of
requireExplicitPolicy. requireExplicitPolicy.
(2) If inhibitPolicyMapping is present and is less than (2) If inhibitPolicyMapping is present and is less than
policy_mapping, set policy_mapping to the value of policy_mapping, set policy_mapping to the value of
inhibitPolicyMapping. inhibitPolicyMapping.
(j) If the inhibitAnyPolicy extension is included in the (j) If the inhibitAnyPolicy extension is included in the
certificate and is less than inhibit_any-policy, set inhibit_any- certificate and is less than inhibit_any-policy, set inhibit_any-
policy to the value of inhibitAnyPolicy. policy to the value of inhibitAnyPolicy.
(k) Verify that the certificate is a CA certificate (as specified (k) Verify that the certificate is a CA certificate (as specified
in a basicConstraints extension or as verified out-of-band). in a basicConstraints extension or as verified out-of-band).
(l) If the certificate was not self-issued, verify that (l) If the certificate was not self-issued, verify that
max_path_length is greater than zero and decrement max_path_length max_path_length is greater than zero and decrement max_path_length
by 1. by 1.
(m) If pathLengthConstraint is present in the certificate and is (m) If pathLengthConstraint is present in the certificate and is
less than max_path_length, set max_path_length to the value of less than max_path_length, set max_path_length to the value of
pathLengthConstraint. pathLengthConstraint.
(n) If a key usage extension is present and marked critical, (n) If a key usage extension is present, verify that the
verify that the keyCertSign bit is set. keyCertSign bit is set.
(o) Recognize and process any other critical extension present in (o) Recognize and process any other critical extension present in
the certificate. the certificate. Process any other recognized non-critical
extension present in the certificate.
If check (a), (k), (l), (n) or (o) fails, the procedure terminates, If check (a), (k), (l), (n) or (o) fails, the procedure terminates,
returning a failure indication and an appropriate reason. returning a failure indication and an appropriate reason.
If (a), (k), (l), (n) and (o) have completed successfully, increment If (a), (k), (l), (n) and (o) have completed successfully, increment
i and perform the basic certificate processing specified in 6.1.2. i and perform the basic certificate processing specified in 6.1.2.
6.1.5 Wrap-up procedure 6.1.5 Wrap-up procedure
To complete the processing of the end entity certificate, perform the To complete the processing of the end entity certificate, perform the
following steps for certificate n: following steps for certificate n:
(a) If certificate n was not self-issued and explicit_policy is (a) If certificate n was not self-issued and explicit_policy is
not 0, decrement explicit_policy by 1. not 0, decrement explicit_policy by 1.
(b) If a policy constraints extension is included in the (b) If a policy constraints extension is included in the
certificate and requireExplicitPolicy is present and has a value certificate and requireExplicitPolicy is present and has a value
of 0, set the explicit_policy state variable to 0. of 0, set the explicit_policy state variable to 0.
(c) Assign the certificate subjectPublicKey to working_public_key. (c) Assign the certificate subjectPublicKey to
working_public_key.
(d) If the subjectPublicKeyInfo field of the certificate contains (d) If the subjectPublicKeyInfo field of the certificate contains
an algorithm field with non-null parameters, assign the parameters an algorithm field with non-null parameters, assign the parameters
to the working_public_key_parameters variable. to the working_public_key_parameters variable.
If the subjectPublicKeyInfo field of the certificate contains an If the subjectPublicKeyInfo field of the certificate contains an
algorithm field with null parameters or parameters are omitted, algorithm field with null parameters or parameters are omitted,
compare the certificate subjectPublicKey algorithm to the compare the certificate subjectPublicKey algorithm to the
working_public_key_algorithm. If the certificate subjectPublicKey working_public_key_algorithm. If the certificate subjectPublicKey
algorithm and the working_public_key_algorithm are different, set algorithm and the working_public_key_algorithm are different, set
the working_public_key_parameters to null. the working_public_key_parameters to null.
(e) Assign the certificate subjectPublicKey algorithm to the (e) Assign the certificate subjectPublicKey algorithm to the
working_public_key_algorithm variable. working_public_key_algorithm variable.
(f) Recognize and process any other critical extension present in (f) Recognize and process any other critical extension present in
the certificate n. the certificate n. Process any other recognized non-critical
extension present in certificate n.
(g) Calculate the intersection of the valid_policy_tree and the (g) Calculate the intersection of the valid_policy_tree and the
user-initial-policy-set, as follows: user-initial-policy-set, as follows:
(i) If the valid_policy_tree is NULL, the intersection is NULL. (i) If the valid_policy_tree is NULL, the intersection is
NULL.
(ii) If the valid_policy_tree is not NULL and the user-initial- (ii) If the valid_policy_tree is not NULL and the user-
policy-set is any-policy, the intersection is the entire initial-policy-set is any-policy, the intersection is the
valid_policy_tree. entire valid_policy_tree.
(iii) If the valid_policy_tree is not NULL and the user- (iii) If the valid_policy_tree is not NULL and the user-
initial-policy-set is not any-policy, calculate the initial-policy-set is not any-policy, calculate the
intersection of the valid_policy_tree and the user-initial- intersection of the valid_policy_tree and the user-initial-
policy-set as follows: policy-set as follows:
1. Determine the set of policy nodes whose parent nodes have 1. Determine the set of policy nodes whose ancestor nodes
a valid_policy of any-policy. This is the have a valid_policy of any-policy. This is the
valid_policy_node_set. valid_policy_node_set.
2. If the valid_policy of any node in the 2. If the valid_policy of any node in the
valid_policy_node_set is not in the user-initial-policy-set valid_policy_node_set is not in the user-initial-policy-set
and is not any-policy, delete this node and all its and is not any-policy, delete this node and all its
children. children.
3. If there is a node in the valid_policy_tree of depth n-1 3. If there is a node in the valid_policy_tree of depth n-1
or less without any child nodes, delete that node. Repeat or less without any child nodes, delete that node. Repeat
this step until there are no nodes of depth n-1 or less this step until there are no nodes of depth n-1 or less
without children. without children.
If either (1) the value of explicit_policy variable is greater than If either (1) the value of explicit_policy variable is greater than
zero, or (2) the valid_policy_tree is not NULL, then path processing zero, or (2) the valid_policy_tree is not NULL, then path processing
has succeeded. has succeeded.
6.1.6 Outputs 6.1.6 Outputs
If path processing succeeds, the procedure terminates, returning a If path processing succeeds, the procedure terminates, returning a
success indication together with final value of the success indication together with final value of the
valid_policy_tree, the working_public_key, the valid_policy_tree, the working_public_key, the
working_public_key_algorithm, and the working_public_key_parameters. working_public_key_algorithm, and the working_public_key_parameters.
6.2 Using the Path Validation Algorithm 6.2 Using the Path Validation Algorithm
The path validation algorithm describes the process of validating a The path validation algorithm describes the process of validating a
single certification path. While each certification path begins with single certification path. While each certification path begins with
a specific trust anchor, there is no requirement that all a specific trust anchor, there is no requirement that all
certification paths validated by a particular system share a single certification paths validated by a particular system share a single
trust anchor. An implementation that supports multiple trust anchors trust anchor. An implementation that supports multiple trust anchors
MAY augment the algorithm presented in section 6.1 to further limit MAY augment the algorithm presented in section 6.1 to further limit
the set of valid certification paths which begin with a particular the set of valid certification paths which begin with a particular
trust anchor. For example, an implementation MAY modify the trust anchor. For example, an implementation MAY modify the
algorithm to apply name constraints to a specific trust anchor during algorithm to apply name constraints to a specific trust anchor during
skipping to change at page 78, line 39 skipping to change at page 79, line 49
reflect application-specific requirements or limitations in the trust reflect application-specific requirements or limitations in the trust
accorded a particular trust anchor. For example, a trusted CA may accorded a particular trust anchor. For example, a trusted CA may
only be trusted for a particular certificate policy. This only be trusted for a particular certificate policy. This
restriction can be expressed through the inputs to the path restriction can be expressed through the inputs to the path
validation procedure. validation procedure.
It is also possible to specify an extended version of the above It is also possible to specify an extended version of the above
certification path processing procedure which results in default certification path processing procedure which results in default
behavior identical to the rules of PEM [RFC 1422]. In this extended behavior identical to the rules of PEM [RFC 1422]. In this extended
version, additional inputs to the procedure are a list of one or more version, additional inputs to the procedure are a list of one or more
Policy Certification Authorities (PCAs) names and an indicator of the Policy Certification Authority (PCA) names and an indicator of the
position in the certification path where the PCA is expected. At the position in the certification path where the PCA is expected. At the
nominated PCA position, the CA name is compared against this list. nominated PCA position, the CA name is compared against this list.
If a recognized PCA name is found, then a constraint of If a recognized PCA name is found, then a constraint of
SubordinateToCA is implicitly assumed for the remainder of the SubordinateToCA is implicitly assumed for the remainder of the
certification path and processing continues. If no valid PCA name is certification path and processing continues. If no valid PCA name is
found, and if the certification path cannot be validated on the basis found, and if the certification path cannot be validated on the basis
of identified policies, then the certification path is considered of identified policies, then the certification path is considered
invalid. invalid.
6.3 CRL Validation 6.3 CRL Validation
This section describes the steps necessary to determine if a This section describes the steps necessary to determine if a
skipping to change at page 79, line 28 skipping to change at page 80, line 35
in the local CRL cache. in the local CRL cache.
This algorithm defines a set of inputs, a set of state variables, and This algorithm defines a set of inputs, a set of state variables, and
processing steps that are performed for each certificate in the path. processing steps that are performed for each certificate in the path.
The algorithm output is the revocation status of the certificate. The algorithm output is the revocation status of the certificate.
6.3.1 Revocation Inputs 6.3.1 Revocation Inputs
To support revocation processing, the algorithm requires two inputs: To support revocation processing, the algorithm requires two inputs:
(a) certificate: The algorithm requires the certificate serial (a) certificate: The algorithm requires the certificate serial
number and issuer name to determine whether a certificate is on a number and issuer name to determine whether a certificate is on a
particular CRL. The basicConstraints extension is used to particular CRL. The basicConstraints extension is used to
determine whether the supplied certificate is associated with a CA determine whether the supplied certificate is associated with a CA
or an end entity. If present, the algorithm uses the or an end entity. If present, the algorithm uses the
cRLDistributionsPoint and freshestCRL extensions to determine cRLDistributionsPoint and freshestCRL extensions to determine
revocation status. revocation status.
(b) use-deltas: This boolean input determines whether delta CRLs (b) use-deltas: This boolean input determines whether delta CRLs
are applied to CRLs. are applied to CRLs.
Note that implementations supporting legacy PKIs, such as RFC 1422 Note that implementations supporting legacy PKIs, such as RFC 1422
and X.509 version 1, will need an additional input indicating and X.509 version 1, will need an additional input indicating
whether the supplied certificate is associated with a CA or an end whether the supplied certificate is associated with a CA or an end
entity. entity.
6.3.2 Initialization and Revocation State Variables 6.3.2 Initialization and Revocation State Variables
To support CRL processing, the algorithm requires the following state To support CRL processing, the algorithm requires the following state
variables: variables:
(a) reasons_mask: This variable contains the set of revocation (a) reasons_mask: This variable contains the set of revocation
reasons supported by the CRLs and delta CRLs processed so far. reasons supported by the CRLs and delta CRLs processed so far.
The legal members of the set are the possible revocation reason The legal members of the set are the possible revocation reason
values: unspecified, keyCompromise, caCompromise, values: unspecified, keyCompromise, caCompromise,
affiliationChanged, superseded, cessationOfOperation, affiliationChanged, superseded, cessationOfOperation,
certificateHold, privilegeWithdrawn, and aACompromise. The certificateHold, privilegeWithdrawn, and aACompromise. The
special value all-reasons is used to denote the set of all legal special value all-reasons is used to denote the set of all legal
members. This variable is initialized to the empty set. members. This variable is initialized to the empty set.
(b) cert_status: This variable contains the status of the (b) cert_status: This variable contains the status of the
certificate. This variable may be assigned one of the following certificate. This variable may be assigned one of the following
values: unspecified, keyCompromise, caCompromise, values: unspecified, keyCompromise, caCompromise,
affiliationChanged, superseded, cessationOfOperation, affiliationChanged, superseded, cessationOfOperation,
certificateHold, removeFromCRL, privilegeWithdrawn, aACompromise, certificateHold, removeFromCRL, privilegeWithdrawn, aACompromise,
the special value UNREVOKED, or the special value UNDETERMINED. the special value UNREVOKED, or the special value UNDETERMINED.
This variable is initialized to the special value UNREVOKED. This variable is initialized to the special value UNREVOKED.
(c) interim_reasons_mask: This contains the set of revocation (c) interim_reasons_mask: This contains the set of revocation
reasons supported by the CRL or delta CRL currently being reasons supported by the CRL or delta CRL currently being
processed. processed.
Note: In some environments, it is not necessary to check all reason Note: In some environments, it is not necessary to check all reason
codes. For example, some environments are only concerned with codes. For example, some environments are only concerned with
caCompromise and keyCompromise for CA certificates. This algorithm caCompromise and keyCompromise for CA certificates. This algorithm
checks all reason codes. Additional processing and state variables checks all reason codes. Additional processing and state variables
may be necessary to limit the checking to a subset of the reason may be necessary to limit the checking to a subset of the reason
codes. codes.
skipping to change at page 81, line 29 skipping to change at page 82, line 38
(1) If the DP includes cRLIssuer, then verify that the issuer (1) If the DP includes cRLIssuer, then verify that the issuer
field in the complete CRL matches cRLIssuer in the DP and that field in the complete CRL matches cRLIssuer in the DP and that
the complete CRL contains an issuing distribution point the complete CRL contains an issuing distribution point
extension with the indrectCRL boolean asserted. Otherwise, extension with the indrectCRL boolean asserted. Otherwise,
verify that the CRL issuer matches the certificate issuer. verify that the CRL issuer matches the certificate issuer.
(2) If the complete CRL includes an issuing distribution point (2) If the complete CRL includes an issuing distribution point
(IDP) CRL extension check the following: (IDP) CRL extension check the following:
(i) If the distribution point name is present in the IDP (i) If the distribution point name is present in the IDP
CRL extension, then verify that it matches one of the names CRL extension and the distribution field is present in the
in the DP. DP, then verify that one of the names in the IDP matches one
of the names in the DP. If the distribution point name is
present in the IDP CRL extension and the distribution field
is omitted from the DP, then verify that one of the names in
the IDP matches one of the names in the cRLIssuer field of
the DP.
(ii) If the onlyContainsUserCerts boolean is asserted in (ii) If the onlyContainsUserCerts boolean is asserted in
the IDP CRL extension, verify that the certificate does not the IDP CRL extension, verify that the certificate does not
include the basic constraints extension with the cA boolean include the basic constraints extension with the cA boolean
asserted. asserted.
(iii) If the onlyContainsCACerts boolean is asserted in the (iii) If the onlyContainsCACerts boolean is asserted in the
IDP CRL extension, verify that the certificate includes the IDP CRL extension, verify that the certificate includes the
basic constraints extension with the cA boolean asserted. basic constraints extension with the cA boolean asserted.
skipping to change at page 82, line 23 skipping to change at page 83, line 36
(1) If the issuing distribution point (IDP) CRL extension is (1) If the issuing distribution point (IDP) CRL extension is
present and includes onlySomeReasons and the DP includes present and includes onlySomeReasons and the DP includes
reasons, then set interim_reasons_mask to the intersection of reasons, then set interim_reasons_mask to the intersection of
reasons in the DP and onlySomeReasons in IDP CRL extension. reasons in the DP and onlySomeReasons in IDP CRL extension.
(2) If the IDP CRL extension includes onlySomeReasons but the (2) If the IDP CRL extension includes onlySomeReasons but the
DP omits reasons, then set interim_reasons_mask to the value of DP omits reasons, then set interim_reasons_mask to the value of
onlySomeReasons in IDP CRL extension. onlySomeReasons in IDP CRL extension.
(3) If the IDP CRL extension omits onlySomeReasons but the DP (3) If the IDP CRL extension is not present or omits
includes reasons, then set interim_reasons_mask to the value of onlySomeReasons but the DP includes reasons, then set
DP reasons. interim_reasons_mask to the value of DP reasons.
(4) If the IDP CRL extension omits onlySomeReasons and the DP (4) If the IDP CRL extension is not present or omits
omits reasons, then set interim_reasons_mask to the special onlySomeReasons and the DP omits reasons, then set
value all-reasons. interim_reasons_mask to the special value all-reasons.
(e) Verify that interim_reasons_mask includes one or more reasons (e) Verify that interim_reasons_mask includes one or more reasons
that is not included in the reasons_mask. that is not included in the reasons_mask.
(f) Obtain and validate the certification path for the complete (f) Obtain and validate the certification path for the complete
CRL issuer. CRL issuer.
(g) Validate the signature on the complete CRL using the public (g) Validate the signature on the complete CRL using the public
key validated in step (f). key validated in step (f).
skipping to change at page 83, line 23 skipping to change at page 84, line 36
(k) If (cert_status is removeFromCRL), then set cert_status to (k) If (cert_status is removeFromCRL), then set cert_status to
UNREVOKED. UNREVOKED.
If ((reasons_mask is all-reasons) OR (cert_status is not UNREVOKED)), If ((reasons_mask is all-reasons) OR (cert_status is not UNREVOKED)),
then the revocation status has been determined, so return then the revocation status has been determined, so return
cert_status. cert_status.
If the revocation status has not been determined, repeat the process If the revocation status has not been determined, repeat the process
above with any available CRLs not specified in a distribution point above with any available CRLs not specified in a distribution point
but issued by the certificate issuer. If the revocation status but issued by the certificate issuer. For the processing of such a
remains undetermined, then return the cert_status UNDETERMINED. CRL, assume a DP with both the reasons and the cRLIssuer fields
omitted and a distribution point name of the certificate issuer.
That is, the sequence of names in fullName is generated from the
certificate issuer field as well as the certificate issuerAltName
extension. If the revocation status remains undetermined, then
return the cert_status UNDETERMINED.
7 References 7 References
[RFC 791] J. Postel, "Internet Protocol", September 1981. [ISO 10646] ISO/IEC 10646-1:1993. International Standard --
Information technology -- Universal Multiple-Octet Coded
Character Set (UCS) -- Part 1: Architecture and Basic
Multilingual Plane.
[RFC 822] D. Crocker, "Standard for the format of ARPA Internet text [RFC 791] Postel, J., "Internet Protocol", RFC 791,
messages", August 1982. September 1981.
[RFC 1034] P.V. Mockapetris, "Domain names - concepts and [RFC 822] Crocker, D., "Standard for the format of ARPA Internet
facilities", November 1987. text messages", RFC 822, August 1982.
[RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic [RFC 1034] Mockapetris, P.V., "Domain names - concepts and
Mail: Part II: Certificate-Based Key Management," RFC facilities", RFC 1034, November 1987.
1422, BBN Communications, February 1993.
[RFC 1423] Balenson, D., "Privacy Enhancement for Internet Electronic [RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic
Mail: Part III: Algorithms, Modes, and Identifiers," Mail: Part II: Certificate-Based Key Management,"
RFC 1423, Trusted Information Systems, February 1993. RFC 1422, February 1993.
[RFC 1510] Kohl, J., and C. Neuman, "The Kerberos Network [RFC 1423] Balenson, D., "Privacy Enhancement for Internet
Authentication Service (V5)," RFC 1510, September 1993. Electronic Mail: Part III: Algorithms, Modes, and
Identifiers," RFC 1423, February 1993.
[RFC 1519] V. Fuller, T. Li, J. Yu, and K. Varadhan. "Classless [RFC 1510] Kohl, J., and C. Neuman, "The Kerberos Network
Inter-Domain Routing (CIDR): an Address Assignment and Authentication Service (V5)," RFC 1510, September 1993.
Aggregation Strategy", September 1993.
[RFC 1738] Berners-Lee, T., Masinter L., and M. McCahill. [RFC 1519] Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless
"Uniform Resource Locators (URL)", RFC 1738, December 1994. Inter-Domain Routing (CIDR): An Address Assignment and
Aggregation Strategy", RFC 1519, September 1993.
[RFC 1778] Howes, T., Kille S., Yeong, W. and C. Robbins. "The [RFC 1738] Berners-Lee, T., L. Masinter, and M. McCahill,
String Representation of Standard Attribute Syntaxes," "Uniform Resource Locators (URL)", RFC 1738,
RFC 1778, March 1995. December 1994.
[RFC 1883] S. Deering and R. Hinden. "Internet Protocol, Version 6 [RFC 1778] Howes, T., S. Kille, W. Yeong, and C. Robbins, "The
(IPv6) Specification", December 1995. String Representation of Standard Attribute Syntaxes,"
RFC 1778, March 1995.
[RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC 1883] Deering, S., and R. Hinden. "Internet Protocol,
Requirement Levels", March 1997. Version 6 (IPv6) Specification", RFC 1883, December
1995.
[RFC 2247] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. [RFC 2044] F. Yergeau, F., "UTF-8, a transformation format of
Sataluri. "Using Domains in LDAP/X.500 Distinguished Names", Unicode and ISO 10646", RFC 2044, October 1996.
RFC 2247, January 1998.
[RFC 2277] H. Alvestrand, "IETF Policy on Character Sets and [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Languages", January 1998. Requirement Levels", March 1997.
[RFC 2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646", [RFC 2247] Kille, S., M. Wahl, A. Grimstad, R. Huber, and
January 1998. S. Sataluri, "Using Domains in LDAP/X.500
Distinguished Names", RFC 2247, January 1998.
[RFC 2560] Myers, M., Ankney R., Malpani A., Galperin S., and [RFC 2252] Wahl, M., A. Coulbeck, T. Howes, and S. Kille,
C. Adams, "Online Certificate Status Protocal - OCSP", "Lightweight Directory Access Protocol (v3):
June 1999. Attribute Syntax Definitions", RFC 2252,
December 1997.
[SDN.701] SDN.701, "Message Security Protocol 4.0", Revision A [RFC 2277] Alvestrand, H., "IETF Policy on Character Sets and
1997-02-06. Languages", January 1998.
[X.208] CCITT Recommendation X.208: Specification of Abstract [RFC 2279] Yergeau, F., "UTF-8, a transformation format of
Syntax Notation One (ASN.1), 1988. ISO 10646", RFC 2279, January 1998.
[X.501] ITU-T Recommendation X.501: Information [RFC 2459] Housley, R., W. Ford, W. Polk, and D. Solo, "Internet
Technology - Open Systems Interconnection - The X.509 Public Key Infrastructure: Certificate and CRL
Directory: Models, 1993. Profile", RFC 2459, January 1999.
[X.509] ITU-T Recommendation X.509 (1997 E): Information [RFC 2560] Myers, M., R. Ankney, A. Malpani, S. Galperin, and
Technology - Open Systems Interconnection - The C. Adams, "Online Certificate Status Protocal - OCSP",
Directory: Authentication Framework, June 1997. June 1999.
[X.520] ITU-T Recommendation X.520: Information [SDN.701] SDN.701, "Message Security Protocol 4.0", Revision A,
Technology - Open Systems Interconnection - The 1997-02-06.
Directory: Selected Attribute Types, 1993.
[X9.55] ANSI X9.55-1995, Public Key Cryptography For The Financial [X.208] CCITT Recommendation X.208: Specification of Abstract
Services Industry: Extensions To Public Key Certificates Syntax Notation One (ASN.1), 1988.
And Certificate Revocation Lists, 8 December, 1995.
[PKINIT] Tung, B., Neuman C., Hur M., Medvinsky A., Medvinsky S., [X.501] ITU-T Recommendation X.501: Information
Wray J., and J. Trostle, "Public Key Cryptography for Technology - Open Systems Interconnection - The
Initial Authentciaion in Kerberos," Directory: Models, 1993.
draft-ietf-cat-kerberos-pk-init-11.txt, March 15, 2000.
[PKIXALGS] Bassham, L., Housley, R., and W. Polk, "Internet X.509 [X.509] ITU-T Recommendation X.509 (1997 E): Information
Public Key Infrastructure Representation of Public Keys Technology - Open Systems Interconnection - The
and Digital Signatures," Directory: Authentication Framework, June 1997.
draft-ietf-pkix-ipki-pkalgs-00.txt, July 14, 2000.
[PKIXTSA] Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 [X.520] ITU-T Recommendation X.520: Information
Public Key Infrastructure Time Stamp Protocol," Technology - Open Systems Interconnection - The
draft-ietf-pkix-time-stamp-12.txt, November, 2000. Directory: Selected Attribute Types, 1993.
[X.660] ITU-T Recommendation X.660: [*** Get Info ***]
[X9.55] ANSI X9.55-1995, Public Key Cryptography For The
Financial Services Industry: Extensions To Public
Key Certificates And Certificate Revocation Lists,
8 December, 1995.
[PKINIT] Tung, B., C. Neuman, M. Hur, A. Medvinsky,
S. Medvinsky, J. Wray, and J. Trostle, "Public Key
Cryptography for Initial Authentciaion in Kerberos,"
draft-ietf-cat-kerberos-pk-init-13.txt, March 2001.
[PKIXALGS] Bassham, L., R. Housley, and W. Polk, "Internet X.509
Public Key Infrastructure Representation of Public Keys
and Digital Signatures,"
draft-ietf-pkix-ipki-pkalgs-02.txt, March 2001.
[PKIXTSA] Cain, P., D. Pinkas, and R. Zuccherato, "Internet
X.509 Public Key Infrastructure Time Stamp Protocol,"
draft-ietf-pkix-time-stamp-13.txt, January 2001.
8 Intellectual Property Rights 8 Intellectual Property Rights
The IETF has been notified of intellectual property rights claimed in The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this regard to some or all of the specification contained in this
document. For more information consult the online list of claimed document. For more information consult the online list of claimed
rights (see http://www.ietf.org/ipr.html). rights (see http://www.ietf.org/ipr.html).
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
skipping to change at page 86, line 4 skipping to change at page 87, line 47
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.
However, security factors outside the scope of this specification However, security factors outside the scope of this specification
will affect the assurance provided to certificate users. This will affect the assurance provided to certificate users. This
section highlights critical issues to be considered by implementers, section highlights critical issues to be considered by implementers,
administrators, and users. administrators, and users.
The procedures performed by CAs and RAs to validate the binding of The procedures performed by CAs and RAs to validate the binding of
the subject's identity of their public key greatly affect the the subject's identity to their public key greatly affect the
assurance that ought to be placed in the certificate. Relying assurance that ought to be placed in the certificate. Relying
parties might wish to review the CA's certificate practice statement. parties might wish to review the CA's certificate practice statement.
This is particularly important when issuing certificates to other This is particularly important when issuing certificates to other
CAs. CAs.
The use of a single key pair for both signature and other purposes is The use of a single key pair for both signature and other purposes is
strongly discouraged. Use of separate key pairs for signature and strongly discouraged. Use of separate key pairs for signature and
key management provides several benefits to the users. The key management provides several benefits to the users. The
ramifications associated with loss or disclosure of a signature key ramifications associated with loss or disclosure of a signature key
are different from loss or disclosure of a key management key. Using are different from loss or disclosure of a key management key. Using
skipping to change at page 87, line 21 skipping to change at page 89, line 15
will be available to all relying parties. Similarly, implementations will be available to all relying parties. Similarly, implementations
of the certification path validation mechanism described in section 6 of the certification path validation mechanism described in section 6
that omit revocation checking provide less assurance than those that that omit revocation checking provide less assurance than those that
support it. support it.
The path validation algorithm depends on the certain knowledge of the The path validation algorithm depends on the certain knowledge of the
public keys (and other information) about one or more trusted CAs. public keys (and other information) about one or more trusted CAs.
The decision to trust a CA is an important decision as it ultimately The decision to trust a CA is an important decision as it ultimately
determines the trust afforded a certificate. The authenticated determines the trust afforded a certificate. The authenticated
distribution of trusted CA public keys (usually in the form of a distribution of trusted CA public keys (usually in the form of a
"self-signed" certificate) is a security critical out of band process "self-signed" certificate) is a security critical out-of-band process
that is beyond the scope of this specification. that is beyond the scope of this specification.
In addition, where a key compromise or CA failure occurs for a In addition, where a key compromise or CA failure occurs for a
trusted CA, the user will need to modify the information provided to trusted CA, the user will need to modify the information provided to
the path validation routine. Selection of too many trusted CAs makes the path validation routine. Selection of too many trusted CAs makes
the trusted CA information difficult to maintain. On the other hand, the trusted CA information difficult to maintain. On the other hand,
selection of only one trusted CA could limit users to a closed selection of only one trusted CA could limit users to a closed
community of users. community of users.
The quality of implementations that process certificates also affects The quality of implementations that process certificates also affects
skipping to change at page 88, line 10 skipping to change at page 90, line 4
acceptance of invalid X.509 certification paths, or rejection of acceptance of invalid X.509 certification paths, or rejection of
valid ones. The X.500 series of specifications defines rules for valid ones. The X.500 series of specifications defines rules for
comparing distinguished names that require comparison of strings comparing distinguished names that require comparison of strings
without regard to case, character set, multi-character white space without regard to case, character set, multi-character white space
substring, or leading and trailing white space. This specification substring, or leading and trailing white space. This specification
relaxes these requirements, requiring support for binary comparison relaxes these requirements, requiring support for binary comparison
at a minimum. at a minimum.
CAs MUST encode the distinguished name in the subject field of a CA CAs MUST encode the distinguished name in the subject field of a CA
certificate identically to the distinguished name in the issuer field certificate identically to the distinguished name in the issuer field
in certificates issued by the latter CA. If CAs use different in certificates issued by that CA. If CAs use different encodings,
encodings, implementations might fail to recognize name chains for implementations might fail to recognize name chains for paths that
paths that include this certificate. As a consequence, valid paths include this certificate. As a consequence, valid paths could be
could be rejected. rejected.
In addition, name constraints for distinguished names MUST be stated In addition, name constraints for distinguished names MUST be stated
identically to the encoding used in the subject field or identically to the encoding used in the subject field or
subjectAltName extension. If not, then name constraints stated as subjectAltName extension. If not, then name constraints stated as
excludedSubTrees will not match and invalid paths will be accepted excludedSubTrees will not match and invalid paths will be accepted
and name constraints expressed as permittedSubtrees will not match and name constraints expressed as permittedSubtrees will not match
and valid paths will be rejected. To avoid acceptance of invalid and valid paths will be rejected. To avoid acceptance of invalid
paths, CAs SHOULD state name constraints for distinguished names as paths, CAs SHOULD state name constraints for distinguished names as
permittedSubtrees wherever possible. permittedSubtrees wherever possible.
skipping to change at page 109, line 13 skipping to change at page 111, line 13
END END
Appendix B. ASN.1 Notes Appendix B. ASN.1 Notes
CAs MUST force the serialNumber to be a non-negative integer, that CAs MUST force the serialNumber to be a non-negative integer, that
is, the sign bit in the DER encoding of the INTEGER value MUST be is, the sign bit in the DER encoding of the INTEGER value MUST be
zero - this can be done by adding a leading (leftmost) `00'H octet if zero - this can be done by adding a leading (leftmost) `00'H octet if
necessary. This removes a potential ambiguity in mapping between a necessary. This removes a potential ambiguity in mapping between a
string of octets and an integer value. string of octets and an integer value.
As noted in section 4.1.2.2, serial numbers can be expected to As noted in section 4.1.2.2, serial numbers can be expected to
contain long integers. Certificate users MUST be able to handle contain long integers. Certificate users MUST be able to handle
serialNumber values up to 20 octets in length. Conformant CAs MUST serialNumber values up to 20 octets in length. Conformant CAs MUST
NOT use serialNumber values longer than 20 octets. NOT use serialNumber values longer than 20 octets.
The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1
constructs. A valid ASN.1 sequence will have zero or more entries. constructs. A valid ASN.1 sequence will have zero or more entries.
The SIZE (1..MAX) construct constrains the sequence to have at least The SIZE (1..MAX) construct constrains the sequence to have at least
one entry. MAX indicates the upper bound is unspecified. one entry. MAX indicates the upper bound is unspecified.
Implementations are free to choose an upper bound that suits their Implementations are free to choose an upper bound that suits their
environment. environment.
The construct "positiveInt ::= INTEGER (0..MAX)" defines positiveInt The construct "positiveInt ::= INTEGER (0..MAX)" defines positiveInt
as a subtype of INTEGER containing integers greater than or equal to as a subtype of INTEGER containing integers greater than or equal to
zero. The upper bound is unspecified. Implementations are free to zero. The upper bound is unspecified. Implementations are free to
select an upper bound that suits their environment. select an upper bound that suits their environment.
The character string type PrintableString supports a very basic Latin The character string type PrintableString supports a very basic Latin
character set: the lower case letters 'a' through 'z', upper case character set: the lower case letters 'a' through 'z', upper case
letters 'A' through 'Z', the digits '0' through '9', eleven special letters 'A' through 'Z', the digits '0' through '9', eleven special
characters ' = ( ) + , - . / : ? and space. characters ' = ( ) + , - . / : ? and space.
Implementers should note that the at sign ('@') and underscore ('_')
characters are not supported by the ASN.1 type PrintableString.
These characters often appear in internet addresses. Such addresses
MUST be encoded using an ASN.1 type that supports them. They are
usually encoded as IA5String in either the emailAddress attribute
within a distinguished name or the rfc822Name field of GeneralName.
Conforming implementations MUST NOT encode strings which include
either the at sign or underscore character as PrintableString.
The character string type TeletexString is a superset of The character string type TeletexString is a superset of
PrintableString. TeletexString supports a fairly standard (ascii- PrintableString. TeletexString supports a fairly standard (ASCII-
like) Latin character set, Latin characters with non-spacing accents like) Latin character set, Latin characters with non-spacing accents
and Japanese characters. and Japanese characters.
Named bit lists are BIT STRINGs where the values have been assigned
names. This specification makes use of named bit lists in the
definitions for the key usage extension and CRL reasons field in the
CRL distribution points and freshest CRL certificate extensions, and
the issuing distribution point CRL extension. When DER encoding a
named bit list, trailing zeroes MUST be omitted. That is, the
encoded value ends with the last named bit that is set to one.
The character string type UniversalString supports any of the The character string type UniversalString supports any of the
characters allowed by ISO 10646-1. ISO 10646 is the Universal characters allowed by ISO 10646-1 [ISO 10646]. ISO 10646-1 is the
multiple-octet coded Character Set (UCS). ISO 10646-1 specifies the Universal multiple-octet coded Character Set (UCS). ISO 10646-1
architecture and the "basic multilingual plane" - a large standard specifies the architecture and the "basic multilingual plane" - a
character set which includes all major world character standards. large standard character set which includes all major world character
standards.
The character string type UTF8String was introduced in the 1997 The character string type UTF8String was introduced in the 1997
version of ASN.1, and UTF8String was added to the list of choices for version of ASN.1, and UTF8String was added to the list of choices for
DirectoryString in the 2001 version of X.520. UTF8String is a DirectoryString in the 2001 version of X.520 [X.520]. UTF8String is
universal type and has been assigned tag number 12. The content of a universal type and has been assigned tag number 12. The content of
UTF8String was defined by RFC 2044 and updated in RFC 2279, "UTF-8, a UTF8String was defined by RFC 2044 [RFC 2044] and updated in RFC 2279
transformation format of ISO 10646." [RFC 2279].
In anticipation of these changes, and in conformance with IETF Best In anticipation of these changes, and in conformance with IETF Best
Practices codified in RFC 2277, IETF Policy on Character Sets and Practices codified in RFC 2277 [RFC 2277], IETF Policy on Character
Languages, this document includes UTF8String as a choice in Sets and Languages, this document includes UTF8String as a choice in
DirectoryString and the CPS qualifier extensions. DirectoryString and the CPS qualifier extensions.
Implementers should note that the DER encoding of the SET OF values Implementers should note that the DER encoding of the SET OF values
requires ordering of the encodings of the values. In particular, requires ordering of the encodings of the values. In particular,
this issue arises with respect to distinguished names. this issue arises with respect to distinguished names.
Implementers should note that the DER encoding of SET or SEQUENCE
components whose value is the DEFAULT omit the component from the
encoded certificate or CRL. For example, a BasicConstraints
extension whose cA value is FALSE would omit the cA boolean from the
encoded certificate.
Object Identifiers (OIDs) are used throughout this specification to Object Identifiers (OIDs) are used throughout this specification to
identify certificate policies, public key and signature algorithms, identify certificate policies, public key and signature algorithms,
certificate extensions, etc. There is no maximum size for OIDs. certificate extensions, etc. There is no maximum size for OIDs.
This specification mandates support for OIDs which have arc elements This specification mandates support for OIDs which have arc elements
with values that are less than 2^28, that is, they MUST be between 0 with values that are less than 2^28, that is, they MUST be between 0
and 268,435,455, inclusive. This allows each arc element to be and 268,435,455, inclusive. This allows each arc element to be
represented within a single 32 bit word. Implementations MUST also represented within a single 32 bit word. Implementations MUST also
support OIDs where the length of the dotted decimal (see [LDAP], support OIDs where the length of the dotted decimal (see [RFC 2252],
section 4.1.2) string representation can be up to 100 bytes section 4.1) string representation can be up to 100 bytes
(inclusive). Implementations MUST be able to handle OIDs with up to (inclusive). Implementations MUST be able to handle OIDs with up to
20 elements (inclusive). CAs SHOULD NOT issue certificates which 20 elements (inclusive). CAs SHOULD NOT issue certificates which
contain OIDs that exceed these requirements. contain OIDs that exceed these requirements.
Implementors are warned that the X.500 standards community has Implementors are warned that the X.500 standards community has
developed a series of extensibility rules. These rules determine developed a series of extensibility rules. These rules determine
when an ASN.1 definition can be changed without assigning a new when an ASN.1 definition can be changed without assigning a new
object identifier (OID). For example, at least two extension object identifier (OID). For example, at least two extension
definitions included in RFC 2459 have different ASN.1 definitions in definitions included in RFC 2459 [RFC 2459], the predecessor to this
this specification, but the same OID is used. If unknown elements profile document, have different ASN.1 definitions in this
appear within an extension, and the extension is not marked critical, specification, but the same OID is used. If unknown elements appear
those unknown elements ought to be ignored, as follows: within an extension, and the extension is not marked critical, those
unknown elements ought to be ignored, as follows:
(a) ignore all unknown bit name assignments within a bit string; (a) ignore all unknown bit name assignments within a bit string;
(b) ignore all unknown named numbers in an ENUMERATED type or (b) ignore all unknown named numbers in an ENUMERATED type or
INTEGER type that is being used in the enumerated style, provided INTEGER type that is being used in the enumerated style, provided
the number occurs as an optional element of a SET or SEQUENCE; and the number occurs as an optional element of a SET or SEQUENCE; and
(c) ignore all unknown elements in SETs, at the end of SEQUENCEs, (c) ignore all unknown elements in SETs, at the end of SEQUENCEs,
or in CHOICEs where the CHOICE is itself an optional element of a or in CHOICEs where the CHOICE is itself an optional element of a
SET or SEQUENCE. SET or SEQUENCE.
skipping to change at page 111, line 37 skipping to change at page 114, line 13
The certificates were processed using Peter Gutman's dumpasn1 utility The certificates were processed using Peter Gutman's dumpasn1 utility
to generate the output. The source for the dumpasn1 utility is to generate the output. The source for the dumpasn1 utility is
available at <http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c>. The available at <http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c>. The
binaries for the certificates and CRLs are available at binaries for the certificates and CRLs are available at
<http://csrc.nist.gov/pki/pkixtools>. <http://csrc.nist.gov/pki/pkixtools>.
C.1 Certificate C.1 Certificate
This section contains an annotated hex dump of a 699 byte version 3 This section contains an annotated hex dump of a 699 byte version 3
certificate. The certificate contains the following information: certificate. The certificate contains the following information:
(a) the serial number is 23 (17 hex); (a) the serial number is 23 (17 hex);
(b) the certificate is signed with DSA and the SHA-1 hash algorithm; (b) the certificate is signed with DSA and the SHA-1 hash algorithm;
(c) the issuer's distinguished name is OU=NIST; O=gov; C=US (c) the issuer's distinguished name is OU=NIST; O=gov; C=US
(d) and the subject's distinguished name is OU=NIST; O=gov; C=US (d) and the subject's distinguished name is OU=NIST; O=gov; C=US
(e) the certificate was issued on June 30, 1997 and will expire on (e) the certificate was issued on June 30, 1997 and will expire on
December 31, 1997; December 31, 1997;
(f) the certificate contains a 1024 bit DSA public key with (f) the certificate contains a 1024 bit DSA public key with
parameters; parameters;
(g) the certificate contains a subject key identifier extension; and (g) the certificate contains a subject key identifier extension
(h) the certificate is a CA certificate (as indicated through the generated using method (1) of section 4.2.1.2; and
(h) the certificate is a CA certificate (as indicated through the
basic constraints extension.) basic constraints extension.)
0 30 701: SEQUENCE { 0 30 699: SEQUENCE {
4 30 637: SEQUENCE { 4 30 635: SEQUENCE {
8 A0 3: [0] { 8 A0 3: [0] {
10 02 1: INTEGER 2 10 02 1: INTEGER 2
: } : }
13 02 1: INTEGER 23 13 02 1: INTEGER 17
16 30 9: SEQUENCE { 16 30 9: SEQUENCE {
18 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 18 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
: } : }
27 30 42: SEQUENCE { 27 30 42: SEQUENCE {
29 31 11: SET { 29 31 11: SET {
31 30 9: SEQUENCE { 31 30 9: SEQUENCE {
33 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 33 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
38 13 2: PrintableString 'US' 38 13 2: PrintableString 'US'
: } : }
: } : }
42 31 12: SET { 42 31 12: SET {
44 30 10: SEQUENCE { 44 30 10: SEQUENCE {
46 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 46 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
51 13 3: PrintableString 'gov' 51 13 3: PrintableString 'gov'
: } : }
: } : }
56 31 13: SET { 56 31 13: SET {
58 30 11: SEQUENCE { 58 30 11: SEQUENCE {
60 06 3: OBJECT IDENTIFIER 60 06 3: OBJECT IDENTIFIER
organizationalUnitName (2 5 4 11) : organizationalUnitName (2 5 4 11)
65 13 4: PrintableString 'NIST' 65 13 4: PrintableString 'NIST'
: } : }
: } : }
: } : }
71 30 30: SEQUENCE { 71 30 30: SEQUENCE {
73 17 13: UTCTime '970630000000Z' 73 17 13: UTCTime '970630000000Z'
88 17 13: UTCTime '971231000000Z' 88 17 13: UTCTime '971231000000Z'
: } : }
103 30 42: SEQUENCE { 103 30 42: SEQUENCE {
105 31 11: SET { 105 31 11: SET {
skipping to change at page 112, line 52 skipping to change at page 115, line 29
: } : }
118 31 12: SET { 118 31 12: SET {
120 30 10: SEQUENCE { 120 30 10: SEQUENCE {
122 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 122 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
127 13 3: PrintableString 'gov' 127 13 3: PrintableString 'gov'
: } : }
: } : }
132 31 13: SET { 132 31 13: SET {
134 30 11: SEQUENCE { 134 30 11: SEQUENCE {
136 06 3: OBJECT IDENTIFIER 136 06 3: OBJECT IDENTIFIER
organizationalUnitName (2 5 4 11) : organizationalUnitName (2 5 4 11)
141 13 4: PrintableString 'NIST' 141 13 4: PrintableString 'NIST'
: } : }
: } : }
: } : }
147 30 440: SEQUENCE { 147 30 440: SEQUENCE {
151 30 300: SEQUENCE { 151 30 300: SEQUENCE {
155 06 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1) 155 06 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1)
164 30 287: SEQUENCE { 164 30 287: SEQUENCE {
168 02 129: INTEGER 168 02 129: INTEGER
: 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC FB 95 : 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC
: 32 AC 01 12 33 B9 E0 1C AD 90 9B BC 48 54 9E F3 : FB 95 32 AC 01 12 33 B9 E0 1C AD 90 9B BC
: 94 77 3C 2C 71 35 55 E6 FE 4F 22 CB D5 D8 3E 89 : 48 54 9E F3 94 77 3C 2C 71 35 55 E6 FE 4F
: 93 33 4D FC BD 4F 41 64 3E A2 98 70 EC 31 B4 50 : 22 CB D5 D8 3E 89 93 33 4D FC BD 4F 41 64
: DE EB F1 98 28 0A C9 3E 44 B3 FD 22 97 96 83 D0 : 3E A2 98 70 EC 31 B4 50 DE EB F1 98 28 0A
: 18 A3 E3 BD 35 5B FF EE A3 21 72 6A 7B 96 DA B9 : C9 3E 44 B3 FD 22 97 96 83 D0 18 A3 E3 BD
: 3F 1E 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A : 35 5B FF EE A3 21 72 6A 7B 96 DA B9 3F 1E
: FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48 63 FE : 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A
: 43 : FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48
: 63 FE 43
300 02 21: INTEGER 300 02 21: INTEGER
: 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA 55 F7 : 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA
: 7D 57 74 81 E5 : 55 F7 7D 57 74 81 E5
323 02 129: INTEGER 323 02 129: INTEGER
: 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91 C0 8E : 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91
: 47 F1 0A C3 01 47 C2 44 42 36 A9 92 81 DE 57 C5 : C0 8E 47 F1 0A C3 01 47 C2 44 42 36 A9 92
: E0 68 86 58 00 7B 1F F9 9B 77 A1 C5 10 A5 80 91 : 81 DE 57 C5 E0 68 86 58 00 7B 1F F9 9B 77
: 78 51 51 3C F6 FC FC CC 46 C6 81 78 92 84 3D F4 : A1 C5 10 A5 80 91 78 51 51 3C F6 FC FC CC
: 93 3D 0C 38 7E 1A 5B 99 4E AB 14 64 F6 0C 21 22 : 46 C6 81 78 92 84 3D F4 93 3D 0C 38 7E 1A
: 4E 28 08 9C 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF : 5B 99 4E AB 14 64 F6 0C 21 22 4E 28 08 9C
: 39 A2 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF : 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 39 A2
: F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE 1E 57 : 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF
: 18 : F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE
: 1E 57 18
: } : }
: } : }
455 03 133: BIT STRING 0 unused bits 455 03 133: BIT STRING 0 unused bits, encapsulates {
: 02 81 81 00 B5 9E 1F 49 04 47 D1 DB F5 3A DD CA 459 02 129: INTEGER
: 04 75 E8 DD 75 F6 9B 8A B1 97 D6 59 69 82 D3 03 : 00 B5 9E 1F 49 04 47 D1 DB F5 3A DD CA 04
: 4D FD 3B 36 5F 4A F2 D1 4E C1 07 F5 D1 2A D3 78 : 75 E8 DD 75 F6 9B 8A B1 97 D6 59 69 82 D3
: 77 63 56 EA 96 61 4D 42 0B 7A 1D FB AB 91 A4 CE : 03 4D FD 3B 36 5F 4A F2 D1 4E C1 07 F5 D1
: DE EF 77 C8 E5 EF 20 AE A6 28 48 AF BE 69 C3 6A : 2A D3 78 77 63 56 EA 96 61 4D 42 0B 7A 1D
: A5 30 F2 C2 B9 D9 82 2B 7D D9 C4 84 1F DE 0D E8 : FB AB 91 A4 CE DE EF 77 C8 E5 EF 20 AE A6
: 54 D7 1B 99 2E B3 D0 88 F6 D6 63 9B A7 E2 0E 82 : 28 48 AF BE 69 C3 6A A5 30 F2 C2 B9 D9 82
: D4 3B 8A 68 1B 06 56 31 59 0B 49 EB 99 A5 D5 81 : 2B 7D D9 C4 84 1F DE 0D E8 54 D7 1B 99 2E
: 41 7B C9 55 : B3 D0 88 F6 D6 63 9B A7 E2 0E 82 D4 3B 8A
: 68 1B 06 56 31 59 0B 49 EB 99 A5 D5 81 41
: 7B C9 55
: }
: } : }
591 A3 52: [3] { 591 A3 50: [3] {
593 30 50: SEQUENCE { 593 30 48: SEQUENCE {
595 30 31: SEQUENCE { 595 30 29: SEQUENCE {
597 06 3: OBJECT IDENTIFIER 597 06 3: OBJECT IDENTIFIER
subjectKeyIdentifier (2 5 29 14) : subjectKeyIdentifier (2 5 29 14)
602 04 24: OCTET STRING 602 04 22: OCTET STRING, encapsulates {
: 04 16 04 14 E7 26 C5 54 CD 5B A3 6F 35 68 95 AA 604 04 20: OCTET STRING
: D5 FF 1C 21 E4 22 75 D6 : 86 CA A5 22 81 62 EF AD 0A 89 BC AD 72 41
: 2C 29 49 F4 86 56
: }
: } : }
628 30 15: SEQUENCE { 626 30 15: SEQUENCE {
630 06 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19) 628 06 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19)
635 01 1: BOOLEAN TRUE 633 01 1: BOOLEAN TRUE
638 04 5: OCTET STRING 636 04 5: OCTET STRING, encapsulates {
: 30 03 01 01 FF 638 30 3: SEQUENCE {
640 01 1: BOOLEAN TRUE
: }
: }
: } : }
: } : }
: } : }
: } : }
645 30 9: SEQUENCE { 643 30 9: SEQUENCE {
647 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 645 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
: } : }
656 03 47: BIT STRING 0 unused bits 654 03 47: BIT STRING 0 unused bits, encapsulates {
: 30 2C 02 14 6A F9 3F 72 30 7F 45 DC E5 50 C1 5E 657 30 44: SEQUENCE {
: 94 A0 6D C7 92 4C E5 E1 02 14 6F 61 B8 65 F7 AA 659 02 20: INTEGER
: DF 46 1B F7 39 0D 0D 88 9E FE B6 83 F7 1A : 43 1B CF 29 25 45 C0 4E 52 E7 7D D6 FC B1
: 66 4C 83 CF 2D 77
681 02 20: INTEGER
: 0B 5B 9A 24 11 98 E8 F3 86 90 04 F6 08 A9
: E1 8D A5 CC 3A D4
: }
: }
: } : }
C.2 Certificate C.2 Certificate
This section contains an annotated hex dump of a 730 byte version 3 This section contains an annotated hex dump of a 730 byte version 3
certificate. The certificate contains the following information: certificate. The certificate contains the following information:
(a) the serial number is 18 (12 hex); (a the serial number is 18 (12 hex);
(b) the certificate is signed with DSA and the SHA-1 hash algorithm; (b) the certificate is signed with DSA and the SHA-1 hash algorithm;
(c) the issuer's distinguished name is OU=nist; O=gov; C=US (c) the issuer's distinguished name is OU=nist; O=gov; C=US
(d) and the subject's distinguished name is CN=Tim Polk; OU=nist; (d) and the subject's distinguished name is CN=Tim Polk; OU=nist;
O=gov; C=US O=gov; C=US
(e) the certificate was valid from July 30, 1997 through December 1, (e) the certificate was valid from July 30, 1997 through December 1,
1997; 1997;
(f) the certificate contains a 1024 bit DSA public key; (f) the certificate contains a 1024 bit DSA 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
and matching the subject key identifier of the certificate in Appendix
(i) the certificate includes one alternative name - an RFC 822 C.1; and
address. (i) the certificate includes one alternative name - an RFC 822
address of "wpolk@nist.gov".
0 30 734: SEQUENCE { 0 30 730: SEQUENCE {
4 30 669: SEQUENCE { 4 30 665: SEQUENCE {
8 A0 3: [0] { 8 A0 3: [0] {
10 02 1: INTEGER 2 10 02 1: INTEGER 2
: } : }
13 02 1: INTEGER 18 13 02 1: INTEGER 18
16 30 9: SEQUENCE { 16 30 9: SEQUENCE {
18 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 18 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
: } : }
27 30 42: SEQUENCE { 27 30 42: SEQUENCE {
29 31 11: SET { 29 31 11: SET {
31 30 9: SEQUENCE { 31 30 9: SEQUENCE {
skipping to change at page 115, line 23 skipping to change at page 118, line 17
: } : }
42 31 12: SET { 42 31 12: SET {
44 30 10: SEQUENCE { 44 30 10: SEQUENCE {
46 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 46 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
51 13 3: PrintableString 'gov' 51 13 3: PrintableString 'gov'
: } : }
: } : }
56 31 13: SET { 56 31 13: SET {
58 30 11: SEQUENCE { 58 30 11: SEQUENCE {
60 06 3: OBJECT IDENTIFIER 60 06 3: OBJECT IDENTIFIER
organizationalUnitName (2 5 4 11) : organizationalUnitName (2 5 4 11)
65 13 4: PrintableString 'NIST' 65 13 4: PrintableString 'NIST'
: } : }
: } : }
: } : }
71 30 30: SEQUENCE { 71 30 30: SEQUENCE {
73 17 13: UTCTime '970730000000Z' 73 17 13: UTCTime '970730000000Z'
88 17 13: UTCTime '971201000000Z' 88 17 13: UTCTime '971201000000Z'
: } : }
103 30 61: SEQUENCE { 103 30 61: SEQUENCE {
105 31 11: SET { 105 31 11: SET {
skipping to change at page 115, line 48 skipping to change at page 118, line 42
: } : }
118 31 12: SET { 118 31 12: SET {
120 30 10: SEQUENCE { 120 30 10: SEQUENCE {
122 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 122 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
127 13 3: PrintableString 'gov' 127 13 3: PrintableString 'gov'
: } : }
: } : }
132 31 13: SET { 132 31 13: SET {
134 30 11: SEQUENCE { 134 30 11: SEQUENCE {
136 06 3: OBJECT IDENTIFIER 136 06 3: OBJECT IDENTIFIER
organizationalUnitName (2 5 4 11) : organizationalUnitName (2 5 4 11)
141 13 4: PrintableString 'NIST' 141 13 4: PrintableString 'NIST'
: } : }
: } : }
147 31 17: SET { 147 31 17: SET {
149 30 15: SEQUENCE { 149 30 15: SEQUENCE {
151 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 151 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
156 13 8: PrintableString 'Tim Polk' 156 13 8: PrintableString 'Tim Polk'
: } : }
: } : }
: } : }
166 30 439: SEQUENCE { 166 30 439: SEQUENCE {
170 30 300: SEQUENCE { 170 30 300: SEQUENCE {
174 06 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1) 174 06 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1)
183 30 287: SEQUENCE { 183 30 287: SEQUENCE {
187 02 129: INTEGER 187 02 129: INTEGER
: 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC FB 95 : 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC
: 32 AC 01 12 33 B9 E0 1C AD 90 9B BC 48 54 9E F3 : FB 95 32 AC 01 12 33 B9 E0 1C AD 90 9B BC
: 94 77 3C 2C 71 35 55 E6 FE 4F 22 CB D5 D8 3E 89 : 48 54 9E F3 94 77 3C 2C 71 35 55 E6 FE 4F
: 93 33 4D FC BD 4F 41 64 3E A2 98 70 EC 31 B4 50 : 22 CB D5 D8 3E 89 93 33 4D FC BD 4F 41 64
: DE EB F1 98 28 0A C9 3E 44 B3 FD 22 97 96 83 D0 : 3E A2 98 70 EC 31 B4 50 DE EB F1 98 28 0A
: 18 A3 E3 BD 35 5B FF EE A3 21 72 6A 7B 96 DA B9 : C9 3E 44 B3 FD 22 97 96 83 D0 18 A3 E3 BD
: 3F 1E 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A : 35 5B FF EE A3 21 72 6A 7B 96 DA B9 3F 1E
: FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48 63 FE : 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A
: 43 : FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48
: 63 FE 43
319 02 21: INTEGER 319 02 21: INTEGER
: 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA 55 F7 : 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA
: 7D 57 74 81 E5 : 55 F7 7D 57 74 81 E5
342 02 129: INTEGER 342 02 129: INTEGER
: 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91 C0 8E : 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91
: 47 F1 0A C3 01 47 C2 44 42 36 A9 92 81 DE 57 C5 : C0 8E 47 F1 0A C3 01 47 C2 44 42 36 A9 92
: E0 68 86 58 00 7B 1F F9 9B 77 A1 C5 10 A5 80 91 : 81 DE 57 C5 E0 68 86 58 00 7B 1F F9 9B 77
: 78 51 51 3C F6 FC FC CC 46 C6 81 78 92 84 3D F4 : A1 C5 10 A5 80 91 78 51 51 3C F6 FC FC CC
: 93 3D 0C 38 7E 1A 5B 99 4E AB 14 64 F6 0C 21 22 : 46 C6 81 78 92 84 3D F4 93 3D 0C 38 7E 1A
: 4E 28 08 9C 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF : 5B 99 4E AB 14 64 F6 0C 21 22 4E 28 08 9C
: 39 A2 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF : 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 39 A2
: F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE 1E 57 : 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF
: 18 : F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE
: 1E 57 18
: } : }
: } : }
474 03 132: BIT STRING 0 unused bits 474 03 132: BIT STRING 0 unused bits, encapsulates {
: 02 81 80 30 B6 75 F7 7C 20 31 AE 38 BB 7E 0D 2B 478 02 128: INTEGER
: AB A0 9C 4B DF 20 D5 24 13 3C CD 98 E5 5F 6C B7 : 30 B6 75 F7 7C 20 31 AE 38 BB 7E 0D 2B AB
: C1 BA 4A BA A9 95 80 53 F0 0D 72 DC 33 37 F4 01 : A0 9C 4B DF 20 D5 24 13 3C CD 98 E5 5F 6C
: 0B F5 04 1F 9D 2E 1F 62 D8 84 3A 9B 25 09 5A 2D : B7 C1 BA 4A BA A9 95 80 53 F0 0D 72 DC 33
: C8 46 8E 2B D4 F5 0D 3B C7 2D C6 6C B9 98 C1 25 : 37 F4 01 0B F5 04 1F 9D 2E 1F 62 D8 84 3A
: 3A 44 4E 8E CA 95 61 35 7C CE 15 31 5C 23 13 1E : 9B 25 09 5A 2D C8 46 8E 2B D4 F5 0D 3B C7
: A2 05 D1 7A 24 1C CB D3 72 09 90 FF 9B 9D 28 C0 : 2D C6 6C B9 98 C1 25 3A 44 4E 8E CA 95 61
: A1 0A EC 46 9F 0D B8 D0 DC D0 18 A6 2B 5E F9 8F : 35 7C CE 15 31 5C 23 13 1E A2 05 D1 7A 24
: B5 95 BE : 1C CB D3 72 09 90 FF 9B 9D 28 C0 A1 0A EC
: 46 9F 0D B8 D0 DC D0 18 A6 2B 5E F9 8F B5
: 95 BE
: }
: } : }
609 A3 66: [3] { 609 A3 62: [3] {
611 30 64: SEQUENCE { 611 30 60: SEQUENCE {
613 30 25: SEQUENCE { 613 30 25: SEQUENCE {
615 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 615 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17)
620 04 18: OCTET STRING 620 04 18: OCTET STRING, encapsulates {
: 30 10 81 0E 77 70 6F 6C 6B 40 6E 69 73 74 2E 67 622 30 16: SEQUENCE {
: 6F 76 624 81 14: [1] 'wpolk@nist.gov'
: }
: }
: } : }
640 30 35: SEQUENCE { 640 30 31: SEQUENCE {
642 06 3: OBJECT IDENTIFIER 642 06 3: OBJECT IDENTIFIER
authorityKeyIdentifier (2 5 29 35) : authorityKeyIdentifier (2 5 29 35)
647 04 28: OCTET STRING 647 04 24: OCTET STRING, encapsulates {
: 30 1A 80 18 04 16 04 14 E7 26 C5 54 CD 5B A3 6F 649 30 22: SEQUENCE {
: 35 68 95 AA D5 FF 1C 21 E4 22 75 D6 651 80 20: [0]
: 86 CA A5 22 81 62 EF AD 0A 89 BC AD 72
: 41 2C 29 49 F4 86 56
: }
: }
: } : }
: } : }
: } : }
: } : }
677 30 9: SEQUENCE { 673 30 9: SEQUENCE {
679 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 675 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
: } : }
688 03 48: BIT STRING 0 unused bits 684 03 48: BIT STRING 0 unused bits, encapsulates {
: 30 2D 02 14 37 FC 44 BF 7F 8D 18 1F 40 04 2F CF 687 30 45: SEQUENCE {
: EA CC 22 B2 16 01 FF 13 02 15 00 97 D0 24 96 0F 689 02 20: INTEGER
: 64 8A C3 8D 41 B2 0E B9 26 D5 31 D1 A0 F1 BC : 36 97 CB E3 B4 2C E1 BB 61 A9 D3 CC 24 CC
: 22 92 9F F4 F5 87
711 02 21: INTEGER
: 00 AB C9 79 AF D2 16 1C A9 E3 68 A9 14 10
: B4 A0 2E FF 22 5A 73
: }
: }
: } : }
C.3 End Entity Certificate Using RSA C.3 End Entity Certificate Using RSA
This section contains an annotated hex dump of a 675 byte version 3 This section contains an annotated hex dump of a 654 byte version 3
certificate. The certificate contains the following information: certificate. The certificate contains the following information:
(a) the serial number is 256; (a) the serial number is 256;
(b) the certificate is signed with RSA and the MD2 hash algorithm; (b) the certificate is signed with RSA and the SHA-1 hash algorithm;
(c) the issuer's distinguished name is OU=Dept. Arquitectura de (c) the issuer's distinguished name is OU=NIST; O=gov; C=US
Computadors; O=Universitat Politecnica de Catalunya; C=ES (d) and the subject's distinguished name is CN=Tim Polk; OU=NIST;
(d) and the subject's distinguished name is CN=Francisco Jordan; O=gov; C=US
OU=Dept. Arquitectura de Computadors; O=Universitat Politecnica de (e) the certificate was issued on May 21, 1996 at 09:58:26 and
Catalunya; C=ES expired on May 21, 1997 at 09:58:26;
(e) the certificate was issued on May 21, 1996 and expired on May 21, (f) the certificate contains a 1024 bit RSA public key;
1997; (g) the certificate is an end entity certificate (not a CA
(f) the certificate contains a 768 bit RSA public key;
(g) the certificate is an end entity certificate (not a CA
certificate); certificate);
(h) the certificate includes an alternative subject name and an (h) the certificate includes an alternative subject name of
alternative issuer name - bothe are URLs; "<http://www.itl.nist.gov/div893/staff/polk/index.html>" and an
(i) the certificate include an authority key identifier and alternative issuer name of "<http://www.nist.gov/>" - both are URLs;
certificate policies extensions; and (i) the certificate include an authority key identifier extension
(j) the certificate includes a critical key usage extension and a certificate policies extension psecifying the policy OID
specifying the public is intended for generation of digital 2.16.840.1.101.3.2.1.48.9; and
signatures. (j) the certificate includes a critical key usage extension
specifying that the public key is intended for verification of
digital signatures.
0 30 654: SEQUENCE { 0 30 654: SEQUENCE {
4 30 503: SEQUENCE { 4 30 503: SEQUENCE {
8 A0 3: [0] { 8 A0 3: [0] {
10 02 1: INTEGER 2 10 02 1: INTEGER 2
: } : }
13 02 2: INTEGER 256 13 02 2: INTEGER 256
17 30 13: SEQUENCE { 17 30 13: SEQUENCE {
19 06 9: OBJECT IDENTIFIER 19 06 9: OBJECT IDENTIFIER
: sha1withRSAEncryption (1 2 840 113549 1 1 5) : sha1withRSAEncryption (1 2 840 113549 1 1 5)
skipping to change at page 118, line 26 skipping to change at page 121, line 37
: } : }
32 30 42: SEQUENCE { 32 30 42: SEQUENCE {
34 31 11: SET { 34 31 11: SET {
36 30 9: SEQUENCE { 36 30 9: SEQUENCE {
38 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 38 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
43 13 2: PrintableString 'US' 43 13 2: PrintableString 'US'
: } : }
: } : }
47 31 12: SET { 47 31 12: SET {
49 30 10: SEQUENCE { 49 30 10: SEQUENCE {
51 06 3: OBJECT IDENTIFIER 51 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
organizationalUnitName (2 5 4 11)
56 13 3: PrintableString 'gov' 56 13 3: PrintableString 'gov'
: } : }
: } : }
61 31 13: SET { 61 31 13: SET {
63 30 11: SEQUENCE { 63 30 11: SEQUENCE {
65 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 65 06 3: OBJECT IDENTIFIER
: organizationalUnitName (2 5 4 11)
70 13 4: PrintableString 'NIST' 70 13 4: PrintableString 'NIST'
: } : }
: } : }
: } : }
76 30 30: SEQUENCE { 76 30 30: SEQUENCE {
78 17 13: UTCTime '960521095826Z' 78 17 13: UTCTime '960521095826Z'
93 17 13: UTCTime '970521095826Z' 93 17 13: UTCTime '970521095826Z'
: } : }
108 30 61: SEQUENCE { 108 30 61: SEQUENCE {
110 31 11: SET { 110 31 11: SET {
112 30 9: SEQUENCE { 112 30 9: SEQUENCE {
114 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 114 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
119 13 2: PrintableString 'US' 119 13 2: PrintableString 'US'
: } : }
: } : }
123 31 12: SET { 123 31 12: SET {
125 30 10: SEQUENCE { 125 30 10: SEQUENCE {
127 06 3: OBJECT IDENTIFIER 127 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
organizationalUnitName (2 5 4 11)
132 13 3: PrintableString 'gov' 132 13 3: PrintableString 'gov'
: } : }
: } : }
137 31 13: SET { 137 31 13: SET {
139 30 11: SEQUENCE { 139 30 11: SEQUENCE {
141 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 141 06 3: OBJECT IDENTIFIER
: organizationalUnitName (2 5 4 11)
146 13 4: PrintableString 'NIST' 146 13 4: PrintableString 'NIST'
: } : }
: } : }
152 31 17: SET { 152 31 17: SET {
154 30 15: SEQUENCE { 154 30 15: SEQUENCE {
156 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 156 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
161 13 8: PrintableString 'Tim Polk' 161 13 8: PrintableString 'Tim Polk'
: } : }
: } : }
: } : }
171 30 159: SEQUENCE { 171 30 159: SEQUENCE {
174 30 13: SEQUENCE { 174 30 13: SEQUENCE {
176 06 9: OBJECT IDENTIFIER 176 06 9: OBJECT IDENTIFIER
rsaEncryption (1 2 840 113549 1 1 1) : rsaEncryption (1 2 840 113549 1 1 1)
187 05 0: NULL 187 05 0: NULL
: } : }
189 03 141: BIT STRING 0 unused bits 189 03 141: BIT STRING 0 unused bits, encapsulates {
: 30 81 89 02 81 81 00 E1 CE 06 C9 D7 00 DF 65 27 193 30 137: SEQUENCE {
: 45 1E 63 6A 09 A0 A0 10 4B AF DF 9D 36 1D 44 1F 196 02 129: INTEGER
: B7 07 5D 36 92 09 6A 1A 96 C7 4E D9 86 0D 0F 77 : 00 E1 6A E4 03 30 97 02 3C F4 10 F3 B5 1E
: 94 F5 82 62 68 9A F2 D7 76 F5 9A 35 C7 B3 7F 4F : 4D 7F 14 7B F6 F5 D0 78 E9 A4 8A F0 A3 75
: BE 64 CF A3 0C B3 84 32 80 F5 CA 77 29 C9 76 0B : EC ED B6 56 96 7F 88 99 85 9A F2 3E 68 77
: 4C 38 19 EE 61 6F BA 68 E0 03 85 46 34 AB 84 64 : 87 EB 9E D1 9F C0 B4 17 DC AB 89 23 A4 1D
: 7F 43 69 02 C0 20 86 BD B1 D4 AD 21 A9 1A 8F CF : 7E 16 23 4C 4F A8 4D F5 31 B8 7C AA E3 1A
: 96 83 86 92 57 5B 43 09 28 4C F2 5A 04 AD E5 DE : 49 09 F4 4B 26 DB 27 67 30 82 12 01 4A E9
: 9E 4F E8 38 3C F0 89 02 03 01 00 01 : 1A B6 C1 0C 53 8B 6C FC 2F 7A 43 EC 33 36
: 7E 32 B2 7B D5 AA CF 01 14 C6 12 EC 13 F2
: 2D 14 7A 8B 21 58 14 13 4C 46 A3 9A F2 16
: 95 FF 23
328 02 3: INTEGER 65537
: }
: }
: } : }
333 A3 175: [3] { 333 A3 175: [3] {
336 30 172: SEQUENCE { 336 30 172: SEQUENCE {
339 30 63: SEQUENCE { 339 30 63: SEQUENCE {
341 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 341 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17)
346 04 56: OCTET STRING 346 04 56: OCTET STRING, encapsulates {
: 30 36 86 34 68 74 74 70 3A 2F 2F 77 77 77 2E 69 348 30 54: SEQUENCE {
: 74 6C 2E 6E 69 73 74 2E 67 6F 76 2F 64 69 76 38 350 86 52: [6]
: 39 33 2F 73 74 61 66 66 2F 70 6F 6C 6B 2F 69 6E : 'http://www.itl.nist.gov/div893/staff/'
: 64 65 78 2E 68 74 6D 6C : 'polk/index.html'
: }
: }
: } : }
404 30 31: SEQUENCE { 404 30 31: SEQUENCE {
406 06 3: OBJECT IDENTIFIER issuerAltName (2 5 29 18) 406 06 3: OBJECT IDENTIFIER issuerAltName (2 5 29 18)
411 04 24: OCTET STRING 411 04 24: OCTET STRING, encapsulates {
: 30 16 86 14 68 74 74 70 3A 2F 2F 77 77 77 2E 6E 413 30 22: SEQUENCE {
: 69 73 74 2E 67 6F 76 2F 415 86 20: [6] 'http://www.nist.gov/'
: }
: }
: } : }
437 30 31: SEQUENCE { 437 30 31: SEQUENCE {
439 06 3: OBJECT IDENTIFIER 439 06 3: OBJECT IDENTIFIER
authorityKeyIdentifier (2 5 29 35) : authorityKeyIdentifier (2 5 29 35)
444 04 24: OCTET STRING 444 04 24: OCTET STRING, encapsulates {
: 30 16 80 14 30 12 80 10 0E 6B 3A BF 04 EA 04 C3 446 30 22: SEQUENCE {
: 0E 6B 3A BF 04 EA 04 C3 448 80 20: [0]
: 08 68 AF 85 33 C8 39 4A 7A F8 82 93 8E
: 70 6A 4A 20 84 2C 32
: }
: }
: } : }
470 30 23: SEQUENCE { 470 30 23: SEQUENCE {
472 06 3: OBJECT IDENTIFIER 472 06 3: OBJECT IDENTIFIER
certificatePolicies (2 5 29 32) : certificatePolicies (2 5 29 32)
477 04 16: OCTET STRING 477 04 16: OCTET STRING, encapsulates {
: 30 0E 30 0C 06 0A 60 86 48 01 65 03 02 01 30 09 479 30 14: SEQUENCE {
481 30 12: SEQUENCE {
483 06 10: OBJECT IDENTIFIER
: '2 16 840 1 101 3 2 1 48 9'
: }
: }
: }
: } : }
495 30 14: SEQUENCE { 495 30 14: SEQUENCE {
497 06 3: OBJECT IDENTIFIER keyUsage (2 5 29 15) 497 06 3: OBJECT IDENTIFIER keyUsage (2 5 29 15)
502 01 1: BOOLEAN TRUE 502 01 1: BOOLEAN TRUE
505 04 4: OCTET STRING 505 04 4: OCTET STRING, encapsulates {
: 03 02 07 80 507 03 2: BIT STRING 7 unused bits
: '1'B (bit 0)
: }
: } : }
: } : }
: } : }
: } : }
511 30 13: SEQUENCE { 511 30 13: SEQUENCE {
513 06 9: OBJECT IDENTIFIER 513 06 9: OBJECT IDENTIFIER
: sha1withRSAEncryption (1 2 840 113549 1 1 5) : sha1withRSAEncryption (1 2 840 113549 1 1 5)
524 05 0: NULL 524 05 0: NULL
: } : }
526 03 129: BIT STRING 0 unused bits 526 03 129: BIT STRING 0 unused bits
: C1 25 6F AB 72 C0 5D DA E4 2F D5 E1 B0 25 D8 B4 : 1E 07 77 6E 66 B5 B6 B8 57 F0 03 DC 6F 77
: F1 82 95 D6 0D A5 4E 4F A1 23 E1 13 A4 9C 3D C5 : 6D AF 55 1D 74 E5 CE 36 81 FC 4B C5 F4 47
: 7F FD 05 EC 75 06 30 66 97 75 A6 5D 8F 97 BA B4 : 82 C4 0A 25 AA 8D D6 7D 3A 89 AB 44 34 39
: EC A9 43 19 8D B7 54 FD E9 AD 43 B8 3C 8B D3 9E : F6 BD 61 1A 78 85 7A B8 1E 92 A2 22 2F CE
: C7 C7 27 E3 1A AD D3 79 AC 65 5A 52 78 C4 D0 43 : 07 1A 08 8E F1 46 03 59 36 4A CB 60 E6 03
: 81 50 F7 8A BA E2 30 1A 6D D0 78 A0 4E AE 2E 79 : 40 01 5B 2A 44 D6 E4 7F EB 43 5E 74 0A E6
: 37 0C 93 05 5C D1 9C 1B B2 62 73 D1 EA 50 B7 84 : E4 F9 3E E1 44 BE 1F E7 5F 5B 2C 41 8D 08
: 29 92 74 34 CF BA AA 2C 4D 43 59 EF 98 0C 41 6C : BD 26 FE 6A A6 C3 2F B2 3B 41 12 6B C1 06
: 8A B8 4C 91 59 EB 2F 38 20 2A 67 74 20 0B
: 77 F3
: } : }
C.4 Certificate Revocation List C.4 Certificate Revocation List
This section contains an annotated hex dump of a version 2 CRL with This section contains an annotated hex dump of a version 2 CRL with
one extension (cRLNumber). The CRL was issued by OU=nist;O=gov;C=us one extension (cRLNumber). The CRL was issued by OU=NIST; O=gov; C=US
on July 7, 1996; the next scheduled issuance was August 7, 1996. The on August 7, 1997; the next scheduled issuance was September 7, 1997.
CRL includes one revoked certificates: serial number 18 (12 hex). The CRL includes one revoked certificates: serial number 18 (12 hex),
The CRL itself is number 18, and it was signed with DSA and SHA-1. which was revoked on July 31, 1997 due to keyCompromise. The CRL
itself is number 18, and it was signed with DSA and SHA-1.
0 30 203: SEQUENCE { 0 30 203: SEQUENCE {
3 30 140: SEQUENCE { 3 30 140: SEQUENCE {
6 02 1: INTEGER 1 6 02 1: INTEGER 1
9 30 9: SEQUENCE { 9 30 9: SEQUENCE {
11 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 11 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
: } : }
20 30 42: SEQUENCE { 20 30 42: SEQUENCE {
22 31 11: SET { 22 31 11: SET {
24 30 9: SEQUENCE { 24 30 9: SEQUENCE {
skipping to change at page 121, line 27 skipping to change at page 125, line 14
: } : }
35 31 12: SET { 35 31 12: SET {
37 30 10: SEQUENCE { 37 30 10: SEQUENCE {
39 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 39 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
44 13 3: PrintableString 'gov' 44 13 3: PrintableString 'gov'
: } : }
: } : }
49 31 13: SET { 49 31 13: SET {
51 30 11: SEQUENCE { 51 30 11: SEQUENCE {
53 06 3: OBJECT IDENTIFIER 53 06 3: OBJECT IDENTIFIER
organizationalUnitName (2 5 4 11) : organizationalUnitName (2 5 4 11)
58 13 4: PrintableString 'NIST' 58 13 4: PrintableString 'NIST'
: } : }
: } : }
: } : }
64 17 13: UTCTime '970807000000Z' 64 17 13: UTCTime '970807000000Z'
79 17 13: UTCTime '970907000000Z' 79 17 13: UTCTime '970907000000Z'
94 30 34: SEQUENCE { 94 30 34: SEQUENCE {
96 30 32: SEQUENCE { 96 30 32: SEQUENCE {
98 02 1: INTEGER 18 98 02 1: INTEGER 18
101 17 13: UTCTime '970731000000Z' 101 17 13: UTCTime '970731000000Z'
116 30 12: SEQUENCE { 116 30 12: SEQUENCE {
118 30 10: SEQUENCE { 118 30 10: SEQUENCE {
120 06 3: OBJECT IDENTIFIER cRLReason (2 5 29 21) 120 06 3: OBJECT IDENTIFIER cRLReason (2 5 29 21)
125 04 3: OCTET STRING 125 04 3: OCTET STRING, encapsulates {
: 0A 01 01 127 0A 1: ENUMERATED 1
: }
: } : }
: } : }
: } : }
: } : }
130 A0 14: [0] { 130 A0 14: [0] {
132 30 12: SEQUENCE { 132 30 12: SEQUENCE {
134 30 10: SEQUENCE { 134 30 10: SEQUENCE {
136 06 3: OBJECT IDENTIFIER cRLNumber (2 5 29 20) 136 06 3: OBJECT IDENTIFIER cRLNumber (2 5 29 20)
141 04 3: OCTET STRING 141 04 3: OCTET STRING, encapsulates {
: 02 01 12 143 02 1: INTEGER 12
: }
: } : }
: } : }
: } : }
: } : }
146 30 9: SEQUENCE { 146 30 9: SEQUENCE {
148 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) 148 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
: } : }
157 03 47: BIT STRING 0 unused bits 157 03 47: BIT STRING 0 unused bits, encapsulates {
: 30 2C 02 14 79 1F F6 93 0B 84 06 D6 A0 7C 8D 68 160 30 44: SEQUENCE {
: A7 52 2E 5F 3F 89 9B 4B 02 14 66 D4 B5 2A 68 36 162 02 20: INTEGER
: 9B 72 88 58 E3 89 19 AD 81 89 2E 96 BB CC : 22 4E 9F 43 BA 95 06 34 F2 BB 5E 65 DB A6
: 80 05 C0 3A 29 47
184 02 20: INTEGER
: 59 1A 57 C9 82 D7 02 21 14 C3 D4 0B 32 1B
: 96 16 B1 1F 46 5A
: }
: }
: } : }
Appendix D. Author Addresses: Appendix D. Author Addresses:
Russell Housley Russell Housley
RSA Laboratories RSA Laboratories
918 Spring Knoll Drive 918 Spring Knoll Drive
Herndon, VA 20170 Herndon, VA 20170
USA USA
rhousley@rsasecurity.com rhousley@rsasecurity.com
 End of changes. 248 change blocks. 
613 lines changed or deleted 771 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/