< draft-ietf-pkix-new-part1-05.txt   draft-ietf-pkix-new-part1-06.txt >
PKIX Working Group R. Housley (SPYRUS) 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 March 2001 expires in six months April 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-05.txt> <draft-ietf-pkix-new-part1-06.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
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
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 fifth draft of a specification based upon RFC 2459. When This is the sixth draft of a specification based upon RFC 2459. When
complete, this specification will obsolete RFC 2459. This complete, this specification will obsolete RFC 2459. This
specification includes minor edits and clarifications. The most specification includes minor edits and clarifications. The most
notable departures from RFC 2459 are found in Section 6, Path notable departures from RFC 2459 are found in Section 6, Path
Validation. In RFC 2459, the reader was expected to augment the path Validation. In RFC 2459, the reader was expected to augment the path
validation algorithm, which concentrated upon policy processing, with validation algorithm, which concentrated upon policy processing, with
information embedded in earlier sections. For example, parameter information embedded in earlier sections. For example, parameter
inheritance is discussed in Section 7, Algorithm Support, and can inheritance is discussed in Section 7, Algorithm Support, and can
certainly affect the validity of a certification path. However, certainly affect the validity of a certification path. However,
parameter inheritance was omitted from the path validation algorithm parameter inheritance was omitted from the path validation algorithm
in RFC 2459. In this draft, the path validation algorithm has a in RFC 2459. In this draft, the path validation algorithm has a
skipping to change at page 3, line 5 skipping to change at page 3, line 5
(i.e., RSA, DSA, and Diffie-Hellman). ASN.1 modules and examples are (i.e., RSA, DSA, and Diffie-Hellman). ASN.1 modules and examples are
provided in the appendices. 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 Please send comments on this document to the ietf-pkix@imc.org mail
list. list.
Table of Contents Table of Contents
1 Introduction ................................................ 6
2 Requirements and Assumptions ................................ 7
2.1 Communication and Topology ................................ 7
2.2 Acceptability Criteria .................................... 8
2.3 User Expectations ......................................... 8
2.4 Administrator Expectations ................................ 8
3 Overview of Approach ........................................ 8
3.1 X.509 Version 3 Certificate ............................... 10
3.2 Certification Paths and Trust ............................. 11
3.3 Revocation ................................................ 13
3.4 Operational Protocols ..................................... 14
3.5 Management Protocols ...................................... 14
4 Certificate and Certificate Extensions Profile .............. 15
4.1 Basic Certificate Fields .................................. 16
4.1.1 Certificate Fields ...................................... 17
4.1.1.1 tbsCertificate ........................................ 17
4.1.1.2 signatureAlgorithm .................................... 17
4.1.1.3 signatureValue ........................................ 18
4.1.2 TBSCertificate .......................................... 18
4.1.2.1 Version ............................................... 18
4.1.2.2 Serial number ......................................... 19
4.1.2.3 Signature ............................................. 19
4.1.2.4 Issuer ................................................ 19
4.1.2.5 Validity .............................................. 23
4.1.2.5.1 UTCTime ............................................. 23
4.1.2.5.2 GeneralizedTime ..................................... 23
4.1.2.6 Subject ............................................... 24
4.1.2.7 Subject Public Key Info ............................... 25
4.1.2.8 Unique Identifiers .................................... 25
4.1.2.9 Extensions ............................................. 25
4.2 Certificate Extensions .................................... 25
4.2.1 Standard Extensions ..................................... 26
4.2.1.1 Authority Key Identifier .............................. 27
4.2.1.2 Subject Key Identifier ................................ 27
4.2.1.3 Key Usage ............................................. 29
4.2.1.4 Private Key Usage Period .............................. 30
4.2.1.5 Certificate Policies .................................. 31
4.2.1.6 Policy Mappings ....................................... 33
4.2.1.7 Subject Alternative Name .............................. 34
4.2.1.8 Issuer Alternative Name ............................... 36
4.2.1.9 Subject Directory Attributes .......................... 37
4.2.1.10 Basic Constraints .................................... 37
4.2.1.11 Name Constraints ..................................... 38
4.2.1.12 Policy Constraints ................................... 40
4.2.1.13 Extended key usage field ............................. 41
4.2.1.14 CRL Distribution Points .............................. 42
4.2.1.15 Inhibit Any-Policy ................................... 43
4.2.1.16 Freshest CRL ......................................... 43
4.2.2 Internet Certificate Extensions ......................... 44
4.2.2.1 Authority Information Access .......................... 44
4.2.2.2 Subject Information Access ............................ 45
5 CRL and CRL Extensions Profile .............................. 47
5.1 CRL Fields ................................................ 47
5.1.1 CertificateList Fields .................................. 48
5.1.1.1 tbsCertList ........................................... 48
5.1.1.2 signatureAlgorithm .................................... 49
5.1.1.3 signatureValue ........................................ 49
5.1.2 Certificate List "To Be Signed" ......................... 49
5.1.2.1 Version ............................................... 49
5.1.2.2 Signature ............................................. 49
5.1.2.3 Issuer Name ........................................... 50
5.1.2.4 This Update ........................................... 50
5.1.2.5 Next Update ........................................... 50
5.1.2.6 Revoked Certificates .................................. 51
5.1.2.7 Extensions ............................................ 51
5.2 CRL Extensions ............................................ 51
5.2.1 Authority Key Identifier ................................ 51
5.2.2 Issuer Alternative Name ................................. 52
5.2.3 CRL Number .............................................. 52
5.2.4 Delta CRL Indicator ..................................... 52
5.2.5 Issuing Distribution Point .............................. 54
5.2.6 Freshest CRL ............................................ 55
5.3 CRL Entry Extensions ...................................... 55
5.3.1 Reason Code ............................................. 56
5.3.2 Hold Instruction Code ................................... 56
5.3.3 Invalidity Date ......................................... 57
5.3.4 Certificate Issuer ...................................... 57
6 Certificate Path Validation ................................. 58
6.1 Basic Path Validation ..................................... 58
6.1.1 Inputs ................................................... 61
6.1.2 Initialization ........................................... 62
6.1.3 Basic Certificate Processing ............................. 65
6.1.4 Preparation for Certificate i+1 .......................... 70
6.1.5 Wrap-up procedure ........................................ 73
6.1.6 Outputs .................................................. 74
6.2 Extending Path Validation ................................. 75
6.3 CRL Validation ............................................ 75
6.3.1 Revocation Inputs ....................................... 76
6.3.2 Initialization and Revocation State Variables ........... 76
6.3.3 CRL Processing .......................................... 77
7 References .................................................. 79
8 Intellectual Property Rights ................................ 81
9 Security Considerations ..................................... 81
Appendix A. ASN.1 Structures and OIDs ......................... 85
A.1 Explicitly Tagged Module, 1988 Syntax ...................... 85
A.2 Implicitly Tagged Module, 1988 Syntax ...................... 98
Appendix B. ASN.1 Notes ....................................... 105
Appendix C. Examples .......................................... 106
C.1 Certificate ............................................... 107
C.2 Certificate ............................................... 110
C.3 End-Entity Certificate Using RSA .......................... 113
C.4 Certificate Revocation List ............................... 116
Appendix D. Author Addresses .................................. 118
Appendix E. Full Copyright Statement .......................... 118
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Requirements and Assumptions . . . . . . . . . . . . . . . . . . 7
2.1 Communication and Topology . . . . . . . . . . . . . . . . . . 7
2.2 Acceptability Criteria . . . . . . . . . . . . . . . . . . . . 8
2.3 User Expectations . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Administrator Expectations . . . . . . . . . . . . . . . . . . 8
3 Overview of Approach . . . . . . . . . . . . . . . . . . . . . . 8
3.1 X.509 Version 3 Certificate . . . . . . . . . . . . . . . . . . 10
3.2 Certification Paths and Trust . . . . . . . . . . . . . . . . . 11
3.3 Revocation . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4 Operational Protocols . . . . . . . . . . . . . . . . . . . . . 14
3.5 Management Protocols . . . . . . . . . . . . . . . . . . . . . 14
4 Certificate and Certificate Extensions Profile . . . . . . . . . 15
4.1 Basic Certificate Fields . . . . . . . . . . . . . . . . . . . 16
4.1.1 Certificate Fields . . . . . . . . . . . . . . . . . . . . . 17
4.1.1.1 tbsCertificate . . . . . . . . . . . . . . . . . . . . . . 17
4.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . . . . . 17
4.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . . . . . 18
4.1.2 TBSCertificate . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.2.2 Serial number . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.2.3 Signature . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.2.4 Issuer . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.2.5 Validity . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.2.5.1 UTCTime . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.2.5.2 GeneralizedTime . . . . . . . . . . . . . . . . . . . . . 23
4.1.2.6 Subject . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.2.7 Subject Public Key Info . . . . . . . . . . . . . . . . . . 25
4.1.2.8 Unique Identifiers . . . . . . . . . . . . . . . . . . . . 25
4.1.2.9 Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 Certificate Extensions . . . . . . . . . . . . . . . . . . . . 25
4.2.1 Standard Extensions . . . . . . . . . . . . . . . . . . . . . 26
4.2.1.1 Authority Key Identifier . . . . . . . . . . . . . . . . . 27
4.2.1.2 Subject Key Identifier . . . . . . . . . . . . . . . . . . 27
4.2.1.3 Key Usage . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.1.4 Private Key Usage Period . . . . . . . . . . . . . . . . . 30
4.2.1.5 Certificate Policies . . . . . . . . . . . . . . . . . . . 31
4.2.1.6 Policy Mappings . . . . . . . . . . . . . . . . . . . . . . 33
4.2.1.7 Subject Alternative Name . . . . . . . . . . . . . . . . . 34
4.2.1.8 Issuer Alternative Name . . . . . . . . . . . . . . . . . . 36
4.2.1.9 Subject Directory Attributes . . . . . . . . . . . . . . . 37
4.2.1.10 Basic Constraints . . . . . . . . . . . . . . . . . . . . 37
4.2.1.11 Name Constraints . . . . . . . . . . . . . . . . . . . . . 38
4.2.1.12 Policy Constraints . . . . . . . . . . . . . . . . . . . . 40
4.2.1.13 Extended key usage field . . . . . . . . . . . . . . . . . 41
4.2.1.14 CRL Distribution Points . . . . . . . . . . . . . . . . . 42
4.2.1.15 Inhibit Any-Policy . . . . . . . . . . . . . . . . . . . . 43
4.2.1.16 Freshest CRL . . . . . . . . . . . . . . . . . . . . . . . 43
4.2.2 Internet Certificate Extensions . . . . . . . . . . . . . . . 44
4.2.2.1 Authority Information Access . . . . . . . . . . . . . . . 44
4.2.2.2 Subject Information Access . . . . . . . . . . . . . . . . 45
5 CRL and CRL Extensions Profile . . . . . . . . . . . . . . . . . 47
5.1 CRL Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.1.1 CertificateList Fields . . . . . . . . . . . . . . . . . . . 48
5.1.1.1 tbsCertList . . . . . . . . . . . . . . . . . . . . . . . . 48
5.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . . . . . 49
5.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . . . . . 49
5.1.2 Certificate List "To Be Signed" . . . . . . . . . . . . . . . 49
5.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1.2.2 Signature . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1.2.3 Issuer Name . . . . . . . . . . . . . . . . . . . . . . . . 50
5.1.2.4 This Update . . . . . . . . . . . . . . . . . . . . . . . . 50
5.1.2.5 Next Update . . . . . . . . . . . . . . . . . . . . . . . . 50
5.1.2.6 Revoked Certificates . . . . . . . . . . . . . . . . . . . 51
5.1.2.7 Extensions . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2 CRL Extensions . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2.1 Authority Key Identifier . . . . . . . . . . . . . . . . . . 51
5.2.2 Issuer Alternative Name . . . . . . . . . . . . . . . . . . . 52
5.2.3 CRL Number . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2.4 Delta CRL Indicator . . . . . . . . . . . . . . . . . . . . . 52
5.2.5 Issuing Distribution Point . . . . . . . . . . . . . . . . . 54
5.2.6 Freshest CRL . . . . . . . . . . . . . . . . . . . . . . . . 55
5.3 CRL Entry Extensions . . . . . . . . . . . . . . . . . . . . . 55
5.3.1 Reason Code . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.3.2 Hold Instruction Code . . . . . . . . . . . . . . . . . . . . 56
5.3.3 Invalidity Date . . . . . . . . . . . . . . . . . . . . . . . 57
5.3.4 Certificate Issuer . . . . . . . . . . . . . . . . . . . . . 57
6 Certificate Path Validation . . . . . . . . . . . . . . . . . . . 58
6.1 Basic Path Validation . . . . . . . . . . . . . . . . . . . . . 58
6.1.1 Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.1.2 Initialization . . . . . . . . . . . . . . . . . . . . . . . . 62
6.1.3 Basic Certificate Processing . . . . . . . . . . . . . . . . . 65
6.1.4 Preparation for Certificate i+1 . . . . . . . . . . . . . . . 70
6.1.5 Wrap-up procedure . . . . . . . . . . . . . . . . . . . . . . 73
6.1.6 Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.2 Extending Path Validation . . . . . . . . . . . . . . . . . . . 75
6.3 CRL Validation . . . . . . . . . . . . . . . . . . . . . . . . 75
6.3.1 Revocation Inputs . . . . . . . . . . . . . . . . . . . . . . 76
6.3.2 Initialization and Revocation State Variables . . . . . . . . 76
6.3.3 CRL Processing . . . . . . . . . . . . . . . . . . . . . . . 77
7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
8 Intellectual Property Rights . . . . . . . . . . . . . . . . . . 81
9 Security Considerations . . . . . . . . . . . . . . . . . . . . . 81
Appendix A. ASN.1 Structures and OIDs . . . . . . . . . . . . . . . 85
A.1 Explicitly Tagged Module, 1988 Syntax . . . . . . . . . . . . . 85
A.2 Implicitly Tagged Module, 1988 Syntax . . . . . . . . . . . . . 98
Appendix B. ASN.1 Notes . . . . . . . . . . . . . . . . . . . . . . 105
Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . . 106
C.1 Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . 107
C.2 Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . 110
C.3 End-Entity Certificate Using RSA . . . . . . . . . . . . . . . 113
C.4 Certificate Revocation List . . . . . . . . . . . . . . . . . . 116
Appendix D. Author Addresses . . . . . . . . . . . . . . . . . . . 118
Appendix E. Full Copyright Statement . . . . . . . . . . . . . . . 118
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 6, line 29 skipping to change at page 6, line 28
The specification describes the requirements which inspire the The specification describes the requirements which inspire the
creation of this document and the assumptions which affect its scope creation of this document and the assumptions which affect its scope
in Section 2. Section 3 presents an architectural model and in Section 2. Section 3 presents an architectural model and
describes its relationship to previous IETF and ISO/IEC/ITU describes its relationship to previous IETF and ISO/IEC/ITU
standards. In particular, this document's relationship with the IETF standards. In particular, this document's relationship with the IETF
PEM specifications and the ISO/IEC/ITU X.509 documents are described. PEM specifications and the ISO/IEC/ITU X.509 documents are described.
The specification profiles the X.509 version 3 certificate in Section The specification profiles the X.509 version 3 certificate in Section
4, and the X.509 version 2 certificate revocation list (CRL) in 4, and the X.509 version 2 certificate revocation list (CRL) in
Section 5. The profiles include the identification of ISO/IEC/ITU Section 5. The profiles include the identification of ISO/IEC/ITU
and ANSI extensions which may be useful in the Internet PKI. The and ANSI extensions which may be useful in the Internet PKI. The
profiles are presented in the 1988 Abstract Syntax Notation One profiles are presented in the 1988 Abstract Syntax Notation One
(ASN.1) rather than the 1994 syntax used in the ISO/IEC/ITU (ASN.1) rather than the 1994 syntax used in the ISO/IEC/ITU
standards. standards.
This specification also includes path validation procedures in This specification also includes path validation procedures in
Section 6. These procedures are based upon the ISO/IEC/ITU Section 6. These procedures are based upon the ISO/IEC/ITU
definition, but the presentation assumes one or more self-signed definition, but the presentation assumes one or more self-signed
trusted CA certificates. Implementations are required to derive the trusted CA certificates. Implementations are required to derive the
same results but are not required to use the specified procedures. same results but are not required to use the specified procedures.
skipping to change at page 7, line 11 skipping to change at page 7, line 11
specification. As above, the material is presented in the 1988 specification. As above, the material is presented in the 1988
Abstract Syntax Notation One (ASN.1) rather than the 1994 syntax. Abstract Syntax Notation One (ASN.1) rather than the 1994 syntax.
Appendix B contains notes on less familiar features of the ASN.1 Appendix B contains notes on less familiar features of the ASN.1
notation used within this specification. Appendix C contains notation used within this specification. Appendix C contains
examples of a conforming certificate and a conforming CRL. examples of a conforming certificate and a conforming CRL.
2 Requirements and Assumptions 2 Requirements and Assumptions
The goal of this specification is to develop a profile to facilitate The goal of this specification is to develop a profile to facilitate
the use of X.509 certificates within Internet applications for those the use of X.509 certificates within Internet applications for those
communities wishing to make use of X.509 technology. Such communities wishing to make use of X.509 technology. Such
applications may include WWW, electronic mail, user authentication, applications may include WWW, electronic mail, user authentication,
and IPsec. In order to relieve some of the obstacles to using X.509 and IPsec. In order to relieve some of the obstacles to using X.509
certificates, this document defines a profile to promote the certificates, this document defines a profile to promote the
development of certificate management systems; development of development of certificate management systems; development of
application tools; and interoperability determined by policy. application tools; and interoperability determined by policy.
Some communities will need to supplement, or possibly replace, this Some communities will need to supplement, or possibly replace, this
profile in order to meet the requirements of specialized application profile in order to meet the requirements of specialized application
domains or environments with additional authorization, assurance, or domains or environments with additional authorization, assurance, or
operational requirements. However, for basic applications, common operational requirements. However, for basic applications, common
skipping to change at page 8, line 9 skipping to change at page 8, line 9
This profile does not assume the deployment of an X.500 Directory This profile does not assume the deployment of an X.500 Directory
system. The profile does not prohibit the use of an X.500 Directory, system. The profile does not prohibit the use of an X.500 Directory,
but other means of distributing certificates and certificate but other means of distributing certificates and certificate
revocation lists (CRLs) may be used. revocation lists (CRLs) may be used.
2.2 Acceptability Criteria 2.2 Acceptability Criteria
The goal of the Internet Public Key Infrastructure (PKI) is to meet The goal of the Internet Public Key Infrastructure (PKI) is to meet
the needs of deterministic, automated identification, authentication, the needs of deterministic, automated identification, authentication,
access control, and authorization functions. Support for these access control, and authorization functions. Support for these
services determines the attributes contained in the certificate as services determines the attributes contained in the certificate as
well as the ancillary control information in the certificate such as well as the ancillary control information in the certificate such as
policy data and certification path constraints. policy data and certification path constraints.
2.3 User Expectations 2.3 User Expectations
Users of the Internet PKI are people and processes who use client Users of the Internet PKI are people and processes who use client
software and are the subjects named in certificates. These uses software and are the subjects named in certificates. These uses
include readers and writers of electronic mail, the clients for WWW include readers and writers of electronic mail, the clients for WWW
browsers, WWW servers, and the key manager for IPsec within a router. browsers, WWW servers, and the key manager for IPsec within a router.
skipping to change at page 8, line 34 skipping to change at page 8, line 34
platform usage constraints within the certificate, certification path platform usage constraints within the certificate, certification path
constraints which shield the user from many malicious actions, and constraints which shield the user from many malicious actions, and
applications which sensibly automate validation functions. applications which sensibly automate validation functions.
2.4 Administrator Expectations 2.4 Administrator Expectations
As with user expectations, the Internet PKI profile is structured to As with user expectations, the Internet PKI profile is structured to
support the individuals who generally operate CAs. Providing support the individuals who generally operate CAs. Providing
administrators with unbounded choices increases the chances that a administrators with unbounded choices increases the chances that a
subtle CA administrator mistake will result in broad compromise. subtle CA administrator mistake will result in broad compromise.
Also, unbounded choices greatly complicate the software that shall Also, unbounded choices greatly complicate the software that process
process and validate the certificates created by the CA. and validate the certificates created by the CA.
3 Overview of Approach 3 Overview of Approach
Following is a simplified view of the architectural model assumed by Following is a simplified view of the architectural model assumed by
the PKIX specifications. the PKIX specifications.
+---+ +---+
| C | +------------+ | C | +------------+
| e | <-------------------->| End entity | | e | <-------------------->| End entity |
| r | Operational +------------+ | r | Operational +------------+
skipping to change at page 10, line 25 skipping to change at page 10, line 25
response protocol), presentation of the private key, or on an response protocol), presentation of the private key, or on an
assertion by the subject. A certificate has a limited valid lifetime assertion by the subject. A certificate has a limited valid lifetime
which is indicated in its signed contents. Because a certificate's which is indicated in its signed contents. Because a certificate's
signature and timeliness can be independently checked by a signature and timeliness can be independently checked by a
certificate-using client, certificates can be distributed via certificate-using client, certificates can be distributed via
untrusted communications and server systems, and can be cached in untrusted communications and server systems, and can be cached in
unsecured storage in certificate-using systems. unsecured storage in certificate-using systems.
ITU-T X.509 (formerly CCITT X.509) or ISO/IEC/ITU 9594-8, which was ITU-T X.509 (formerly CCITT X.509) or ISO/IEC/ITU 9594-8, which was
first published in 1988 as part of the X.500 Directory first published in 1988 as part of the X.500 Directory
recommendations, defines a standard certificate format [X.509]. The recommendations, defines a standard certificate format [X.509]. The
certificate format in the 1988 standard is called the version 1 (v1) certificate format in the 1988 standard is called the version 1 (v1)
format. When X.500 was revised in 1993, two more fields were added, format. When X.500 was revised in 1993, two more fields were added,
resulting in the version 2 (v2) format. resulting in the version 2 (v2) format.
The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993, The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993,
include specifications for a public key infrastructure based on X.509 include specifications for a public key infrastructure based on X.509
v1 certificates [RFC 1422]. The experience gained in attempts to v1 certificates [RFC 1422]. The experience gained in attempts to
deploy RFC 1422 made it clear that the v1 and v2 certificate formats deploy RFC 1422 made it clear that the v1 and v2 certificate formats
are deficient in several respects. Most importantly, more fields are deficient in several respects. Most importantly, more fields
were needed to carry information which PEM design and implementation were needed to carry information which PEM design and implementation
experience has proven necessary. In response to these new experience has proven necessary. In response to these new
requirements, ISO/IEC/ITU and ANSI X9 developed the X.509 version 3 requirements, ISO/IEC/ITU and ANSI X9 developed the X.509 version 3
(v3) certificate format. The v3 format extends the v2 format by (v3) certificate format. The v3 format extends the v2 format by
adding provision for additional extension fields. Particular adding provision for additional extension fields. Particular
extension field types may be specified in standards or may be defined extension field types may be specified in standards or may be defined
and registered by any organization or community. In June 1996, and registered by any organization or community. In June 1996,
standardization of the basic v3 format was completed [X.509]. standardization of the basic v3 format was completed [X.509].
ISO/IEC/ITU and ANSI X9 have also developed standard extensions for ISO/IEC/ITU and ANSI X9 have also developed standard extensions for
use in the v3 extensions field [X.509][X9.55]. These extensions can use in the v3 extensions field [X.509][X9.55]. These extensions can
convey such data as additional subject identification information, convey such data as additional subject identification information,
key attribute information, policy information, and certification path key attribute information, policy information, and certification path
constraints. constraints.
However, the ISO/IEC/ITU and ANSI X9 standard extensions are very However, the ISO/IEC/ITU and ANSI X9 standard extensions are very
broad in their applicability. In order to develop interoperable broad in their applicability. In order to develop interoperable
skipping to change at page 11, line 40 skipping to change at page 11, line 40
(a) Internet Policy Registration Authority (IPRA): This (a) Internet Policy Registration Authority (IPRA): This
authority, operated under the auspices of the Internet Society, authority, operated under the auspices of the Internet Society,
acts as the root of the PEM certification hierarchy at level 1. acts as the root of the PEM certification hierarchy at level 1.
It issues certificates only for the next level of authorities, It issues certificates only for the next level of authorities,
PCAs. All certification paths start with the IPRA. PCAs. All certification paths start with the IPRA.
(b) Policy Certification Authorities (PCAs): PCAs are at level 2 (b) Policy Certification Authorities (PCAs): PCAs are at level 2
of the hierarchy, each PCA being certified by the IPRA. A PCA of the hierarchy, each PCA being certified by the IPRA. A PCA
shall establish and publish a statement of its policy with respect shall establish and publish a statement of its policy with respect
to certifying users or subordinate certification authorities. to certifying users or subordinate certification authorities.
Distinct PCAs aim to satisfy different user needs. For example, Distinct PCAs aim to satisfy different user needs. For example,
one PCA (an organizational PCA) might support the general one PCA (an organizational PCA) might support the general
electronic mail needs of commercial organizations, and another PCA electronic mail needs of commercial organizations, and another PCA
(a high-assurance PCA) might have a more stringent policy designed (a high-assurance PCA) might have a more stringent policy designed
for satisfying legally binding digital signature requirements. for satisfying legally binding digital signature requirements.
(c) Certification Authorities (CAs): CAs are at level 3 of the (c) Certification Authorities (CAs): CAs are at level 3 of the
hierarchy and can also be at lower levels. Those at level 3 are hierarchy and can also be at lower levels. Those at level 3 are
certified by PCAs. CAs represent, for example, particular certified by PCAs. CAs represent, for example, particular
organizations, particular organizational units (e.g., departments, organizations, particular organizational units (e.g., departments,
groups, sections), or particular geographical areas. groups, sections), or particular geographical areas.
RFC 1422 furthermore has a name subordination rule which requires RFC 1422 furthermore has a name subordination rule which requires
that a CA can only issue certificates for entities whose names are that a CA can only issue certificates for entities whose names are
subordinate (in the X.500 naming tree) to the name of the CA itself. subordinate (in the X.500 naming tree) to the name of the CA itself.
The trust associated with a PEM certification path is implied by the The trust associated with a PEM certification path is implied by the
PCA name. The name subordination rule ensures that CAs below the PCA PCA name. The name subordination rule ensures that CAs below the PCA
are sensibly constrained as to the set of subordinate entities they are sensibly constrained as to the set of subordinate entities they
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;
skipping to change at page 13, line 13 skipping to change at page 13, line 13
application can determine if the certification path is acceptable application can determine if the certification path is acceptable
based on the contents of the certificates instead of a priori based on the contents of the certificates instead of a priori
knowledge of PCAs. This permits automation of certificate chain knowledge of PCAs. This permits automation of certificate chain
processing. 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
circumstances, the CA needs to revoke the certificate. circumstances, the CA needs to revoke the certificate.
X.509 defines one method of certificate revocation. This method X.509 defines one method of certificate revocation. This method
involves each CA periodically issuing a signed data structure called involves each CA periodically issuing a signed data structure called
a certificate revocation list (CRL). A CRL is a time stamped list a certificate revocation list (CRL). A CRL is a time stamped list
identifying revoked certificates which is signed by a CA and made identifying revoked certificates which is signed by a CA and made
freely available in a public repository. Each revoked certificate is freely available in a public repository. Each revoked certificate is
identified in a CRL by its certificate serial number. When a identified in a CRL by its certificate serial number. When a
certificate-using system uses a certificate (e.g., for verifying a certificate-using system uses a certificate (e.g., for verifying a
remote user's digital signature), that system not only checks the remote user's digital signature), that system not only checks the
certificate signature and validity but also acquires a suitably- certificate signature and validity but also acquires a suitably-
recent CRL and checks that the certificate serial number is not on recent CRL and checks that the certificate serial number is not on
that CRL. The meaning of "suitably-recent" may vary with local that CRL. The meaning of "suitably-recent" may vary with local
policy, but it usually means the most recently-issued CRL. A CA policy, but it usually means the most recently-issued CRL. A CA
issues a new CRL on a regular periodic basis (e.g., hourly, daily, or issues a new CRL on a regular periodic basis (e.g., hourly, daily, or
weekly). An entry is added to the CRL as part of the next update weekly). An entry is added to the CRL as part of the next update
following notification of revocation. An entry may be removed from following notification of revocation. An entry may be removed from
the CRL after appearing on one regularly scheduled CRL issued beyond the CRL after appearing on one regularly scheduled CRL issued beyond
skipping to change at page 14, line 5 skipping to change at page 14, line 5
revocation is limited to the CRL issue period. For example, if a revocation is limited to the CRL issue period. For example, if a
revocation is reported now, that revocation will not be reliably revocation is reported now, that revocation will not be reliably
notified to certificate-using systems until all currently issued CRLs notified to certificate-using systems until all currently issued CRLs
are updated -- this may be up to one hour, one day, or one week are updated -- this may be up to one hour, one day, or one week
depending on the frequency that the CA issues CRLs. depending on the frequency that the CA issues CRLs.
As with the X.509 v3 certificate format, in order to facilitate As with the X.509 v3 certificate format, in order to facilitate
interoperable implementations from multiple vendors, the X.509 v2 CRL interoperable implementations from multiple vendors, the X.509 v2 CRL
format needs to be profiled for Internet use. It is one goal of this format needs to be profiled for Internet use. It is one goal of this
document to specify that profile. However, this profile does not document to specify that profile. However, this profile does not
require CAs to issue CRLs. Message formats and protocols supporting require CAs to issue CRLs. Message formats and protocols supporting
on-line revocation notification may be defined in other PKIX on-line revocation notification may be defined in other PKIX
specifications. On-line methods of revocation notification may be specifications. On-line methods of revocation notification may be
applicable in some environments as an alternative to the X.509 CRL. applicable in some environments as an alternative to the X.509 CRL.
On-line revocation checking may significantly reduce the latency On-line revocation checking may significantly reduce the latency
between a revocation report and the distribution of the information between a revocation report and the distribution of the information
to relying parties. Once the CA accepts the report as authentic and to relying parties. Once the CA accepts the report as authentic and
valid, any query to the on-line service will correctly reflect the valid, any query to the on-line service will correctly reflect the
certificate validation impacts of the revocation. However, these certificate validation impacts of the revocation. However, these
methods impose new security requirements: the certificate validator methods impose new security requirements: the certificate validator
needs to trust the on-line validation service while the repository needs to trust the on-line validation service while the repository
skipping to change at page 16, line 36 skipping to change at page 16, line 36
TBSCertificate ::= SEQUENCE { TBSCertificate ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1, version [0] EXPLICIT Version DEFAULT v1,
serialNumber CertificateSerialNumber, serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier, signature AlgorithmIdentifier,
issuer Name, issuer Name,
validity Validity, validity Validity,
subject Name, subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo, subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version shall be v2 or v3 -- If present, version MUST be v2 or v3
subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version shall be v2 or v3 -- If present, version MUST be v2 or v3
extensions [3] EXPLICIT Extensions OPTIONAL extensions [3] EXPLICIT Extensions OPTIONAL
-- If present, version shall be v3 -- If present, version MUST be v3
} }
Version ::= INTEGER { v1(0), v2(1), v3(2) } Version ::= INTEGER { v1(0), v2(1), v3(2) }
CertificateSerialNumber ::= INTEGER CertificateSerialNumber ::= INTEGER
Validity ::= SEQUENCE { Validity ::= SEQUENCE {
notBefore Time, notBefore Time,
notAfter Time } notAfter Time }
skipping to change at page 23, line 14 skipping to change at page 23, line 14
in distinguished names are irrelevant. The characters themselves are in distinguished names are irrelevant. The characters themselves are
compared without regard to encoding. Implementations of the profile compared without regard to encoding. Implementations of the profile
are permitted to use the comparison algorithm defined in the X.500 are permitted to use the comparison algorithm defined in the X.500
series. Such an implementation will recognize a superset of name series. Such an implementation will recognize a superset of name
matches recognized by the algorithm specified above. matches recognized by the algorithm specified above.
4.1.2.5 Validity 4.1.2.5 Validity
The certificate validity period is the time interval during which the The certificate validity period is the time interval during which the
CA warrants that it will maintain information about the status of the CA warrants that it will maintain information about the status of the
certificate. The field is represented as a SEQUENCE of two dates: certificate. The field is represented as a SEQUENCE of two dates: the
the date on which the certificate validity period begins (notBefore) date on which the certificate validity period begins (notBefore) and
and the date on which the certificate validity period ends the date on which the certificate validity period ends (notAfter).
(notAfter). Both notBefore and notAfter may be encoded as UTCTime or Both notBefore and notAfter may be encoded as UTCTime or
GeneralizedTime. GeneralizedTime.
CAs conforming to this profile MUST always encode certificate CAs conforming to this profile MUST always encode certificate
validity dates through the year 2049 as UTCTime; certificate validity validity dates through the year 2049 as UTCTime; certificate validity
dates in 2050 or later MUST be encoded as GeneralizedTime. dates in 2050 or later MUST be encoded as GeneralizedTime.
The validity period for a certificate is the period of time from The validity period for a certificate is the period of time from
notBefore through notAfter, inclusive. notBefore through notAfter, inclusive.
4.1.2.5.1 UTCTime 4.1.2.5.1 UTCTime
skipping to change at page 23, line 40 skipping to change at page 23, line 40
for representation of dates and time. UTCTime specifies the year for representation of dates and time. UTCTime specifies the year
through the two low order digits and time is specified to the through the two low order digits and time is specified to the
precision of one minute or one second. UTCTime includes either Z precision of one minute or one second. UTCTime includes either Z
(for Zulu, or Greenwich Mean Time) or a time differential. (for Zulu, or Greenwich Mean Time) or a time differential.
For the purposes of this profile, UTCTime values MUST be expressed For the purposes of this profile, UTCTime values MUST be expressed
Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are
YYMMDDHHMMSSZ), even where the number of seconds is zero. Conforming YYMMDDHHMMSSZ), even where the number of seconds is zero. Conforming
systems MUST interpret the year field (YY) as follows: systems MUST interpret the year field (YY) as follows:
Where YY is greater than or equal to 50, the year shall be Where YY is greater than or equal to 50, the year SHALL be
interpreted as 19YY; and interpreted as 19YY; and
Where YY is less than 50, the year shall be interpreted as 20YY. Where YY is less than 50, the year SHALL be interpreted as 20YY.
4.1.2.5.2 GeneralizedTime 4.1.2.5.2 GeneralizedTime
The generalized time type, GeneralizedTime, is a standard ASN.1 type The generalized time type, GeneralizedTime, is a standard ASN.1 type
for variable precision representation of time. Optionally, the for variable precision representation of time. Optionally, the
GeneralizedTime field can include a representation of the time GeneralizedTime field can include a representation of the time
differential between local and Greenwich Mean Time. differential between local and Greenwich Mean Time.
For the purposes of this profile, GeneralizedTime values MUST be For the purposes of this profile, GeneralizedTime values MUST be
expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e., expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e.,
skipping to change at page 25, line 25 skipping to change at page 25, line 25
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. The algorithm is identified using the
AlgorithmIdentifier structure specified in section 4.1.1.2. The AlgorithmIdentifier structure specified in section 4.1.1.2. The
object identifiers for the supported algorithms and the methods for object identifiers for the supported algorithms and the methods for
encoding the public key materials (public key and parameters) are encoding the public key materials (public key and parameters) are
specified in [PKIX ALGS]. specified in [PKIX ALGS].
4.1.2.8 Unique Identifiers 4.1.2.8 Unique Identifiers
These fields may only appear if the version is 2 or 3 (see sec. These fields may only appear if the version is 2 or 3 (see sec.
4.1.2.1). The subject and issuer unique identifiers are present in 4.1.2.1). These fields MUST NOT appear if the version is 1. The
the certificate to handle the possibility of reuse of subject and/or subject and issuer unique identifiers are present in the certificate
issuer names over time. This profile recommends that names not be to handle the possibility of reuse of subject and/or issuer names
reused for different entities and that Internet certificates not make over time. This profile RECOMMENDS that names not be reused for
use of unique identifiers. CAs conforming to this profile SHOULD NOT different entities and that Internet certificates not make use of
unique identifiers. CAs conforming to this profile SHOULD NOT
generate certificates with unique identifiers. Applications generate certificates with unique identifiers. Applications
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 may only appear if the version is 3 (see sec. 4.1.2.1). This field may only appear if the version is 3 (see sec. 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 Standard 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 may be designated as critical or non-critical. A certificate may be designated as critical or non-critical. A
skipping to change at page 26, line 32 skipping to change at page 26, line 33
4.2.1.3), and certificate policies (see sec. 4.2.1.5) extensions. If 4.2.1.3), and certificate policies (see sec. 4.2.1.5) extensions. If
the CA issues certificates with an empty sequence for the subject the CA issues certificates with an empty sequence for the subject
field, the CA MUST support the subject alternative name extension field, the CA MUST support the subject alternative name extension
(see sec. 4.2.1.7). Support for the remaining extensions is (see sec. 4.2.1.7). Support for the remaining extensions is
OPTIONAL. Conforming CAs may support extensions that are not OPTIONAL. Conforming CAs may support extensions that are not
identified within this specification; certificate issuers are identified within this specification; certificate issuers are
cautioned that marking such extensions as critical may inhibit cautioned that marking such extensions as critical may inhibit
interoperability. interoperability.
At a minimum, applications conforming to this profile MUST recognize At a minimum, applications conforming to this profile MUST recognize
the following extensions: key usage (see sec. 4.2.1.3), certificate the following extensions: key usage (see sec. 4.2.1.3), certificate
policies (see sec. 4.2.1.5), the subject alternative name (see sec. policies (see sec. 4.2.1.5), the subject alternative name (see sec.
4.2.1.7), basic constraints (see sec. 4.2.1.10), name constraints 4.2.1.7), basic constraints (see sec. 4.2.1.10), name constraints
(see sec. 4.2.1.11), policy constraints (see sec. 4.2.1.12), extended (see sec. 4.2.1.11), policy constraints (see sec. 4.2.1.12), extended
key usage (see sec. 4.2.1.13), and inhibit any-policy (see sec. key usage (see sec. 4.2.1.13), and inhibit any-policy (see sec.
4.2.1.15). 4.2.1.15).
In addition, this profile RECOMMENDS application support for the In addition, this profile RECOMMENDS application support for the
authority and subject key identifier (see sec. 4.2.1.1 and 4.2.1.2), authority and subject key identifier (see sec. 4.2.1.1 and 4.2.1.2),
and policy mapping (see sec. 4.2.1.6) extensions. and policy mapping (see sec. 4.2.1.6) extensions.
skipping to change at page 30, line 4 skipping to change at page 30, line 4
falsely denying some action, excluding certificate or CRL signing. falsely denying some action, excluding certificate or CRL signing.
In the case of later conflict, a reliable third party may In the case of later conflict, a reliable third party may
determine the authenticity of the signed data. determine the authenticity of the signed data.
Further distinctions between the digitalSignature and Further distinctions between the digitalSignature and
nonRepudiation bits may be provided in specific certificate nonRepudiation bits may be provided in specific certificate
policies. policies.
The keyEncipherment bit is asserted when the subject public key is The keyEncipherment bit is asserted when the subject public key is
used for key transport. For example, when an RSA key is to be used for key transport. For example, when an RSA key is to be
used for key management, then this bit shall asserted. used for key management, then this bit is set.
The dataEncipherment bit is asserted when the subject public key The dataEncipherment bit is asserted when the subject public key
is used for enciphering user data, other than cryptographic keys. is used for enciphering user data, other than cryptographic keys.
The keyAgreement bit is asserted when the subject public key is The keyAgreement bit is asserted when the subject public key is
used for key agreement. For example, when a Diffie-Hellman key is used for key agreement. For example, when a Diffie-Hellman key is
to be used for key management, then this bit shall asserted. to be used for key management, then this bit is set.
The keyCertSign bit is asserted when the subject public key is The keyCertSign bit is asserted when the subject public key is
used for verifying a signature on certificates. This bit may only used for verifying a signature on certificates. This bit may only
be asserted in CA certificates. If the keyCertSign bit is be asserted in CA certificates. If the keyCertSign bit is
asserted, then the cA bit in the basic constraints extension (see asserted, then the cA bit in the basic constraints extension (see
4.2.1.10) MUST also be asserted. If the keyCertSign bit is not 4.2.1.10) MUST also be asserted. If neither the cRLSign bit nor
asserted, then the cA bit in the basic constraints extension MUST the keyCertSign bit are asserted, then the cA bit in the basic
NOT be asserted. constraints extension MUST NOT be asserted.
The cRLSign bit is asserted when the subject public key is used The cRLSign bit is asserted when the subject public key is used
for verifying a signature on revocation information (e.g., a CRL). for verifying a signature on revocation information (e.g., a CRL).
This bit may only be asserted in CA certificates. If the cRLSign
bit is asserted, then the cA bit in the basic constraints
extension (see 4.2.1.10) MUST also be asserted. If neither the
cRLSign bit nor the keyCertSign bit are asserted, then the cA bit
in the basic constraints extension MUST NOT be asserted.
The meaning of the encipherOnly bit is undefined in the absence of The meaning of the encipherOnly bit is undefined in the absence of
the keyAgreement bit. When the encipherOnly bit is asserted and the keyAgreement bit. When the encipherOnly bit is asserted and
the keyAgreement bit is also set, the subject public key may be the keyAgreement bit is also set, the subject public key may be
used only for enciphering data while performing key agreement. used only for enciphering data while performing key agreement.
The meaning of the decipherOnly bit is undefined in the absence of The meaning of the decipherOnly bit is undefined in the absence of
the keyAgreement bit. When the decipherOnly bit is asserted and the keyAgreement bit. When the decipherOnly bit is asserted and
the keyAgreement bit is also set, the subject public key may be the keyAgreement bit is also set, the subject public key may be
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 [PKIX ALGS]. are specified in [PKIX ALGS].
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 with
critical private key usage period extensions. critical private key usage period extensions.
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
skipping to change at page 31, line 30 skipping to change at page 31, line 35
The certificate policies extension contains a sequence of one or more The certificate policies extension contains a sequence of one or more
policy information terms, each of which consists of an object policy information terms, each of which consists of an object
identifier (OID) and optional qualifiers. Optional qualifiers, which identifier (OID) and optional qualifiers. Optional qualifiers, which
may be present, are not expected to change the definition of the may be present, are not expected to change the definition of the
policy. policy.
In an end-entity certificate, these policy information terms indicate In an end-entity certificate, these policy information terms indicate
the policy under which the certificate has been issued and the the policy under which the certificate has been issued and the
purposes for which the certificate may be used. In a CA certificate, purposes for which the certificate may be used. In a CA certificate,
these policy information terms limit the set of policies for these policy information terms limit the set of policies for
certification paths which include this certificate. When a CA does certification paths which include this certificate. When a CA does
not wish to limit the set of policies for certification paths which not wish to limit the set of policies for certification paths which
include this certificate, they may assert the special policy include this certificate, they may assert the special policy
anyPolicy, with a value of {2 5 29 32 0}. anyPolicy, with a value of {2 5 29 32 0}.
Applications with specific policy requirements are expected to have a Applications with specific policy requirements are expected to have a
list of those policies which they will accept and to compare the list of those policies which they will accept and to compare the
policy OIDs in the certificate to that list. If this extension is policy OIDs in the certificate to that list. If this extension is
critical, the path validation software MUST be able to interpret this critical, the path validation software MUST be able to interpret this
extension (including the optional qualifier), or MUST reject the extension (including the optional qualifier), or MUST reject the
certificate. certificate.
skipping to change at page 34, line 39 skipping to change at page 34, line 47
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
MUST contain exactly four octets. For IP Version 6, as specified in MUST contain exactly four octets. For IP Version 6, as specified in
RFC 1883, the octet string MUST contain exactly sixteen octets [RFC RFC 1883, the octet string MUST contain exactly sixteen octets [RFC
1883]. 1883].
skipping to change at page 35, line 35 skipping to change at page 35, line 42
stored in the uniformResourceIdentifier (an IA5String). The name MUST stored in the uniformResourceIdentifier (an IA5String). The name MUST
be a non-relative URL, and MUST follow the URL syntax and encoding be a non-relative URL, and MUST follow the URL syntax and encoding
rules specified in [RFC 1738]. The name must include both a scheme rules specified in [RFC 1738]. The name must include both a scheme
(e.g., "http" or "ftp") and a scheme-specific-part. The scheme- (e.g., "http" or "ftp") and a scheme-specific-part. The scheme-
specific-part must include a fully qualified domain name or IP specific-part must include a fully qualified domain name or IP
address as the host. address as the host.
As specified in [RFC 1738], the scheme name is not case-sensitive As specified in [RFC 1738], the scheme name is not case-sensitive
(e.g., "http" is equivalent to "HTTP"). The host part is also not (e.g., "http" is equivalent to "HTTP"). The host part is also not
case-sensitive, but other components of the scheme-specific-part may case-sensitive, but other components of the scheme-specific-part may
be case-sensitive. When comparing URIs, conforming implementations be case-sensitive. When comparing URIs, conforming implementations
MUST compare the scheme and host without regard to case, but assume MUST compare the scheme and host without regard to case, but assume
the remainder of the scheme-specific-part is case sensitive. the remainder of the scheme-specific-part is case sensitive.
When the subjectAltName extension contains a DN in the directoryName, When the subjectAltName extension contains a DN in the directoryName,
the DN MUST be unique for each subject entity certified by the one CA the DN MUST be unique for each subject entity certified by the one CA
as defined by the issuer name field. A CA may issue more than one as defined by the issuer name field. A CA may issue more than one
certificate with the same DN to the same subject entity. certificate with the same DN to the same subject entity.
The subjectAltName may carry additional name types through the use of The subjectAltName may carry additional name types through the use of
the otherName field. The format and semantics of the name are the otherName field. The format and semantics of the name are
skipping to change at page 36, line 21 skipping to change at page 36, line 27
NOT issue certificates with subjectAltNames containing empty NOT issue certificates with subjectAltNames containing empty
GeneralName fields. For example, an rfc822Name is represented as an GeneralName fields. For example, an rfc822Name is represented as an
IA5String. While an empty string is a valid IA5String, such an IA5String. While an empty string is a valid IA5String, such an
rfc822Name is not permitted by this profile. The behavior of clients rfc822Name is not permitted by this profile. The behavior of clients
that encounter such a certificate when processing a certificication that encounter such a certificate when processing a certificication
path is not defined by this profile. path is not defined by this profile.
Finally, the semantics of subject alternative names that include Finally, the semantics of subject alternative names that include
wildcard characters (e.g., as a placeholder for a set of names) are wildcard characters (e.g., as a placeholder for a set of names) are
not addressed by this specification. Applications with specific not addressed by this specification. Applications with specific
requirements may use such names but shall define the semantics. requirements may use such names but MUST define the semantics.
id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 }
SubjectAltName ::= GeneralNames SubjectAltName ::= GeneralNames
GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
GeneralName ::= CHOICE { GeneralName ::= CHOICE {
otherName [0] OtherName, otherName [0] OtherName,
rfc822Name [1] IA5String, rfc822Name [1] IA5String,
skipping to change at page 37, line 30 skipping to change at page 37, line 37
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 how deep a certification path may exist certificate is a CA and how deep a certification path may exist
through that CA. through that CA.
The cA bit indicates if the certified public key may be used to The cA bit indicates if the certified public key may be used to
verify signatures on other certificates. If the cA bit is asserted, verify signatures on other certificates. If the cA bit is asserted,
then the keyCertSign bit in the key usage extension (see 4.2.1.3) then either the keyCertSign bit or the cRLSign bit in the key usage
MUST also be asserted. If the cA bit is not asserted, then the extension (see 4.2.1.3) MUST also be asserted. If the cA bit is not
keyCertSign bit in the key usage extension MUST NOT be asserted. asserted, then both the keyCertSign bit and the cRLSign in the key
usage extension MUST NOT be asserted.
The pathLenConstraint field is meaningful only if cA is set to TRUE. The pathLenConstraint field is meaningful only if cA is set to TRUE.
In this case, it gives the maximum number of CA certificates that may In this case, it gives the maximum number of CA certificates that may
follow this certificate in a certification path. (Note: The last follow this certificate in a certification path. (Note: The last
certificate may be an end-entity certificate or a CA certificate. certificate in the certification path is not included in this limit.
The cA bit, or its absence, determines the type of the last Usually, the last certificate is an end-entity certificate, but it
certificate rather than the application.) A pathLenConstraint of can be a CA certificate.) A pathLenConstraint of zero indicates that
zero indicates that only an end-entity certificate may follow in the only one more certificate may follow in the certification path.
path. Where it appears, the pathLenConstraint field MUST be greater Where it appears, the pathLenConstraint field MUST be greater than or
than or equal to zero. Where pathLenConstraint does not appear, there equal to zero. Where pathLenConstraint does not appear, there is no
is no limit to the allowed length of the certification path. limit to the allowed length of the certification path.
This extension MUST appear as a critical extension in all CA This extension MUST appear as a critical extension in all CA
certificates. This extension MAY appear as a critical or non- certificates. This extension MAY appear as a critical or non-
critical extension in end entity certificates. critical extension in end entity certificates.
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 shall be located. subsequent certificates in a certification path MUST be located.
Restrictions may apply to the subject distinguished name or subject Restrictions apply to the subject distinguished name and apply to
alternative names. Restrictions apply only when the specified name subject alternative names. Restrictions apply only when the
form is present. If no name of the type is in the certificate, the specified name form is present. If no name of the type is in 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. (This could prevent CAs that use name subject are identical. (This could prevent CAs that use name
constraints from issuing self-signed certificates to implement key constraints from issuing self-signed 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.
skipping to change at page 39, line 21 skipping to change at page 39, line 29
Legacy implementations exist where an RFC 822 name is embedded in the Legacy implementations exist where an RFC 822 name is embedded in the
subject distinguished name in an attribute of type EmailAddress (see subject distinguished name in an attribute of type EmailAddress (see
sec. 4.1.2.6). When rfc822 names are constrained, but the certificate sec. 4.1.2.6). When rfc822 names are constrained, but the certificate
does not include a subject alternative name, the rfc822 name does not include a subject alternative name, the rfc822 name
constraint MUST be applied to the attribute of type EmailAddress in constraint MUST be applied to the attribute of type EmailAddress in
the subject distinguished name. The ASN.1 syntax for EmailAddress the subject distinguished name. The ASN.1 syntax for EmailAddress
and the corresponding OID are supplied in Appendix A and B. and the corresponding OID are supplied in Appendix A and B.
Restrictions of the form directoryName MUST be applied to the subject Restrictions of the form directoryName MUST be applied to the subject
field in the certificate and to the subjectAltName extensions of type field in the certificate and to the subjectAltName extensions of type
directoryName. Restrictions of the form x400Address MUST be applied directoryName. Restrictions of the form x400Address MUST be applied
to subjectAltName extensions of type x400Address. to subjectAltName extensions of type x400Address.
When applying restrictions of the form directoryName, an When applying restrictions of the form directoryName, an
implementation MUST compare DN attributes. At a minimum, implementation MUST compare DN attributes. At a minimum,
implementations MUST perform the DN comparison rules specified in implementations MUST perform the DN comparison rules specified in
Section 4.1.2.4. CAs issuing certificates with a restriction of the Section 4.1.2.4. CAs issuing certificates with a restriction of the
form directoryName SHOULD NOT rely on implementation of the full ISO form directoryName SHOULD NOT rely on implementation of the full ISO
DN name comparison algorithm. This implies name restrictions shall DN name comparison algorithm. This implies name restrictions MUST be
be stated identically to the encoding used in the subject field or stated identically to the encoding used in the subject field or
subjectAltName extension. subjectAltName extension.
The syntax of iPAddress MUST be as described in section 4.2.1.7 with The syntax of iPAddress MUST be as described in section 4.2.1.7 with
the following additions specifically for Name Constraints. For IPv4 the following additions specifically for Name Constraints. For IPv4
addresses, the ipAddress field of generalName MUST contain eight (8) addresses, the ipAddress field of generalName MUST contain eight (8)
octets, encoded in the style of RFC 1519 (CIDR) to represent an octets, encoded in the style of RFC 1519 (CIDR) to represent an
address range.[RFC 1519] For IPv6 addresses, the ipAddress field address range.[RFC 1519] For IPv6 addresses, the ipAddress field
MUST contain 32 octets similarly encoded. For example, a name MUST contain 32 octets similarly encoded. For example, a name
constraint for "class C" subnet 10.9.8.0 shall be represented as the constraint for "class C" subnet 10.9.8.0 is represented as the octets
octets 0A 09 08 00 FF FF FF 00, representing the CIDR notation 0A 09 08 00 FF FF FF 00, representing the CIDR notation
10.9.8.0/255.255.255.0. 10.9.8.0/255.255.255.0.
The syntax and semantics for name constraints for otherName, The syntax and semantics for name constraints for otherName,
ediPartyName, and registeredID are not defined by this specification. ediPartyName, and registeredID are not defined by this specification.
id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 }
NameConstraints ::= SEQUENCE { NameConstraints ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees OPTIONAL, permittedSubtrees [0] GeneralSubtrees OPTIONAL,
excludedSubtrees [1] GeneralSubtrees OPTIONAL } excludedSubtrees [1] GeneralSubtrees OPTIONAL }
skipping to change at page 40, line 30 skipping to change at page 40, line 37
identifier. identifier.
If the inhibitPolicyMapping field is present, the value indicates the If the inhibitPolicyMapping field is present, the value indicates the
number of additional certificates that may appear in the path before number of additional certificates that may appear in the path before
policy mapping is no longer permitted. For example, a value of one policy mapping is no longer permitted. For example, a value of one
indicates that policy mapping may be processed in certificates issued indicates that policy mapping may be processed in certificates issued
by the subject of this certificate, but not in additional by the subject of this certificate, but not in additional
certificates in the path. certificates in the path.
If the requireExplicitPolicy field is present, subsequent If the requireExplicitPolicy field is present, subsequent
certificates shall 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 null sequence. That is, at least one of the inhibitPolicyMapping
field or the requireExplicitPolicy field MUST be present. The field or the requireExplicitPolicy field MUST be present. The
skipping to change at page 41, line 19 skipping to change at page 41, line 27
purposes indicated in the key usage extension field. In general, purposes indicated in the key usage extension field. In general,
this extension will appear only in end entity certificates. This this extension will appear only in end entity certificates. This
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 shall be assigned in identifiers used to identify key purposes MUST be assigned in
accordance with IANA or ITU-T Rec. X.660 | ISO/IEC/ITU 9834-1. accordance with IANA or ITU-T Rec. X.660 | ISO/IEC/ITU 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
intended purpose or purposes of the key, and may be used in finding intended purpose or purposes of the key, and may be used in finding
the correct key/certificate of an entity that has multiple the correct key/certificate of an entity that has multiple
keys/certificates. It is an advisory field and does not imply that keys/certificates. It is an advisory field and does not imply that
usage of the key is restricted by the certification authority to the usage of the key is restricted by the certification authority to the
purpose indicated. Certificate using applications may nevertheless purpose indicated. Certificate using applications may nevertheless
require that a particular purpose be indicated in order for the require that a particular purpose be indicated in order for the
skipping to change at page 41, line 50 skipping to change at page 42, line 9
If a certificate contains both a critical key usage field and a If a certificate contains both a critical key usage field and a
critical extended key usage field, then both fields MUST be processed critical extended key usage field, then both fields MUST be processed
independently and the certificate MUST only be used for a purpose independently and the certificate MUST only be used for a purpose
consistent with both fields. If there is no purpose consistent with consistent with both fields. If there is no purpose consistent with
both fields, then the certificate MUST NOT be used for any purpose. both fields, then the certificate MUST NOT be used for any purpose.
The following key usage purposes are defined by this profile: The following key usage purposes are defined by this profile:
id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
id-kp-serverAuth OBJECT IDENTIFIER ::= {id-kp 1} id-kp-serverAuth OBJECT IDENTIFIER ::= {id-kp 1}
-- TLS Web server authentication -- TLS Web server authentication
-- Key usage bits that may be consistent: digitalSignature, -- Key usage bits that may be consistent: digitalSignature,
-- keyEncipherment or keyAgreement -- keyEncipherment or keyAgreement
-- --
id-kp-clientAuth OBJECT IDENTIFIER ::= {id-kp 2} id-kp-clientAuth OBJECT IDENTIFIER ::= {id-kp 2}
-- TLS Web client authentication -- TLS Web client authentication
-- Key usage bits that may be consistent: digitalSignature and/or -- Key usage bits that may be consistent: digitalSignature and/or
-- keyAgreement -- keyAgreement
-- --
id-kp-codeSigning OBJECT IDENTIFIER ::= {id-kp 3} id-kp-codeSigning OBJECT IDENTIFIER ::= {id-kp 3}
-- Signing of downloadable executable code -- Signing of downloadable executable code
-- Key usage bits that may be consistent: digitalSignature -- Key usage bits that may be consistent: digitalSignature
-- --
id-kp-emailProtection OBJECT IDENTIFIER ::= {id-kp 4} id-kp-emailProtection OBJECT IDENTIFIER ::= {id-kp 4}
-- E-mail protection -- E-mail protection
-- Key usage bits that may be consistent: digitalSignature, -- Key usage bits that may be consistent: digitalSignature,
-- nonRepudiation, and/or (keyEncipherment -- nonRepudiation, and/or (keyEncipherment
-- or keyAgreement) -- or keyAgreement)
-- --
id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }
-- Binding the hash of an object to a time from an agreed-upon time -- Binding the hash of an object to a time from an agreed-upon time
-- source. Key usage bits that may be consistent: digitalSignature, -- source. Key usage bits that may be consistent: digitalSignature,
-- nonRepudiation -- nonRepudiation
4.2.1.14 CRL Distribution Points 4.2.1.14 CRL Distribution Points
The CRL distribution points extension identifies how CRL information The CRL distribution points extension identifies how CRL information
is obtained. The extension SHOULD be non-critical, but this profile is obtained. The extension SHOULD be non-critical, but this profile
recommends support for this extension by CAs and applications. RECOMMENDS support for this extension by CAs and applications.
Further discussion of CRL management is contained in section 5. Further discussion of CRL management is contained in section 5.
The cRLDistributionPoints extension is a SEQUENCE of The cRLDistributionPoints extension is a SEQUENCE of
DistributionPoint. A DistributionPoint consists of three fields, DistributionPoint. A DistributionPoint consists of three fields,
each of which is optional: the name of the DistributionPoint, each of which is optional: the name of the DistributionPoint,
ReasonsFlags, and the cRLIssuer. While each component is optional, a ReasonsFlags, and the cRLIssuer. While each component is optional, a
DistributionPoint MUST NOT consist of only the ReasonsFlags field. If DistributionPoint MUST NOT consist of only the ReasonsFlags field.
the distributionPoint omits cRLIssuer, the CRL MUST be issued by the If the distributionPoint omits cRLIssuer, the CRL MUST be issued by
CA that issued the certificate. If the distributionPointName is the CA that issued the certificate. If the distributionPointName is
absent, cRLIssuer MUST be present and include a Name corresponding to absent, cRLIssuer MUST be present and include a Name corresponding to
an X.500 or LDAP directory entry where the CRL is located. an X.500 or LDAP directory entry where the CRL is located.
If the cRLDistributionPoints extension contains a If the cRLDistributionPoints extension contains a
DistributionPointName of type URI, the following semantics MUST be DistributionPointName of type URI, the following semantics MUST be
assumed: the URI is a pointer to the current CRL for the associated assumed: the URI is a pointer to the current CRL for the associated
reasons and will be issued by the associated cRLIssuer. The expected reasons and will be issued by the associated cRLIssuer. The expected
values for the URI are those defined in 4.2.1.7. Processing rules for values for the URI are those defined in 4.2.1.7. Processing rules for
other values are not defined by this specification. If the other values are not defined by this specification. If the
distributionPoint omits reasons, the CRL MUST include revocations for distributionPoint omits reasons, the CRL MUST include revocations for
skipping to change at page 43, line 50 skipping to change at page 44, line 8
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
skipping to change at page 48, line 12 skipping to change at page 48, line 18
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,
signatureValue BIT STRING } signatureValue BIT STRING }
TBSCertList ::= SEQUENCE { TBSCertList ::= SEQUENCE {
version Version OPTIONAL, version Version OPTIONAL,
-- if present, shall be v2 -- if present, MUST be v2
signature AlgorithmIdentifier, signature AlgorithmIdentifier,
issuer Name, issuer Name,
thisUpdate Time, thisUpdate Time,
nextUpdate Time OPTIONAL, nextUpdate Time OPTIONAL,
revokedCertificates SEQUENCE OF SEQUENCE { revokedCertificates SEQUENCE OF SEQUENCE {
userCertificate CertificateSerialNumber, userCertificate CertificateSerialNumber,
revocationDate Time, revocationDate Time,
crlEntryExtensions Extensions OPTIONAL crlEntryExtensions Extensions OPTIONAL
-- if present, shall be v2 -- if present, MUST be v2
} OPTIONAL, } OPTIONAL,
crlExtensions [0] EXPLICIT Extensions OPTIONAL crlExtensions [0] EXPLICIT Extensions OPTIONAL
-- if present, shall be v2 -- if present, MUST be v2
} }
-- Version, Time, CertificateSerialNumber, and Extensions -- Version, Time, CertificateSerialNumber, and Extensions
-- are all defined in the ASN.1 in section 4.1 -- are all defined in the ASN.1 in section 4.1
-- AlgorithmIdentifier is defined in section 4.1.1.2 -- AlgorithmIdentifier is defined in section 4.1.1.2
The following items describe the use of the X.509 v2 CRL in the The following items describe the use of the X.509 v2 CRL in the
Internet PKI. Internet PKI.
skipping to change at page 49, line 21 skipping to change at page 49, line 24
Conforming CAs MUST use the algorithm identifiers presented in [PKIX Conforming CAs MUST use the algorithm identifiers presented in [PKIX
ALGS] when signing with a supported signature algorithm. ALGS] when signing with a supported signature algorithm.
This field MUST contain the same algorithm identifier as the This field MUST contain the same algorithm identifier as the
signature field in the sequence tbsCertList (see sec. 5.1.2.2). signature field in the sequence tbsCertList (see sec. 5.1.2.2).
5.1.1.3 signatureValue 5.1.1.3 signatureValue
The signatureValue field contains a digital signature computed upon The signatureValue field contains a digital signature computed upon
the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded tbsCertList the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded tbsCertList
is used as the input to the signature function. This signature value is used as the input to the signature function. This signature value
is then ASN.1 encoded as a BIT STRING and included in the CRL's is then ASN.1 encoded as a BIT STRING and included in the CRL's
signatureValue field. The details of this process are specified for signatureValue field. The details of this process are specified for
each of the supported algorithms in [PKIX ALGS]. each of the supported algorithms in [PKIX ALGS].
CAs MAY use one private key to digitally sign certificates and CRLs,
or CAs MAY use separate private keys to digitally sign certificates
and CRLs. When separate private keys are employed, each of the
public keys associated with these private keys is placed in a
separate certificate, one with the keyCertSign bit set in the key
usage extension, and one with the cRLSign bit set in the key usage
extension (see sec. 4.2.1.3). When separate private keys are
employed, certificates issued by the CA contain one authority key
identifier, and the corresponding CRLs contain a different authority
key identifier. The use of separate CA certificates for validation
of certificate signatures and CRL signatures can offer improved
security characteristics; however, it imposes a burden on
applications, and it might limit interoperability. Many applications
construct a certification path, and then validate the certification
path (see sec. 6). CRL checking in turn requires a separate
certification path to be constructed and validated for the CA's CRL
signature validation certificate. Applications that perform CRL
checking MUST support certification path validation when certificates
and CRLs are digitally signed with the same CA private key. These
applications SHOULD support certification path validation when
certificates and CRLs are digitally signed with different CA private
keys.
5.1.2 Certificate List "To Be Signed" 5.1.2 Certificate List "To Be Signed"
The certificate list to be signed, or TBSCertList, is a SEQUENCE of The certificate list to be signed, or TBSCertList, is a SEQUENCE of
required and optional fields. The required fields identify the CRL required and optional fields. The required fields identify the CRL
issuer, the algorithm used to sign the CRL, the date and time the CRL issuer, the algorithm used to sign the CRL, the date and time the CRL
was issued, and the date and time by which the CA will issue the next was issued, and the date and time by which the CA will issue the next
CRL. CRL.
Optional fields include lists of revoked certificates and CRL Optional fields include lists of revoked certificates and CRL
extensions. The revoked certificate list is optional to support the extensions. The revoked certificate list is optional to support the
skipping to change at page 50, line 23 skipping to change at page 50, line 51
distinguished name (DN). The issuer name field is defined as the distinguished name (DN). The issuer name field is defined as the
X.501 type Name, and MUST follow the encoding rules for the issuer X.501 type Name, and MUST follow the encoding rules for the issuer
name field in the certificate (see sec. 4.1.2.4). name field in the certificate (see sec. 4.1.2.4).
5.1.2.4 This Update 5.1.2.4 This Update
This field indicates the issue date of this CRL. ThisUpdate may be This field indicates the issue date of this CRL. ThisUpdate may be
encoded as UTCTime or GeneralizedTime. encoded as UTCTime or GeneralizedTime.
CAs conforming to this profile that issue CRLs MUST encode thisUpdate CAs conforming to this profile that issue CRLs MUST encode thisUpdate
as UTCTime for dates through the year 2049. CAs conforming to this as UTCTime for dates through the year 2049. CAs conforming to this
profile that issue CRLs MUST encode thisUpdate as GeneralizedTime for profile that issue CRLs MUST encode thisUpdate as GeneralizedTime for
dates in the year 2050 or later. dates in the year 2050 or later.
Where encoded as UTCTime, thisUpdate MUST be specified and Where encoded as UTCTime, thisUpdate MUST be specified and
interpreted as defined in section 4.1.2.5.1. Where encoded as interpreted as defined in section 4.1.2.5.1. Where encoded as
GeneralizedTime, thisUpdate MUST be specified and interpreted as GeneralizedTime, thisUpdate MUST be specified and interpreted as
defined in section 4.1.2.5.2. defined in section 4.1.2.5.2.
5.1.2.5 Next Update 5.1.2.5 Next Update
This field indicates the date by which the next CRL will be issued. This field indicates the date by which the next CRL will be issued.
The next CRL could be issued before the indicated date, but it will The next CRL could be issued before the indicated date, but it will
not be issued any later than the indicated date. CAs SHOULD issue not be issued any later than the indicated date. CAs SHOULD issue
CRLs with a nextUpdate time equal to or later than all previous CRLs. CRLs with a nextUpdate time equal to or later than all previous CRLs.
nextUpdate may be encoded as UTCTime or GeneralizedTime. nextUpdate may be encoded as UTCTime or GeneralizedTime.
This profile requires inclusion of nextUpdate in all CRLs issued by This profile requires inclusion of nextUpdate in all CRLs issued by
conforming CAs. Note that the ASN.1 syntax of TBSCertList describes conforming CAs. Note that the ASN.1 syntax of TBSCertList describes
this field as OPTIONAL, which is consistent with the ASN.1 structure this field as OPTIONAL, which is consistent with the ASN.1 structure
defined in [X.509]. The behavior of clients processing CRLs which defined in [X.509]. The behavior of clients processing CRLs which
omit nextUpdate is not specified by this profile. omit nextUpdate is not specified by this profile.
CAs conforming to this profile that issue CRLs MUST encode nextUpdate CAs conforming to this profile that issue CRLs MUST encode nextUpdate
as UTCTime for dates through the year 2049. CAs conforming to this as UTCTime for dates through the year 2049. CAs conforming to this
profile that issue CRLs MUST encode nextUpdate as GeneralizedTime for profile that issue CRLs MUST encode nextUpdate as GeneralizedTime for
dates in the year 2050 or later. dates in the year 2050 or later.
Where encoded as UTCTime, nextUpdate MUST be specified and Where encoded as UTCTime, nextUpdate MUST be specified and
interpreted as defined in section 4.1.2.5.1. Where encoded as interpreted as defined in section 4.1.2.5.1. Where encoded as
GeneralizedTime, nextUpdate MUST be specified and interpreted as GeneralizedTime, nextUpdate MUST be specified and interpreted as
defined in section 4.1.2.5.2. defined in section 4.1.2.5.2.
5.1.2.6 Revoked Certificates 5.1.2.6 Revoked Certificates
skipping to change at page 54, line 19 skipping to change at page 54, line 45
(b) If the certificate was not removed from hold, but was (b) If the certificate was not removed from hold, but was
permanently revoked, then it must be listed on all subsequent permanently revoked, then it must be listed on all subsequent
delta CRLs where the cRLNumber of the referenced base CRL is less delta CRLs where the cRLNumber of the referenced base CRL is less
than the cRLNumber of the CRL (either a delta CRL or a CRL that is than the cRLNumber of the CRL (either a delta CRL or a CRL that is
complete for the given scope) on which the permanent revocation complete for the given scope) on which the permanent revocation
notice first appeared. notice first appeared.
id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }
deltaCRLIndicator EXTENSION ::= {
SYNTAX BaseCRLNumber
IDENTIFIED BY id-ce-deltaCRLIndicator }
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 for a particular CRL, and it identifies the CRL distribution point for a particular CRL, and it
indicates whether the CRL covers revocation for end entity indicates whether the CRL covers revocation for end entity
certificates only, CA certificates only, or a limited set of reason certificates only, CA certificates only, or a limited set of reason
codes. Although the extension is critical, conforming codes. Although the extension is critical, conforming
implementations are not required to support this extension. implementations are not required to support this extension.
The CRL is signed using the CA's private key. CRL Distribution The CRL is signed using the CA's private key. CRL Distribution
Points do not have their own key pairs. If the CRL is stored in the Points do not have their own key pairs. If the CRL is stored in the
X.500 Directory, it is stored in the Directory entry corresponding to X.500 Directory, it is stored in the Directory entry corresponding to
the CRL distribution point, which may be different than the Directory the CRL distribution point, which may be different than the Directory
entry of the CA. entry of the CA.
The reason codes associated with a distribution point shall be The reason codes associated with a distribution point MUST be
specified in onlySomeReasons. If onlySomeReasons does not appear, the specified in onlySomeReasons. If onlySomeReasons does not appear,
distribution point shall contain revocations for all reason codes. the distribution point shall contain revocations for all reason
CAs may use CRL distribution points to partition the CRL on the basis codes. CAs MAY use CRL distribution points to partition the CRL on
of compromise and routine revocation. In this case, the revocations the basis of compromise and routine revocation. In this case, the
with reason code keyCompromise (1) and cACompromise (2) appear in one revocations with reason code keyCompromise (1) and cACompromise (2)
distribution point, and the revocations with other reason codes appear in one distribution point, and the revocations with other
appear in another distribution point. reason codes appear in another distribution point.
Where the issuingDistributionPoint extension contains a URL, the Where the issuingDistributionPoint extension contains a URL, the
following semantics MUST be assumed: the object is a pointer to the following semantics MUST be assumed: the object is a pointer to the
most current CRL issued by this CA. The URI schemes ftp, http, most current CRL issued by this CA. The URI schemes ftp, http,
mailto [RFC1738] and ldap [RFC1778] are defined for this purpose. mailto [RFC1738] and ldap [RFC1778] are defined for this purpose.
The URI MUST be an absolute, not relative, pathname and MUST specify The URI MUST be an absolute, not relative, pathname and MUST specify
the host. the host.
id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 }
skipping to change at page 55, line 39 skipping to change at page 56, line 14
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
also allows communities to define private CRL entry extensions to also allows communities to define private CRL entry extensions to
carry information unique to those communities. Each extension in a carry information unique to those communities. Each extension in a
CRL entry may be designated as critical or non-critical. A CRL CRL entry may be designated as critical or non-critical. A CRL
validation MUST fail if it encounters a critical CRL entry extension validation MUST fail if it encounters a critical CRL entry extension
which it does not know how to process. However, an unrecognized which it does not know how to process. However, an unrecognized non-
non-critical CRL entry extension may be ignored. The following critical CRL entry extension may be ignored. The following
subsections present recommended extensions used within Internet CRL subsections present recommended extensions used within Internet CRL
entries and standard locations for information. Communities may entries and standard locations for information. Communities may
elect to use additional CRL entry extensions; however, caution should elect to use additional CRL entry extensions; however, caution should
be exercised in adopting any critical extensions in CRL entries which be exercised in adopting any critical extensions in CRL entries which
might be used in a general context. might be used in a general context.
All CRL entry extensions used in this specification are non-critical. All CRL entry extensions used in this specification are non-critical.
Support for these extensions is optional for conforming CAs and Support for these extensions is optional for conforming CAs and
applications. However, CAs that issue CRLs SHOULD include reason applications. However, CAs that issue CRLs SHOULD include reason
codes (see sec. 5.3.1) and invalidity dates (see sec. 5.3.3) whenever codes (see sec. 5.3.1) and invalidity dates (see sec. 5.3.3) whenever
this information is available. this information is available.
5.3.1 Reason Code 5.3.1 Reason Code
The reasonCode is a non-critical CRL entry extension that identifies The reasonCode is a non-critical CRL entry extension that identifies
the reason for the certificate revocation. CAs are strongly the reason for the certificate revocation. CAs are strongly
encouraged to include meaningful reason codes in CRL entries; encouraged to include meaningful reason codes in CRL entries;
however, the reason code CRL entry extension SHOULD be absent instead however, the reason code CRL entry extension SHOULD be absent instead
of using the unspecified (0) reasonCode value. of using the unspecified (0) reasonCode value.
id-ce-cRLReason OBJECT IDENTIFIER ::= { id-ce 21 } id-ce-cRLReason OBJECT IDENTIFIER ::= { id-ce 21 }
-- reasonCode ::= { CRLReason } -- reasonCode ::= { CRLReason }
CRLReason ::= ENUMERATED { CRLReason ::= ENUMERATED {
unspecified (0), unspecified (0),
skipping to change at page 58, line 24 skipping to change at page 58, line 49
extensions allow the certification path processing logic to automate extensions allow the certification path processing logic to automate
the decision making process. the decision making process.
This section describes an algorithm for validating certification This section describes an algorithm for validating certification
paths. Conforming implementations of this specification are not paths. Conforming implementations of this specification are not
required to implement this algorithm, but MUST provide functionality required to implement this algorithm, but MUST provide functionality
equivalent to the external behavior resulting from this procedure. equivalent to the external behavior resulting from this procedure.
Any algorithm may be used by a particular implementation so long as Any algorithm may be used by a particular implementation so long as
it derives the correct result. it derives the correct result.
In section 6.1, the text describes basic path validation. Valid paths In section 6.1, the text describes basic path validation. Valid
begin with certificates issued by a "most-trusted CA". The algorithm paths begin with certificates issued by a "most-trusted CA". The
requires the public key of the CA, the CA's name, and any constraints algorithm requires the public key of the CA, the CA's name, and any
upon the set of paths which may be validated using this key. constraints upon the set of paths which may be validated using this
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
skipping to change at page 59, line 9 skipping to change at page 59, line 35
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, some of the certificate fields processed in this algorithm. However, some of the certificate fields processed in
this algorithm are optional for compliant implementations. Clients this algorithm are optional for compliant implementations. Clients
that do not support these fields may omit the corresponding steps in that do not support these fields may omit the corresponding steps in
the path validation algorithm. 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 critical clients MUST reject the certificate if it contains critical
extensions that are not supported. extensions that are not supported.
This text describes the trust anchor as an input to the algorithm. This text describes the trust anchor as an input to the algorithm.
There is no requirement that the same trust anchor be used to There is no requirement that the same trust anchor be used to
validate all certification paths. Different trust anchors may be validate all certification paths. Different trust anchors may be
used to validate different paths, as discussed further in Section used to validate different paths, as discussed further in Section
6.2. 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
skipping to change at page 60, line 15 skipping to change at page 60, line 41
general, the issuer and subject of the certificates that make up a general, the issuer and subject of the certificates that make up a
path are different for each certificate. However, a CA may issue a path are different for each certificate. However, a CA may issue a
certificate to itself to support key rollover or changes in certificate to itself to support key rollover or changes in
certificate policies. These self-issued certificates are not counted certificate policies. These self-issued certificates are not counted
when evaluating path length or name constraints. when evaluating path length or name constraints.
This section presents the algorithm in four basic steps: (1) This section presents the algorithm in four basic steps: (1)
initialization, (2) basic certificate processing, (3) preparation for initialization, (2) basic certificate processing, (3) preparation for
the next certificate, and (4) wrap-up. Steps (1) and (4) are the next certificate, and (4) wrap-up. Steps (1) and (4) are
performed exactly once. Step (2) is performed for all certificates performed exactly once. Step (2) is performed for all certificates
in the path. Step (3) is performed for all certificates in the path in the path. Step (3) is performed for all certificates in the path
except the final certificate. Figure 2 provides a high-level except the final certificate. Figure 2 provides a high-level
flowchart of this algorithm. flowchart of this algorithm.
+-------+ +-------+
| START | | START |
+-------+ +-------+
| |
V V
+----------------+ +----------------+
| Initialization | | Initialization |
skipping to change at page 62, line 22 skipping to change at page 62, line 22
(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. The processing procedure in the form of a self-signed certificate.
trusted anchor information is trusted because it was delivered to The trusted anchor information is trusted because it was delivered
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.
(e) initial-policy-mapping-inhibit, which indicates if policy (e) initial-policy-mapping-inhibit, which indicates if policy
mapping is allowed in the certification path. mapping is allowed in the certification path.
(f) initial-explicit-policy, which indicates if the path must be (f) initial-explicit-policy, which indicates if the path must be
valid for at least one of the certificate policies in the user- valid for at least one of the certificate policies in the user-
initial-policy-set. initial-policy-set.
skipping to change at page 63, line 49 skipping to change at page 63, line 49
| FALSE | <---- criticality_indicator | FALSE | <---- criticality_indicator
+----------------+ +----------------+
| {any-policy} | <---- expected_policy_set | {any-policy} | <---- expected_policy_set
+----------------+ +----------------+
Figure 3. Initial value of the valid_policy_tree state variable Figure 3. Initial value of the valid_policy_tree state variable
(b) permitted_subtrees: A set of root names for each name type (b) permitted_subtrees: A set of root names for each name type
(e.g., X.500 distinguished names, email addresses, or ip (e.g., X.500 distinguished names, email addresses, or ip
addresses) defining a set of subtrees within which all subject addresses) defining a set of subtrees within which all subject
names in subsequent certificates in the certification path shall names in subsequent certificates in the certification path MUST
fall. This variable includes a set for each name type: the initial fall. This variable includes a set for each name type: the
value for the set for Distinguished Names is the set of all initial value for the set for Distinguished Names is the set of
Distinguished names; the initial value for the set of RFC822 names all Distinguished names; the initial value for the set of RFC822
is the set of all RFC822 names, etc. names is the set of all RFC822 names, etc.
(c) excluded_subtrees: A set of root names for each name type (c) excluded_subtrees: A set of root names for each name type
(e.g., X.500 distinguished names, email addresses, or ip (e.g., X.500 distinguished names, email addresses, or ip
addresses) defining a set of subtrees within which no subject name addresses) defining a set of subtrees within which no subject name
in subsequent certificates in the certification path may fall. in subsequent certificates in the certification path may fall.
This variable includes a set for each name type, and the initial This variable includes a set for each name type, and the initial
value for each set is empty. value for each set is empty.
(d) explicit_policy: an integer which indicates if a non-NULL (d) explicit_policy: an integer which indicates if a non-NULL
valid_policy_tree is required. The integer indicates the number of valid_policy_tree is required. The integer indicates the number of
non-self-issued certificates to be processed before this non-self-issued certificates to be processed before this
requirement is imposed. Once set, this variable may be decreased, requirement is imposed. Once set, this variable may be decreased,
but may not be increased. That is, if a certificate in the path but may not be increased. That is, if a certificate in the path
requires a non-NULL valid_policy_tree, a later certificate can not requires a non-NULL valid_policy_tree, a later certificate can not
remove this requirement. If initial-explicit-policy is set, then remove this requirement. If initial-explicit-policy is set, then
the initial value is 0, otherwise the initial value is n+1. the initial value is 0, otherwise the initial value is n+1.
(e) inhibit_any-policy: an integer which indicates whether the (e) inhibit_any-policy: an integer which indicates whether the
any-policy policy identifier is considered a match. The integer any-policy policy identifier is considered a match. The integer
indicates the number of non-self-issued certificates to be indicates the number of non-self-issued certificates to be
processed before the any-policy OID, if asserted in a certificate, processed before the any-policy OID, if asserted in a certificate,
is ignored. Once set, this variable may be decreased, but may not is ignored. Once set, this variable may be decreased, but may not
skipping to change at page 66, line 19 skipping to change at page 66, line 19
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 qualifier_set to P-Q, and set the expected_policy_set to {P-
{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
rule will generate a child node of depth i for the Gold rule will generate a child node of depth i for the Gold
policy. The result is shown as Figure 4. policy. The result is shown as Figure 4.
|-----------------| |-----------------|
skipping to change at page 67, line 34 skipping to change at page 67, line 34
|-----------------| |-----------------|
| {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 qualifier_set to P-Q, and set the expected_policy_set to {P-
{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
policy does not have a qualifier, but the Silver policy has policy does not have a qualifier, but the Silver policy has
the qualifier Q-Silver. If Gold and Silver were not matched the qualifier Q-Silver. If Gold and Silver were not matched
in (i) above, this rule will generate two child nodes of in (i) above, this rule will generate two child nodes of
depth i, one for each policy. The result is shown as Figure depth i, one for each policy. The result is shown as Figure
5. 5.
|-----------------| |-----------------|
| any-policy | | any-policy |
skipping to change at page 69, line 37 skipping to change at page 69, line 37
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 or
less without any child nodes, delete that node. Repeat this 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 to below. The two nodes at depth i-1 that are marked with an 'X'
the resulting tree will cause the node at depth i-2 that is have no children, and are deleted. Applying this rule to the
marked with an 'Y' to be deleted. The following application of resulting tree will cause the node at depth i-2 that is marked
the rule does not cause any nodes to be deleted, and this step with an 'Y' to be deleted. The following application of the
is complete. rule does not cause any nodes to be deleted, and this step is
complete.
+-----------+ +-----------+
| | node of depth i-3 | | node of depth i-3
+-----------+ +-----------+
/ | \ / | \
/ | \ / | \
/ | \ / | \
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
| | | | | Y | nodes of | | | | | Y | nodes of
+-----------+ +-----------+ +-----------+ depth i-2 +-----------+ +-----------+ +-----------+ depth i-2
skipping to change at page 74, line 23 skipping to change at page 74, line 23
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.
(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- (ii) If the valid_policy_tree is not NULL and the user-initial-
initial-policy-set is any-policy, the intersection is the policy-set is any-policy, the intersection is the entire
entire valid_policy_tree. 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 parent nodes have
a valid_policy of any-policy. This is the 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.
(h) If the certificate was not self-issued, verify that If either (1) the value of explicit_policy variable is greater than
max_path_length is greater than zero and decrement zero, or (2) the valid_policy_tree is not NULL, then path processing
max_path_length by 1. has succeeded.
If check (h) fails, the procedure terminates, returning a failure
indication and an appropriate reason.
If check (h) succeeds and either (1) value of explicit_policy
variable is greater than zero, or (2) the valid_policy_tree is not
NULL, then path processing 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 path begins with a specific single certification path. While each path begins with a specific
trust anchor, there is no requirement that all paths validated by a trust anchor, there is no requirement that all paths validated by a
particular system share a single trust anchor. particular system share a single trust anchor. An implementation
that supports multiple trust anchors may augment the algorithm
prresented in section 6.1 to further limit the set of valid paths
which begin with a particular trust anchor. For example, an
implementation may specify name constraints that apply to a specific
trust anchor.
The selection of one or more trusted CAs is a local decision. A The selection of one or more trusted CAs is a local decision. A
system may provide any one of its trusted CAs as the trust anchor for system may provide any one of its trusted CAs as the trust anchor for
a particular path. The inputs to the path validation algorithm may a particular path. The inputs to the path validation algorithm may
be different for each path. The inputs used to process a path may be different for each path. The inputs used to process a path may
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.
skipping to change at page 76, line 37 skipping to change at page 76, line 35
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 whether the supplied certificate is associated with a CA or an
end-entity. end-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. The reasons supported by the CRLs and delta CRLs processed so far.
legal members of the set are the possible values for reasonflags: The legal members of the set are the possible values for
unspecified; keyCompromise; caCompromise; affiliationChanged; reasonflags: unspecified; keyCompromise; caCompromise;
superseded; cessationOfOperation; and certificateHold. The affiliationChanged; superseded; cessationOfOperation; and
special value all-reasons is used to denote the set of all legal certificateHold. The special value all-reasons is used to denote
members. This variable is initialized to the empty set. the set of all legal 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. Legal values are unspecified; keyCompromise; certificate. Legal values are unspecified; keyCompromise;
caCompromise; affiliationChanged; superseded; caCompromise; affiliationChanged; superseded;
cessationOfOperation; and certificateHold, the special value cessationOfOperation; and certificateHold, the special value
UNREVOKED, or the special value UNDETERMINED. This variable is UNREVOKED, or the special value UNDETERMINED. This variable is
initialized to the special value UNREVOKED. 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
skipping to change at page 79, line 50 skipping to change at page 79, line 49
Authentication Service (V5)," RFC 1510, September 1993. Authentication Service (V5)," RFC 1510, September 1993.
[RFC 1519] V. Fuller, T. Li, J. Yu, and K. Varadhan. "Classless [RFC 1519] V. Fuller, T. Li, J. Yu, and K. Varadhan. "Classless
Inter-Domain Routing (CIDR): an Address Assignment and Inter-Domain Routing (CIDR): an Address Assignment and
Aggregation Strategy", September 1993. Aggregation Strategy", September 1993.
[RFC 1738] Berners-Lee, T., Masinter L., and M. McCahill. [RFC 1738] Berners-Lee, T., Masinter L., and M. McCahill.
"Uniform Resource Locators (URL)", RFC 1738, December 1994. "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[RFC 1778] Howes, T., Kille S., Yeong, W. and C. Robbins. "The [RFC 1778] Howes, T., Kille S., Yeong, W. and C. Robbins. "The
String Representation of Standard Attribute Syntaxes," String Representation of Standard Attribute Syntaxes,"
RFC 1778, March 1995. RFC 1778, March 1995.
[RFC 1883] S. Deering and R. Hinden. "Internet Protocol, Version 6 [RFC 1883] S. Deering and R. Hinden. "Internet Protocol, Version 6
(IPv6) Specification", December 1995. (IPv6) Specification", December 1995.
[RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997. Requirement Levels", March 1997.
[RFC 2247] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. [RFC 2247] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S.
Sataluri. "Using Domains in LDAP/X.500 Distinguished Names", Sataluri. "Using Domains in LDAP/X.500 Distinguished Names",
RFC 2247, January 1998. RFC 2247, January 1998.
[RFC 2277] H. Alvestrand, "IETF Policy on Character Sets and [RFC 2277] H. Alvestrand, "IETF Policy on Character Sets and
Languages", January 1998. Languages", January 1998.
[RFC 2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646", [RFC 2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646",
January 1998. January 1998.
[RFC 2560] Myers, M., Ankney R., Malpani A., Galperin S., and [RFC 2560] Myers, M., Ankney R., Malpani A., Galperin S., and
C. Adams, "Online Certificate Status Protocal - OCSP", C. Adams, "Online Certificate Status Protocal - OCSP",
June 1999. June 1999.
[SDN.701] SDN.701, "Message Security Protocol 4.0", Revision A [SDN.701] SDN.701, "Message Security Protocol 4.0", Revision A
1997-02-06. 1997-02-06.
[X.208] CCITT Recommendation X.208: Specification of Abstract [X.208] CCITT Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1), 1988. Syntax Notation One (ASN.1), 1988.
[X.501] ITU-T Recommendation X.501: Information [X.501] ITU-T Recommendation X.501: Information
Technology - Open Systems Interconnection - The Technology - Open Systems Interconnection - The
Directory: Models, 1993. Directory: Models, 1993.
[X.509] ITU-T Recommendation X.509 (1997 E): Information [X.509] ITU-T Recommendation X.509 (1997 E): Information
Technology - Open Systems Interconnection - The Technology - Open Systems Interconnection - The
Directory: Authentication Framework, June 1997. Directory: Authentication Framework, June 1997.
[X.520] ITU-T Recommendation X.520: Information [X.520] ITU-T Recommendation X.520: Information
Technology - Open Systems Interconnection - The Technology - Open Systems Interconnection - The
Directory: Selected Attribute Types, 1993. Directory: Selected Attribute Types, 1993.
[X9.55] ANSI X9.55-1995, Public Key Cryptography For The Financial [X9.55] ANSI X9.55-1995, Public Key Cryptography For The Financial
Services Industry: Extensions To Public Key Certificates Services Industry: Extensions To Public Key Certificates
And Certificate Revocation Lists, 8 December, 1995. And Certificate Revocation Lists, 8 December, 1995.
[PKINIT] Tung, B., Neuman C., Hur M., Medvinsky A., Medvinsky S., [PKINIT] Tung, B., Neuman C., Hur M., Medvinsky A., Medvinsky S.,
Wray J., and J. Trostle, "Public Key Cryptography for Wray J., and J. Trostle, "Public Key Cryptography for
Initial Authentciaion in Kerberos," Initial Authentciaion in Kerberos,"
draft-ietf-cat-kerberos-pk-init-11.txt, March 15, 2000. draft-ietf-cat-kerberos-pk-init-11.txt, March 15, 2000.
[PKIX ALGS] Bassham, L., Housley, R., and W. Polk, "Internet X.509 [PKIX ALGS] Bassham, L., Housley, R., and W. Polk, "Internet X.509
Public Key Infrastructure Representation of Public Keys Public Key Infrastructure Representation of Public Keys
and Digital Signatures," and Digital Signatures,"
draft-ietf-pkix-ipki-pkalgs-00.txt, July 14, 2000. draft-ietf-pkix-ipki-pkalgs-00.txt, July 14, 2000.
[PKIX TSA] Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 [PKIX TSA] Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509
Public Key Infrastructure Time Stamp Protocol," Public Key Infrastructure Time Stamp Protocol,"
draft-ietf-pkix-time-stamp-12.txt, November, 2000. draft-ietf-pkix-time-stamp-12.txt, November, 2000.
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. rights.
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 82, line 23 skipping to change at page 82, line 23
applications (e.g., SSL) use a single key pair for signature and key applications (e.g., SSL) use a single key pair for signature and key
management. management.
The protection afforded private keys is a critical factor in The protection afforded private keys is a critical factor in
maintaining security. On a small scale, failure of users to protect maintaining security. On a small scale, failure of users to protect
their private keys will permit an attacker to masquerade as them, or their private keys will permit an attacker to masquerade as them, or
decrypt their personal information. On a larger scale, compromise of decrypt their personal information. On a larger scale, compromise of
a CA's private signing key may have a catastrophic effect. If an a CA's private signing key may have a catastrophic effect. If an
attacker obtains the private key unnoticed, the attacker may issue attacker obtains the private key unnoticed, the attacker may issue
bogus certificates and CRLs. Existence of bogus certificates and bogus certificates and CRLs. Existence of bogus certificates and
CRLs will undermine confidence in the system. If the compromise is CRLs will undermine confidence in the system. If the compromise is
detected, all certificates issued to the CA shall be revoked, detected, all certificates issued to the CA MUST be revoked,
preventing services between its users and users of other CAs. preventing services between its users and users of other CAs.
Rebuilding after such a compromise will be problematic, so CAs are Rebuilding after such a compromise will be problematic, so CAs are
advised to implement a combination of strong technical measures advised to implement a combination of strong technical measures
(e.g., tamper-resistant cryptographic modules) and appropriate (e.g., tamper-resistant cryptographic modules) and appropriate
management procedures (e.g., separation of duties) to avoid such an management procedures (e.g., separation of duties) to avoid such an
incident. incident.
Loss of a CA's private signing key may also be problematic. The CA Loss of a CA's private signing key may also be problematic. The CA
would not be able to produce CRLs or perform normal key rollover. would not be able to produce CRLs or perform normal key rollover.
CAs are advised to maintain secure backup for signing keys. The CAs are advised to maintain secure backup for signing keys. The
skipping to change at page 83, line 39 skipping to change at page 83, line 39
Inconsistent application of name comparison rules may result in Inconsistent application of name comparison rules may result in
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 require comparison of strings without comparing distinguished names require comparison of strings without
regard to case, character set, multi-character white space substring, regard to case, character set, multi-character white space substring,
or leading and trailing white space. This specification relaxes or leading and trailing white space. This specification relaxes
these requirements, requiring support for binary comparison at a these requirements, requiring support for binary comparison at a
minimum. minimum.
CAs shall 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 the latter CA. If CAs use different
encodings, implementations of this specification may fail to encodings, implementations of this specification may fail to
recognize name chains for paths that include this certificate. As a recognize name chains for paths that include this certificate. As a
consequence, valid paths could be rejected. consequence, valid paths could be rejected.
In addition, name constraints for distinguished names shall 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, (1) name constraints stated as subjectAltName extension. If not, (1) 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 (2) name constraints expressed as permittedSubtrees will not and (2) name constraints expressed as permittedSubtrees will not
match and valid paths will be rejected. To avoid acceptance of match and valid paths will be rejected. To avoid acceptance of
invalid paths, CAs should state name constraints for distinguished invalid paths, CAs should state name constraints for distinguished
names as permittedSubtrees where ever possible. names as permittedSubtrees where ever possible.
Appendix A. Psuedo-ASN.1 Structures and OIDs Appendix A. Psuedo-ASN.1 Structures and OIDs
skipping to change at page 85, line 42 skipping to change at page 85, line 42
-- IMPORTS NONE -- -- IMPORTS NONE --
-- UNIVERSAL Types defined in '93 and '98 ASN.1 -- UNIVERSAL Types defined in '93 and '98 ASN.1
-- but required by this specification -- but required by this specification
UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING
-- UniversalString is defined in ASN.1:1993 -- UniversalString is defined in ASN.1:1993
BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING
-- BMPString is the subtype of UniversalString and models -- BMPString is the subtype of UniversalString and models
-- the Basic Multilingual Plane of ISO/IEC/ITU 10646-1 -- the Basic Multilingual Plane of ISO/IEC/ITU 10646-1
UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- The content of this type conforms to RFC 2279. -- The content of this type conforms to RFC 2279.
-- --
-- PKIX specific OIDs -- PKIX specific OIDs
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) }
-- PKIX arcs -- PKIX arcs
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
-- arc for private certificate extensions -- arc for private certificate extensions
id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
-- arc for policy qualifier types -- arc for policy qualifier types
id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
-- arc for extended key purpose OIDS -- arc for extended key purpose OIDS
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
-- arc for access descriptors -- arc for access descriptors
-- policyQualifierIds for Internet policy qualifiers -- policyQualifierIds for Internet policy qualifiers
id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 }
-- OID for CPS qualifier -- OID for CPS qualifier
id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 }
-- OID for user notice qualifier -- OID for user notice qualifier
-- access descriptor definitions -- access descriptor definitions
id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }
id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }
id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 } id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 }
id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 } id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 }
-- attribute data types -- -- attribute data types --
Attribute ::= SEQUENCE { Attribute ::= SEQUENCE {
type AttributeType, type AttributeType,
values SET OF AttributeValue values SET OF AttributeValue
-- at least one value is required -- } -- at least one value is required -- }
AttributeType ::= OBJECT IDENTIFIER AttributeType ::= OBJECT IDENTIFIER
AttributeValue ::= ANY AttributeValue ::= ANY
AttributeTypeAndValue ::= SEQUENCE { AttributeTypeAndValue ::= SEQUENCE {
type AttributeType, type AttributeType,
value AttributeValue } value AttributeValue }
-- suggested naming attributes: Definition of the following -- suggested naming attributes: Definition of the following
-- information object set may be augmented to meet local -- information object set may be augmented to meet local
-- requirements. Note that deleting members of the set may -- requirements. Note that deleting members of the set may
-- prevent interoperability with conforming implementations. -- prevent interoperability with conforming implementations.
-- presented in pairs: the AttributeType followed by the -- presented in pairs: the AttributeType followed by the
-- type definition for the corresponding AttributeValue -- type definition for the corresponding AttributeValue
--Arc for standard naming attributes --Arc for standard naming attributes
id-at OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 4} id-at OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 4}
id-at-name AttributeType ::= {id-at 41} -- Naming attributes of type X520name
id-at-surname AttributeType ::= {id-at 4}
id-at-givenName AttributeType ::= {id-at 42}
id-at-initials AttributeType ::= {id-at 43}
id-at-generationQualifier AttributeType ::= {id-at 44}
X520name ::= CHOICE { id-at-name AttributeType ::= {id-at 41}
teletexString TeletexString (SIZE (1..ub-name)), id-at-surname AttributeType ::= {id-at 4}
printableString PrintableString (SIZE (1..ub-name)), id-at-givenName AttributeType ::= {id-at 42}
universalString UniversalString (SIZE (1..ub-name)), id-at-initials AttributeType ::= {id-at 43}
id-at-generationQualifier AttributeType ::= {id-at 44}
X520name ::= CHOICE {
teletexString TeletexString (SIZE (1..ub-name)),
printableString PrintableString (SIZE (1..ub-name)),
universalString UniversalString (SIZE (1..ub-name)),
utf8String UTF8String (SIZE (1..ub-name)), utf8String UTF8String (SIZE (1..ub-name)),
bmpString BMPString (SIZE(1..ub-name)) } bmpString BMPString (SIZE(1..ub-name)) }
-- Naming attributes of type X520CommonName
id-at-commonName AttributeType ::= {id-at 3} id-at-commonName AttributeType ::= {id-at 3}
X520CommonName ::= CHOICE { X520CommonName ::= CHOICE {
teletexString TeletexString (SIZE (1..ub-common-name)), teletexString TeletexString (SIZE (1..ub-common-name)),
printableString PrintableString (SIZE (1..ub-common-name)), printableString PrintableString (SIZE (1..ub-common-name)),
universalString UniversalString (SIZE (1..ub-common-name)), universalString UniversalString (SIZE (1..ub-common-name)),
utf8String UTF8String (SIZE (1..ub-common-name)), utf8String UTF8String (SIZE (1..ub-common-name)),
bmpString BMPString (SIZE(1..ub-common-name)) } bmpString BMPString (SIZE(1..ub-common-name)) }
-- Naming attributes of type X520LocalityName
id-at-localityName AttributeType ::= {id-at 7} id-at-localityName AttributeType ::= {id-at 7}
X520LocalityName ::= CHOICE { X520LocalityName ::= CHOICE {
teletexString TeletexString (SIZE (1..ub-locality-name)), teletexString TeletexString (SIZE (1..ub-locality-name)),
printableString PrintableString (SIZE (1..ub-locality-name)), printableString PrintableString (SIZE (1..ub-locality-name)),
universalString UniversalString (SIZE (1..ub-locality-name)), universalString UniversalString (SIZE (1..ub-locality-name)),
utf8String UTF8String (SIZE (1..ub-locality-name)), utf8String UTF8String (SIZE (1..ub-locality-name)),
bmpString BMPString (SIZE(1..ub-locality-name)) } bmpString BMPString (SIZE(1..ub-locality-name)) }
-- Naming attributes of type X520StateOrProvinceName
id-at-stateOrProvinceName AttributeType ::= {id-at 8} id-at-stateOrProvinceName AttributeType ::= {id-at 8}
X520StateOrProvinceName ::= CHOICE { X520StateOrProvinceName ::= CHOICE {
teletexString TeletexString (SIZE (1..ub-state-name)), teletexString TeletexString (SIZE (1..ub-state-name)),
printableString PrintableString (SIZE (1..ub-state-name)), printableString PrintableString (SIZE (1..ub-state-name)),
universalString UniversalString (SIZE (1..ub-state-name)), universalString UniversalString (SIZE (1..ub-state-name)),
utf8String UTF8String (SIZE (1..ub-state-name)), utf8String UTF8String (SIZE (1..ub-state-name)),
bmpString BMPString (SIZE(1..ub-state-name)) } bmpString BMPString (SIZE(1..ub-state-name)) }
-- Naming attributes of type X520OrganizationName
id-at-organizationName AttributeType ::= {id-at 10} id-at-organizationName AttributeType ::= {id-at 10}
X520OrganizationName ::= CHOICE { X520OrganizationName ::= CHOICE {
teletexString TeletexString (SIZE (1..ub-organization-name)), teletexString TeletexString (SIZE (1..ub-organization-name)),
printableString PrintableString (SIZE (1..ub-organization-name)), printableString PrintableString (SIZE (1..ub-organization-name)),
universalString UniversalString (SIZE (1..ub-organization-name)), universalString UniversalString (SIZE (1..ub-organization-name)),
utf8String UTF8String (SIZE (1..ub-organization-name)), utf8String UTF8String (SIZE (1..ub-organization-name)),
bmpString BMPString (SIZE(1..ub-organization-name)) } bmpString BMPString (SIZE(1..ub-organization-name)) }
-- Naming attributes of type X520OrganizationalUnitName
id-at-organizationalUnitName AttributeType ::= {id-at 11} id-at-organizationalUnitName AttributeType ::= {id-at 11}
X520OrganizationalUnitName ::= CHOICE { X520OrganizationalUnitName ::= CHOICE {
teletexString TeletexString (SIZE (1..ub-organizational-unit-name)), teletexString TeletexString (SIZE (1..ub-organizational-unit-name)),
printableString PrintableString printableString PrintableString
(SIZE (1..ub-organizational-unit-name)), (SIZE (1..ub-organizational-unit-name)),
universalString UniversalString universalString UniversalString
(SIZE (1..ub-organizational-unit-name)), (SIZE (1..ub-organizational-unit-name)),
utf8String UTF8String (SIZE (1..ub-organizational-unit-name)), utf8String UTF8String (SIZE (1..ub-organizational-unit-name)),
bmpString BMPString (SIZE(1..ub-organizational-unit-name)) } bmpString BMPString (SIZE(1..ub-organizational-unit-name)) }
-- Naming attributes of type X520Title
id-at-title AttributeType ::= {id-at 12} id-at-title AttributeType ::= {id-at 12}
X520Title ::= CHOICE { X520Title ::= CHOICE {
teletexString TeletexString (SIZE (1..ub-title)), teletexString TeletexString (SIZE (1..ub-title)),
printableString PrintableString (SIZE (1..ub-title)), printableString PrintableString (SIZE (1..ub-title)),
universalString UniversalString (SIZE (1..ub-title)), universalString UniversalString (SIZE (1..ub-title)),
utf8String UTF8String (SIZE (1..ub-title)), utf8String UTF8String (SIZE (1..ub-title)),
bmpString BMPString (SIZE(1..ub-title)) } bmpString BMPString (SIZE(1..ub-title)) }
-- Naming attributes of type X520dnQualifier
id-at-dnQualifier AttributeType ::= {id-at 46} id-at-dnQualifier AttributeType ::= {id-at 46}
X520dnQualifier ::= PrintableString
id-at-countryName AttributeType ::= {id-at 6} X520dnQualifier ::= PrintableString
X520countryName ::= PrintableString (SIZE (2)) -- IS 3166 codes
-- Naming attributes of type X520countryName
id-at-countryName AttributeType ::= {id-at 6}
X520countryName ::= PrintableString (SIZE (2)) -- IS 3166 codes
-- Naming attributes of type X520SerialNumber
id-at-serialNumber AttributeType ::= { id-at 5 } id-at-serialNumber AttributeType ::= { id-at 5 }
X520SerialNumber ::= PrintableString (SIZE (1..ub-serial-number))
-- domaincomponent and identifier from RFC 2247 X520SerialNumber ::= PrintableString (SIZE (1..ub-serial-number))
-- Naming attributes of type DomainComponent (from RFC 2247)
- <span class="insert">Naming attributes of type DomainComponent (from</span> RFC <span class="insert">2247)</span>
id-domainComponent OBJECT IDENTIFIER ::= id-domainComponent OBJECT IDENTIFIER ::=
{ 0 9 2342 19200300 100 1 25 } { 0 9 2342 19200300 100 1 25 }
DomainComponent ::= IA5String DomainComponent ::= IA5String
-- Legacy attributes -- Legacy attributes
pkcs-9 OBJECT IDENTIFIER ::= pkcs-9 OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 } { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 }
emailAddress AttributeType ::= { pkcs-9 1 } id-emailAddress AttributeType ::= { pkcs-9 1 }
Pkcs9email ::= IA5String (SIZE (1..ub-emailaddress-length)) EmailAddress ::= IA5String (SIZE (1..ub-emailaddress-length))
-- naming data types -- -- naming data types --
Name ::= CHOICE { -- only one possibility for now -- Name ::= CHOICE { -- only one possibility for now --
rdnSequence RDNSequence } rdnSequence RDNSequence }
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
DistinguishedName ::= RDNSequence DistinguishedName ::= RDNSequence
RelativeDistinguishedName ::= RelativeDistinguishedName ::=
SET SIZE (1 .. MAX) OF AttributeTypeAndValue SET SIZE (1 .. MAX) OF AttributeTypeAndValue
-- Directory string type -- -- Directory string type --
DirectoryString ::= CHOICE { DirectoryString ::= CHOICE {
teletexString TeletexString (SIZE (1..MAX)), teletexString TeletexString (SIZE (1..MAX)),
printableString PrintableString (SIZE (1..MAX)), printableString PrintableString (SIZE (1..MAX)),
universalString UniversalString (SIZE (1..MAX)), universalString UniversalString (SIZE (1..MAX)),
utf8String UTF8String (SIZE (1..MAX)), utf8String UTF8String (SIZE (1..MAX)),
bmpString BMPString (SIZE(1..MAX)) } bmpString BMPString (SIZE(1..MAX)) }
-- certificate and CRL specific structures begin here -- certificate and CRL specific structures begin here
Certificate ::= SEQUENCE { Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate, tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier, signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING } signature BIT STRING }
TBSCertificate ::= SEQUENCE { TBSCertificate ::= SEQUENCE {
version [0] Version DEFAULT v1, version [0] Version DEFAULT v1,
serialNumber CertificateSerialNumber, serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier, signature AlgorithmIdentifier,
issuer Name, issuer Name,
validity Validity, validity Validity,
subject Name, subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo, subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version shall be v2 or v3 -- If present, version MUST be v2 or v3
subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version shall be v2 or v3 -- If present, version MUST be v2 or v3
extensions [3] Extensions OPTIONAL extensions [3] Extensions OPTIONAL
-- If present, version shall be v3 -- } -- If present, version MUST be v3 -- }
Version ::= INTEGER { v1(0), v2(1), v3(2) } Version ::= INTEGER { v1(0), v2(1), v3(2) }
CertificateSerialNumber ::= INTEGER CertificateSerialNumber ::= INTEGER
Validity ::= SEQUENCE { Validity ::= SEQUENCE {
notBefore Time, notBefore Time,
notAfter Time } notAfter Time }
Time ::= CHOICE { Time ::= CHOICE {
skipping to change at page 90, line 49 skipping to change at page 91, line 9
-- CRL structures -- CRL structures
CertificateList ::= SEQUENCE { CertificateList ::= SEQUENCE {
tbsCertList TBSCertList, tbsCertList TBSCertList,
signatureAlgorithm AlgorithmIdentifier, signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING } signature BIT STRING }
TBSCertList ::= SEQUENCE { TBSCertList ::= SEQUENCE {
version Version OPTIONAL, version Version OPTIONAL,
-- if present, shall be v2 -- if present, MUST be v2
signature AlgorithmIdentifier, signature AlgorithmIdentifier,
issuer Name, issuer Name,
thisUpdate Time, thisUpdate Time,
nextUpdate Time OPTIONAL, nextUpdate Time OPTIONAL,
revokedCertificates SEQUENCE OF SEQUENCE { revokedCertificates SEQUENCE OF SEQUENCE {
userCertificate CertificateSerialNumber, userCertificate CertificateSerialNumber,
revocationDate Time, revocationDate Time,
crlEntryExtensions Extensions OPTIONAL crlEntryExtensions Extensions OPTIONAL
-- if present, shall be v2 -- if present, MUST be v2
} OPTIONAL, } OPTIONAL,
crlExtensions [0] Extensions OPTIONAL crlExtensions [0] Extensions OPTIONAL
-- if present, shall be v2 -- } -- if present, MUST be v2 -- }
-- Version, Time, CertificateSerialNumber, and Extensions were -- Version, Time, CertificateSerialNumber, and Extensions were
-- defined earlier for use in the certificate structure -- defined earlier for use in the certificate structure
AlgorithmIdentifier ::= SEQUENCE { AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER, algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL } parameters ANY DEFINED BY algorithm OPTIONAL }
-- contains a value of the type -- contains a value of the type
-- registered for use with the -- registered for use with the
-- algorithm object identifier value -- algorithm object identifier value
-- x400 address syntax starts here -- x400 address syntax starts here
-- OR Names
ORAddress ::= SEQUENCE { ORAddress ::= SEQUENCE {
built-in-standard-attributes BuiltInStandardAttributes, built-in-standard-attributes BuiltInStandardAttributes,
built-in-domain-defined-attributes built-in-domain-defined-attributes
BuiltInDomainDefinedAttributes OPTIONAL, BuiltInDomainDefinedAttributes OPTIONAL,
-- see also teletex-domain-defined-attributes -- see also teletex-domain-defined-attributes
extension-attributes ExtensionAttributes OPTIONAL } extension-attributes ExtensionAttributes OPTIONAL }
-- The OR-address is semantically absent from the OR-name if the
-- built-in-standard-attribute sequence is empty and the
-- built-in-domain-defined-attributes and extension-attributes are
-- both omitted.
-- Built-in Standard Attributes
BuiltInStandardAttributes ::= SEQUENCE { BuiltInStandardAttributes ::= SEQUENCE {
country-name CountryName OPTIONAL, country-name CountryName OPTIONAL,
administration-domain-name AdministrationDomainName OPTIONAL, administration-domain-name AdministrationDomainName OPTIONAL,
network-address [0] NetworkAddress OPTIONAL, network-address [0] NetworkAddress OPTIONAL,
-- see also extended-network-address -- see also extended-network-address
terminal-identifier [1] TerminalIdentifier OPTIONAL, terminal-identifier [1] TerminalIdentifier OPTIONAL,
private-domain-name [2] PrivateDomainName OPTIONAL, private-domain-name [2] PrivateDomainName OPTIONAL,
organization-name [3] OrganizationName OPTIONAL, organization-name [3] OrganizationName OPTIONAL,
-- see also teletex-organization-name -- see also teletex-organization-name
numeric-user-identifier [4] NumericUserIdentifier OPTIONAL, numeric-user-identifier [4] NumericUserIdentifier OPTIONAL,
personal-name [5] PersonalName OPTIONAL, personal-name [5] PersonalName OPTIONAL,
-- see also teletex-personal-name -- see also teletex-personal-name
organizational-unit-names [6] OrganizationalUnitNames OPTIONAL organizational-unit-names [6] OrganizationalUnitNames OPTIONAL
-- see also teletex-organizational-unit-names -- } -- see also teletex-organizational-unit-names -- }
CountryName ::= [APPLICATION 1] CHOICE { CountryName ::= [APPLICATION 1] CHOICE {
x121-dcc-code NumericString x121-dcc-code NumericString
(SIZE (ub-country-name-numeric-length)), (SIZE (ub-country-name-numeric-length)),
iso-3166-alpha2-code PrintableString iso-3166-alpha2-code PrintableString
(SIZE (ub-country-name-alpha-length)) } (SIZE (ub-country-name-alpha-length)) }
AdministrationDomainName ::= [APPLICATION 2] CHOICE { AdministrationDomainName ::= [APPLICATION 2] CHOICE {
numeric NumericString (SIZE (0..ub-domain-name-length)), numeric NumericString (SIZE (0..ub-domain-name-length)),
printable PrintableString (SIZE (0..ub-domain-name-length)) } printable PrintableString (SIZE (0..ub-domain-name-length)) }
NetworkAddress ::= X121Address -- see also extended-network-address NetworkAddress ::= X121Address -- see also extended-network-address
X121Address ::= NumericString (SIZE (1..ub-x121-address-length)) X121Address ::= NumericString (SIZE (1..ub-x121-address-length))
TerminalIdentifier ::= PrintableString (SIZE (1..ub-terminal-id-length)) TerminalIdentifier ::= PrintableString (SIZE (1..ub-terminal-id-length))
skipping to change at page 92, line 38 skipping to change at page 92, line 46
OrganizationName ::= PrintableString OrganizationName ::= PrintableString
(SIZE (1..ub-organization-name-length)) (SIZE (1..ub-organization-name-length))
-- see also teletex-organization-name -- see also teletex-organization-name
NumericUserIdentifier ::= NumericString NumericUserIdentifier ::= NumericString
(SIZE (1..ub-numeric-user-id-length)) (SIZE (1..ub-numeric-user-id-length))
PersonalName ::= SET { PersonalName ::= SET {
surname [0] PrintableString (SIZE (1..ub-surname-length)), surname [0] PrintableString (SIZE (1..ub-surname-length)),
given-name [1] PrintableString given-name [1] PrintableString
(SIZE (1..ub-given-name-length)) OPTIONAL, (SIZE (1..ub-given-name-length)) OPTIONAL,
initials [2] PrintableString (SIZE (1..ub-initials-length)) OPTIONAL, initials [2] PrintableString (SIZE (1..ub-initials-length)) OPTIONAL,
generation-qualifier [3] PrintableString generation-qualifier [3] PrintableString
(SIZE (1..ub-generation-qualifier-length)) OPTIONAL } (SIZE (1..ub-generation-qualifier-length)) OPTIONAL }
-- see also teletex-personal-name -- see also teletex-personal-name
OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units) OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units)
OF OrganizationalUnitName OF OrganizationalUnitName
-- see also teletex-organizational-unit-names -- see also teletex-organizational-unit-names
OrganizationalUnitName ::= PrintableString (SIZE OrganizationalUnitName ::= PrintableString (SIZE
(1..ub-organizational-unit-name-length)) (1..ub-organizational-unit-name-length))
-- Built-in Domain-defined Attributes
BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE
(1..ub-domain-defined-attributes) OF (1..ub-domain-defined-attributes) OF
BuiltInDomainDefinedAttribute BuiltInDomainDefinedAttribute
BuiltInDomainDefinedAttribute ::= SEQUENCE { BuiltInDomainDefinedAttribute ::= SEQUENCE {
type PrintableString (SIZE type PrintableString (SIZE
(1..ub-domain-defined-attribute-type-length)), (1..ub-domain-defined-attribute-type-length)),
value PrintableString (SIZE value PrintableString (SIZE
(1..ub-domain-defined-attribute-value-length))} (1..ub-domain-defined-attribute-value-length))}
-- Extension Attributes
ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) OF ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) OF
ExtensionAttribute ExtensionAttribute
ExtensionAttribute ::= SEQUENCE { ExtensionAttribute ::= SEQUENCE {
extension-attribute-type [0] INTEGER (0..ub-extension-attributes), extension-attribute-type [0] INTEGER (0..ub-extension-attributes),
extension-attribute-value [1] extension-attribute-value [1]
ANY DEFINED BY extension-attribute-type } ANY DEFINED BY extension-attribute-type }
-- Extension types and attribute values -- Extension types and attribute values
-- --
common-name INTEGER ::= 1 common-name INTEGER ::= 1
skipping to change at page 94, line 4 skipping to change at page 94, line 12
TeletexPersonalName ::= SET { TeletexPersonalName ::= SET {
surname [0] TeletexString (SIZE (1..ub-surname-length)), surname [0] TeletexString (SIZE (1..ub-surname-length)),
given-name [1] TeletexString given-name [1] TeletexString
(SIZE (1..ub-given-name-length)) OPTIONAL, (SIZE (1..ub-given-name-length)) OPTIONAL,
initials [2] TeletexString (SIZE (1..ub-initials-length)) OPTIONAL, initials [2] TeletexString (SIZE (1..ub-initials-length)) OPTIONAL,
generation-qualifier [3] TeletexString (SIZE generation-qualifier [3] TeletexString (SIZE
(1..ub-generation-qualifier-length)) OPTIONAL } (1..ub-generation-qualifier-length)) OPTIONAL }
teletex-organizational-unit-names INTEGER ::= 5 teletex-organizational-unit-names INTEGER ::= 5
TeletexOrganizationalUnitNames ::= SEQUENCE SIZE TeletexOrganizationalUnitNames ::= SEQUENCE SIZE
(1..ub-organizational-units) OF TeletexOrganizationalUnitName (1..ub-organizational-units) OF TeletexOrganizationalUnitName
TeletexOrganizationalUnitName ::= TeletexString TeletexOrganizationalUnitName ::= TeletexString
(SIZE (1..ub-organizational-unit-name-length)) (SIZE (1..ub-organizational-unit-name-length))
pds-name INTEGER ::= 7 pds-name INTEGER ::= 7
PDSName ::= PrintableString (SIZE (1..ub-pds-name-length)) PDSName ::= PrintableString (SIZE (1..ub-pds-name-length))
physical-delivery-country-name INTEGER ::= 8 physical-delivery-country-name INTEGER ::= 8
PhysicalDeliveryCountryName ::= CHOICE { PhysicalDeliveryCountryName ::= CHOICE {
x121-dcc-code NumericString (SIZE (ub-country-name-numeric-length)), x121-dcc-code NumericString (SIZE (ub-country-name-numeric-length)),
iso-3166-alpha2-code PrintableString iso-3166-alpha2-code PrintableString
(SIZE (ub-country-name-alpha-length)) } (SIZE (ub-country-name-alpha-length)) }
postal-code INTEGER ::= 9 postal-code INTEGER ::= 9
PostalCode ::= CHOICE { PostalCode ::= CHOICE {
numeric-code NumericString (SIZE (1..ub-postal-code-length)), numeric-code NumericString (SIZE (1..ub-postal-code-length)),
printable-code PrintableString (SIZE (1..ub-postal-code-length)) } printable-code PrintableString (SIZE (1..ub-postal-code-length)) }
physical-delivery-office-name INTEGER ::= 10 physical-delivery-office-name INTEGER ::= 10
PhysicalDeliveryOfficeName ::= PDSParameter PhysicalDeliveryOfficeName ::= PDSParameter
skipping to change at page 94, line 42 skipping to change at page 95, line 4
PhysicalDeliveryOfficeNumber ::= PDSParameter PhysicalDeliveryOfficeNumber ::= PDSParameter
extension-OR-address-components INTEGER ::= 12 extension-OR-address-components INTEGER ::= 12
ExtensionORAddressComponents ::= PDSParameter ExtensionORAddressComponents ::= PDSParameter
physical-delivery-personal-name INTEGER ::= 13 physical-delivery-personal-name INTEGER ::= 13
PhysicalDeliveryPersonalName ::= PDSParameter PhysicalDeliveryPersonalName ::= PDSParameter
physical-delivery-organization-name INTEGER ::= 14 physical-delivery-organization-name INTEGER ::= 14
PhysicalDeliveryOrganizationName ::= PDSParameter PhysicalDeliveryOrganizationName ::= PDSParameter
extension-physical-delivery-address-components INTEGER ::= 15 extension-physical-delivery-address-components INTEGER ::= 15
ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter
unformatted-postal-address INTEGER ::= 16 unformatted-postal-address INTEGER ::= 16
UnformattedPostalAddress ::= SET { UnformattedPostalAddress ::= SET {
printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines) OF printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines) OF
PrintableString (SIZE (1..ub-pds-parameter-length)) OPTIONAL, PrintableString (SIZE (1..ub-pds-parameter-length)) OPTIONAL,
teletex-string TeletexString teletex-string TeletexString
(SIZE (1..ub-unformatted-address-length)) OPTIONAL } (SIZE (1..ub-unformatted-address-length)) OPTIONAL }
street-address INTEGER ::= 17 street-address INTEGER ::= 17
StreetAddress ::= PDSParameter StreetAddress ::= PDSParameter
post-office-box-address INTEGER ::= 18 post-office-box-address INTEGER ::= 18
PostOfficeBoxAddress ::= PDSParameter PostOfficeBoxAddress ::= PDSParameter
skipping to change at page 95, line 40 skipping to change at page 95, line 50
PDSParameter ::= SET { PDSParameter ::= SET {
printable-string PrintableString printable-string PrintableString
(SIZE(1..ub-pds-parameter-length)) OPTIONAL, (SIZE(1..ub-pds-parameter-length)) OPTIONAL,
teletex-string TeletexString teletex-string TeletexString
(SIZE(1..ub-pds-parameter-length)) OPTIONAL } (SIZE(1..ub-pds-parameter-length)) OPTIONAL }
extended-network-address INTEGER ::= 22 extended-network-address INTEGER ::= 22
ExtendedNetworkAddress ::= CHOICE { ExtendedNetworkAddress ::= CHOICE {
e163-4-address SEQUENCE { e163-4-address SEQUENCE {
number [0] NumericString (SIZE (1..ub-e163-4-number-length)), number [0] NumericString (SIZE (1..ub-e163-4-number-length)),
sub-address [1] NumericString sub-address [1] NumericString
(SIZE (1..ub-e163-4-sub-address-length)) OPTIONAL }, (SIZE (1..ub-e163-4-sub-address-length)) OPTIONAL },
psap-address [0] PresentationAddress } psap-address [0] PresentationAddress }
PresentationAddress ::= SEQUENCE { PresentationAddress ::= SEQUENCE {
pSelector [0] EXPLICIT OCTET STRING OPTIONAL, pSelector [0] EXPLICIT OCTET STRING OPTIONAL,
sSelector [1] EXPLICIT OCTET STRING OPTIONAL, sSelector [1] EXPLICIT OCTET STRING OPTIONAL,
tSelector [2] EXPLICIT OCTET STRING OPTIONAL, tSelector [2] EXPLICIT OCTET STRING OPTIONAL,
nAddresses [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING } nAddresses [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING }
terminal-type INTEGER ::= 23 terminal-type INTEGER ::= 23
TerminalType ::= INTEGER { TerminalType ::= INTEGER {
telex (3), telex (3),
teletex (4), teletex (4),
g3-facsimile (5), g3-facsimile (5),
g4-facsimile (6), g4-facsimile (6),
ia5-terminal (7), ia5-terminal (7),
videotex (8) } (0..ub-integer-options) videotex (8) } (0..ub-integer-options)
-- Extension Domain-defined Attributes
teletex-domain-defined-attributes INTEGER ::= 6 teletex-domain-defined-attributes INTEGER ::= 6
TeletexDomainDefinedAttributes ::= SEQUENCE SIZE TeletexDomainDefinedAttributes ::= SEQUENCE SIZE
(1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute
TeletexDomainDefinedAttribute ::= SEQUENCE { TeletexDomainDefinedAttribute ::= SEQUENCE {
type TeletexString type TeletexString
(SIZE (1..ub-domain-defined-attribute-type-length)), (SIZE (1..ub-domain-defined-attribute-type-length)),
value TeletexString value TeletexString
(SIZE (1..ub-domain-defined-attribute-value-length)) } (SIZE (1..ub-domain-defined-attribute-value-length)) }
-- specifications of Upper Bounds MUST be regarded as mandatory
-- from Annex B of ITU-T X.411 Reference Definition of MTS Parameter -- from Annex B of ITU-T X.411 Reference Definition of MTS Parameter
-- Upper Bounds -- Upper Bounds
ub-name INTEGER ::= 32768 -- Upper Bounds
ub-common-name INTEGER ::= 64 ub-name INTEGER ::= 32768
ub-locality-name INTEGER ::= 128 ub-common-name INTEGER ::= 64
ub-state-name INTEGER ::= 128 ub-locality-name INTEGER ::= 128
ub-organization-name INTEGER ::= 64 ub-state-name INTEGER ::= 128
ub-organizational-unit-name INTEGER ::= 64 ub-organization-name INTEGER ::= 64
ub-title INTEGER ::= 64 ub-organizational-unit-name INTEGER ::= 64
ub-serialNumber INTEGER ::= 64 ub-title INTEGER ::= 64
ub-match INTEGER ::= 128 ub-serial-number INTEGER ::= 64
ub-match INTEGER ::= 128
ub-emailaddress-length INTEGER ::= 128 ub-emailaddress-length INTEGER ::= 128
ub-common-name-length INTEGER ::= 64 ub-common-name-length INTEGER ::= 64
ub-country-name-alpha-length INTEGER ::= 2 ub-country-name-alpha-length INTEGER ::= 2
ub-country-name-numeric-length INTEGER ::= 3 ub-country-name-numeric-length INTEGER ::= 3
ub-domain-defined-attributes INTEGER ::= 4 ub-domain-defined-attributes INTEGER ::= 4
ub-domain-defined-attribute-type-length INTEGER ::= 8 ub-domain-defined-attribute-type-length INTEGER ::= 8
ub-domain-defined-attribute-value-length INTEGER ::= 128 ub-domain-defined-attribute-value-length INTEGER ::= 128
ub-domain-name-length INTEGER ::= 16 ub-domain-name-length INTEGER ::= 16
ub-extension-attributes INTEGER ::= 256 ub-extension-attributes INTEGER ::= 256
ub-e163-4-number-length INTEGER ::= 15 ub-e163-4-number-length INTEGER ::= 15
ub-e163-4-sub-address-length INTEGER ::= 40 ub-e163-4-sub-address-length INTEGER ::= 40
skipping to change at page 98, line 16 skipping to change at page 98, line 16
PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1) PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19)} security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19)}
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS ALL -- -- EXPORTS ALL --
IMPORTS IMPORTS
id-pkix, id-pe, id-qt, id-kp, id-qt-unotice, id-qt-cps, id-pe, id-kp, id-qt-unotice, id-qt-cps, id-ad,
id-ad, id-ad-ocsp, id-ad-caIssuers, -- delete following line if "new" types are supported --
-- delete following line if "new" types are supported -- BMPString, UTF8String, -- end "new" types --
BMPString, UniversalString, UTF8String, -- end "new" types ORAddress, Name, RelativeDistinguishedName,
ORAddress, Name, RelativeDistinguishedName, CertificateSerialNumber, Attribute, DirectoryString
CertificateSerialNumber, FROM PKIX1Explicit88 {iso(1) identified-organization(3)
CertificateList, AlgorithmIdentifier, ub-name, dod(6) internet(1) security(5) mechanisms(5) pkix(7)
Attribute, DirectoryString id-mod(0) id-pkix1-explicit(18)};
FROM PKIX1Explicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(1)};
-- ISO arc for standard certificate and CRL extensions -- ISO arc for standard certificate and CRL extensions
id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29}
-- authority key identifier OID and syntax -- authority key identifier OID and syntax
id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 }
AuthorityKeyIdentifier ::= SEQUENCE { AuthorityKeyIdentifier ::= SEQUENCE {
keyIdentifier [0] KeyIdentifier OPTIONAL, keyIdentifier [0] KeyIdentifier OPTIONAL,
authorityCertIssuer [1] GeneralNames OPTIONAL, authorityCertIssuer [1] GeneralNames OPTIONAL,
authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }
-- authorityCertIssuer and authorityCertSerialNumber shall both -- authorityCertIssuer and authorityCertSerialNumber MUST both
-- be present or both be absent -- be present or both be absent
KeyIdentifier ::= OCTET STRING KeyIdentifier ::= OCTET STRING
-- subject key identifier OID and syntax -- subject key identifier OID and syntax
id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 }
SubjectKeyIdentifier ::= KeyIdentifier SubjectKeyIdentifier ::= KeyIdentifier
-- key usage extension OID and syntax -- key usage extension OID and syntax
id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 }
KeyUsage ::= BIT STRING { KeyUsage ::= BIT STRING {
digitalSignature (0), digitalSignature (0),
nonRepudiation (1), nonRepudiation (1),
keyEncipherment (2), keyEncipherment (2),
dataEncipherment (3), dataEncipherment (3),
keyAgreement (4), keyAgreement (4),
keyCertSign (5), keyCertSign (5),
cRLSign (6), cRLSign (6),
encipherOnly (7), encipherOnly (7),
decipherOnly (8) } decipherOnly (8) }
-- private key usage period extension OID and syntax -- private key usage period extension OID and syntax
id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 }
PrivateKeyUsagePeriod ::= SEQUENCE { PrivateKeyUsagePeriod ::= SEQUENCE {
notBefore [0] GeneralizedTime OPTIONAL, notBefore [0] GeneralizedTime OPTIONAL,
notAfter [1] GeneralizedTime OPTIONAL } notAfter [1] GeneralizedTime OPTIONAL }
-- either notBefore or notAfter shall be present -- either notBefore or notAfter MUST be present
-- certificate policies extension OID and syntax -- certificate policies extension OID and syntax
id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 }
anyPolicy OBJECT IDENTIFIER ::= {id-ce-certificatePolicies 0} anyPolicy OBJECT IDENTIFIER ::= {id-ce-certificatePolicies 0}
CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
PolicyInformation ::= SEQUENCE { PolicyInformation ::= SEQUENCE {
policyIdentifier CertPolicyId, policyIdentifier CertPolicyId,
policyQualifiers SEQUENCE SIZE (1..MAX) OF policyQualifiers SEQUENCE SIZE (1..MAX) OF
PolicyQualifierInfo OPTIONAL } PolicyQualifierInfo OPTIONAL }
CertPolicyId ::= OBJECT IDENTIFIER CertPolicyId ::= OBJECT IDENTIFIER
PolicyQualifierInfo ::= SEQUENCE { PolicyQualifierInfo ::= SEQUENCE {
policyQualifierId PolicyQualifierId, policyQualifierId PolicyQualifierId,
qualifier ANY DEFINED BY policyQualifierId } qualifier ANY DEFINED BY policyQualifierId }
-- Implementations that recognize additional policy qualifiers MUST
-- augment the following definition for PolicyQualifierId -- augment the following definition for PolicyQualifierId
PolicyQualifierId ::= PolicyQualifierId ::=
OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )
-- CPS pointer qualifier -- CPS pointer qualifier
CPSuri ::= IA5String CPSuri ::= IA5String
-- user notice qualifier -- user notice qualifier
UserNotice ::= SEQUENCE { UserNotice ::= SEQUENCE {
noticeRef NoticeReference OPTIONAL, noticeRef NoticeReference OPTIONAL,
explicitText DisplayText OPTIONAL} explicitText DisplayText OPTIONAL}
NoticeReference ::= SEQUENCE { NoticeReference ::= SEQUENCE {
organization DisplayText, organization DisplayText,
noticeNumbers SEQUENCE OF INTEGER } noticeNumbers SEQUENCE OF INTEGER }
skipping to change at page 101, line 7 skipping to change at page 100, line 51
directoryName [4] Name, directoryName [4] Name,
ediPartyName [5] EDIPartyName, ediPartyName [5] EDIPartyName,
uniformResourceIdentifier [6] IA5String, uniformResourceIdentifier [6] IA5String,
iPAddress [7] OCTET STRING, iPAddress [7] OCTET STRING,
registeredID [8] OBJECT IDENTIFIER } registeredID [8] OBJECT IDENTIFIER }
-- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as -- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as
-- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax -- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax
AnotherName ::= SEQUENCE { AnotherName ::= SEQUENCE {
type-id OBJECT IDENTIFIER, type-id OBJECT IDENTIFIER,
value [0] EXPLICIT ANY DEFINED BY type-id } value [0] EXPLICIT ANY DEFINED BY type-id }
EDIPartyName ::= SEQUENCE { EDIPartyName ::= SEQUENCE {
nameAssigner [0] DirectoryString OPTIONAL, nameAssigner [0] DirectoryString OPTIONAL,
partyName [1] DirectoryString } partyName [1] DirectoryString }
-- issuer alternative name extension OID and syntax -- issuer alternative name extension OID and syntax
id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 }
IssuerAltName ::= GeneralNames IssuerAltName ::= GeneralNames
skipping to change at page 102, line 4 skipping to change at page 101, line 48
GeneralSubtree ::= SEQUENCE { GeneralSubtree ::= SEQUENCE {
base GeneralName, base GeneralName,
minimum [0] BaseDistance DEFAULT 0, minimum [0] BaseDistance DEFAULT 0,
maximum [1] BaseDistance OPTIONAL } maximum [1] BaseDistance OPTIONAL }
BaseDistance ::= INTEGER (0..MAX) BaseDistance ::= INTEGER (0..MAX)
-- policy constraints extension OID and syntax -- policy constraints extension OID and syntax
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)
-- CRL distribution points extension OID and syntax -- CRL distribution points extension OID and syntax
id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31} id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31}
CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
DistributionPoint ::= SEQUENCE { DistributionPoint ::= SEQUENCE {
distributionPoint [0] DistributionPointName OPTIONAL, distributionPoint [0] DistributionPointName OPTIONAL,
reasons [1] ReasonFlags OPTIONAL, reasons [1] ReasonFlags OPTIONAL,
cRLIssuer [2] GeneralNames OPTIONAL } cRLIssuer [2] GeneralNames OPTIONAL }
DistributionPointName ::= CHOICE { DistributionPointName ::= CHOICE {
fullName [0] GeneralNames, fullName [0] GeneralNames,
skipping to change at page 103, line 46 skipping to change at page 103, line 42
IssuingDistributionPoint ::= SEQUENCE { IssuingDistributionPoint ::= SEQUENCE {
distributionPoint [0] DistributionPointName OPTIONAL, distributionPoint [0] DistributionPointName OPTIONAL,
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 }
id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }
BaseCRLNumber ::= CRLNumber BaseCRLNumber ::= CRLNumber
-- CRL reasons extension OID and syntax -- CRL reasons extension OID and syntax
id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 } id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 }
CRLReason ::= ENUMERATED { CRLReason ::= ENUMERATED {
unspecified (0), unspecified (0),
keyCompromise (1), keyCompromise (1),
cACompromise (2), cACompromise (2),
affiliationChanged (3), affiliationChanged (3),
superseded (4), superseded (4),
cessationOfOperation (5), cessationOfOperation (5),
certificateHold (6), certificateHold (6),
skipping to change at page 104, line 36 skipping to change at page 104, line 30
HoldInstructionCode ::= OBJECT IDENTIFIER HoldInstructionCode ::= OBJECT IDENTIFIER
-- ANSI x9 holdinstructions -- ANSI x9 holdinstructions
-- ANSI x9 arc holdinstruction arc -- ANSI x9 arc holdinstruction arc
holdInstruction OBJECT IDENTIFIER ::= holdInstruction OBJECT IDENTIFIER ::=
{joint-iso-itu-t(2) member-body(2) us(840) x9cm(10040) 2} {joint-iso-itu-t(2) member-body(2) us(840) x9cm(10040) 2}
-- ANSI X9 holdinstructions referenced by this standard -- ANSI X9 holdinstructions referenced by this standard
id-holdinstruction-none OBJECT IDENTIFIER ::= id-holdinstruction-none OBJECT IDENTIFIER ::=
{holdInstruction 1} -- deprecated {holdInstruction 1} -- deprecated
id-holdinstruction-callissuer OBJECT IDENTIFIER ::= id-holdinstruction-callissuer OBJECT IDENTIFIER ::=
{holdInstruction 2} {holdInstruction 2}
id-holdinstruction-reject OBJECT IDENTIFIER ::= id-holdinstruction-reject OBJECT IDENTIFIER ::=
{holdInstruction 3} {holdInstruction 3}
-- invalidity date CRL entry extension OID and syntax -- invalidity date CRL entry extension OID and syntax
id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 }
InvalidityDate ::= GeneralizedTime InvalidityDate ::= GeneralizedTime
END END
Appendix B. ASN.1 Notes Appendix B. ASN.1 Notes
skipping to change at page 105, line 30 skipping to change at page 105, line 30
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.
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.
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 is the Universal
multiple-octet coded Character Set (UCS). ISO 10646-1 specifes the multiple-octet coded Character Set (UCS). ISO 10646-1 specifes the
architecture and the "basic multilingual plane" - a large standard architecture and the "basic multilingual plane" - a large standard
character set which includes all major world character standards. character set which includes all major world character standards.
The character string type UTF8String will be introduced in the 1998 The character string type UTF8String was introduced in the 1997
version of ASN.1. UTF8String is a universal type and has been version of ASN.1, and UTF8String was added to the list of choices for
assigned tag number 12. The content of UTF8String was defined by RFC DirectoryString in the 2001 version of X.520. UTF8String is a
2044 and updated in RFC 2279, "UTF-8, a transformation Format of ISO universal type and has been assigned tag number 12. The content of
10646." ISO is expected to formally add UTF8String to the list of UTF8String was defined by RFC 2044 and updated in RFC 2279, "UTF-8, a
choices for DirectoryString in 1998 as well. transformation format of ISO 10646."
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, IETF Policy on Character Sets and
Languages, this document includes UTF8String as a choice in 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, this requires ordering of the encodings of the values. In particular, this
issue arises with respect to distinguished names. issue arises with respect to distinguished names.
Object Identifiers (OIDs) are used throught this specification to Object Identifiers (OIDs) are used throught this specification to
skipping to change at page 118, line 8 skipping to change at page 118, line 8
: } : }
157 03 47: BIT STRING 0 unused bits 157 03 47: BIT STRING 0 unused bits
: 30 2C 02 14 79 1F F6 93 0B 84 06 D6 A0 7C 8D 68 : 30 2C 02 14 79 1F F6 93 0B 84 06 D6 A0 7C 8D 68
: A7 52 2E 5F 3F 89 9B 4B 02 14 66 D4 B5 2A 68 36 : A7 52 2E 5F 3F 89 9B 4B 02 14 66 D4 B5 2A 68 36
: 9B 72 88 58 E3 89 19 AD 81 89 2E 96 BB CC : 9B 72 88 58 E3 89 19 AD 81 89 2E 96 BB CC
: } : }
Appendix D. Author Addresses: Appendix D. Author Addresses:
Russell Housley Russell Housley
SPYRUS RSA Laboratories
381 Elden Street 918 Spring Knoll Drive
Suite 1120
Herndon, VA 20170 Herndon, VA 20170
USA USA
housley@spyrus.com rhousley@rsasecurity.com
Warwick Ford Warwick Ford
VeriSign, Inc. VeriSign, Inc.
One Alewife Center One Alewife Center
Cambridge, MA 02140 Cambridge, MA 02140
USA USA
wford@verisign.com wford@verisign.com
Tim Polk Tim Polk
NIST NIST
Building 820, Room 426 Building 820, Room 426
Gaithersburg, MD 20899 Gaithersburg, MD 20899
USA USA
wpolk@nist.gov wpolk@nist.gov
David Solo David Solo
Citicorp Citigroup
666 Fifth Ave, 3rd Floor 909 Third Ave, 16th Floor
New York, NY 10103 New York, NY 10043
USA USA
david.solo@citicorp.com dsolo@alum.mit.edu
Appendix E. Full Copyright Statement Appendix E. Full Copyright Statement
Copyright (C) The Internet Society (date). All Rights Reserved. Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
 End of changes. 206 change blocks. 
432 lines changed or deleted 481 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/