< draft-ietf-pkix-new-part1-03.txt   draft-ietf-pkix-new-part1-04.txt >
PKIX Working Group R. Housley (SPYRUS) PKIX Working Group R. Housley (SPYRUS)
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 November, 2000 expires in six months January 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-03.txt> <draft-ietf-pkix-new-part1-04.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 (1998). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
This is the first draft of a specification based upon RFC 2459. When This is the fourth draft of a specification based upon RFC 2459.
complete, this specification will obsolete RFC 2459. This When complete, this specification will obsolete RFC 2459. This
specification includes numerous 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
comprehensive and extremely detailed description. Details such as comprehensive and extremely detailed description. Details such as
parameter inheritance are covered thoroughly. In addition, this parameter inheritance are covered thoroughly. In addition, this
draft anticipates certain corrections proposed in the X.509 standard draft anticipates certain corrections proposed in the X.509 standard
for the policy processing aspects of path validation. for the policy processing aspects of path validation.
A new section 6.3, CRL validation, has been added as well. This A new section 6.3, CRL validation, has been added as well. This
section provides a supplement to the path validation algorithm that section provides a supplement to the path validation algorithm that
determines if a particular CRL may be used to verify the status of a determines if a particular CRL may be used to verify the status of a
particular certificate. (The basic path validation algorithm is, by particular certificate. (The basic path validation algorithm is, by
design, independent of the type and format of status information.) design, independent of the type and format of status information.)
The most significant enhancement in draft four is a definition of the
term self-issued in section 6.1. Also, the certificate serial number
MUST be positive integers. This is not a new requirement, but the
text has been modified to use the term MUST.
This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use
in the Internet. An overview of the approach and model are provided in the Internet. An overview of the approach and model are provided
as an introduction. The X.509 v3 certificate format is described in as an introduction. The X.509 v3 certificate format is described in
detail, with additional information regarding the format and detail, with additional information regarding the format and
semantics of Internet name forms (e.g., IP addresses). Standard semantics of Internet name forms (e.g., IP addresses). Standard
certificate extensions are described and one new Internet-specific certificate extensions are described and one new Internet-specific
extension is defined. A required set of certificate extensions is extension is defined. A required set of certificate extensions is
specified. The X.509 v2 CRL format is described and a required specified. The X.509 v2 CRL format is described and a required
extension set is defined as well. An algorithm for X.509 certificate extension set is defined as well. An algorithm for X.509 certificate
path validation is described. Supplemental information is provided path validation is described. Supplemental information is provided
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 TTTTaaaabbbblllleeee ooooffff CCCCoooonnnntttteeeennnnttttssss
1 Introduction ................................................ 6 1 Introduction ................................................ 6
2 Requirements and Assumptions ................................ 7 2 Requirements and Assumptions ................................ 7
2.1 Communication and Topology ................................ 7 2.1 Communication and Topology ................................ 7
2.2 Acceptability Criteria .................................... 8 2.2 Acceptability Criteria .................................... 8
2.3 User Expectations ......................................... 8 2.3 User Expectations ......................................... 8
2.4 Administrator Expectations ................................ 8 2.4 Administrator Expectations ................................ 8
3 Overview of Approach ........................................ 8 3 Overview of Approach ........................................ 8
3.1 X.509 Version 3 Certificate ............................... 10 3.1 X.509 Version 3 Certificate ............................... 10
3.2 Certification Paths and Trust ............................. 11 3.2 Certification Paths and Trust ............................. 11
skipping to change at page 3, line 37 skipping to change at page 3, line 37
4.1.2.2 Serial number ......................................... 19 4.1.2.2 Serial number ......................................... 19
4.1.2.3 Signature ............................................. 19 4.1.2.3 Signature ............................................. 19
4.1.2.4 Issuer ................................................ 19 4.1.2.4 Issuer ................................................ 19
4.1.2.5 Validity .............................................. 23 4.1.2.5 Validity .............................................. 23
4.1.2.5.1 UTCTime ............................................. 23 4.1.2.5.1 UTCTime ............................................. 23
4.1.2.5.2 GeneralizedTime ..................................... 23 4.1.2.5.2 GeneralizedTime ..................................... 23
4.1.2.6 Subject ............................................... 24 4.1.2.6 Subject ............................................... 24
4.1.2.7 Subject Public Key Info ............................... 25 4.1.2.7 Subject Public Key Info ............................... 25
4.1.2.8 Unique Identifiers .................................... 25 4.1.2.8 Unique Identifiers .................................... 25
4.1.2.9 Extensions ............................................. 25 4.1.2.9 Extensions ............................................. 25
4.2 Certificate Extensions .................................... 26 4.2 Certificate Extensions .................................... 25
4.2.1 Standard Extensions ..................................... 26 4.2.1 Standard Extensions ..................................... 26
4.2.1.1 Authority Key Identifier .............................. 27 4.2.1.1 Authority Key Identifier .............................. 27
4.2.1.2 Subject Key Identifier ................................ 27 4.2.1.2 Subject Key Identifier ................................ 27
4.2.1.3 Key Usage ............................................. 28 4.2.1.3 Key Usage ............................................. 29
4.2.1.4 Private Key Usage Period .............................. 30 4.2.1.4 Private Key Usage Period .............................. 30
4.2.1.5 Certificate Policies .................................. 31 4.2.1.5 Certificate Policies .................................. 31
4.2.1.6 Policy Mappings ....................................... 33 4.2.1.6 Policy Mappings ....................................... 33
4.2.1.7 Subject Alternative Name .............................. 34 4.2.1.7 Subject Alternative Name .............................. 34
4.2.1.8 Issuer Alternative Name ............................... 36 4.2.1.8 Issuer Alternative Name ............................... 36
4.2.1.9 Subject Directory Attributes .......................... 37 4.2.1.9 Subject Directory Attributes .......................... 37
4.2.1.10 Basic Constraints .................................... 37 4.2.1.10 Basic Constraints .................................... 37
4.2.1.11 Name Constraints ..................................... 38 4.2.1.11 Name Constraints ..................................... 38
4.2.1.12 Policy Constraints ................................... 40 4.2.1.12 Policy Constraints ................................... 40
4.2.1.13 Extended key usage field ............................. 41 4.2.1.13 Extended key usage field ............................. 41
4.2.1.14 CRL Distribution Points .............................. 42 4.2.1.14 CRL Distribution Points .............................. 42
4.2.1.15 Inhibit Any-Policy ................................... 43 4.2.1.15 Inhibit Any-Policy ................................... 43
4.2.1.16 Freshest CRL ......................................... 43 4.2.1.16 Freshest CRL ......................................... 43
4.2.2 Internet Certificate Extensions ......................... 44 4.2.2 Internet Certificate Extensions ......................... 44
4.2.2.1 Authority Information Access .......................... 44 4.2.2.1 Authority Information Access .......................... 44
4.2.2.2 Subject Information Access ............................ 45 4.2.2.2 Subject Information Access ............................ 45
5 CRL and CRL Extensions Profile .............................. 47 5 CRL and CRL Extensions Profile .............................. 47
5.1 CRL Fields ................................................ 47 5.1 CRL Fields ................................................ 47
5.1.1 CertificateList Fields .................................. 48 5.1.1 CertificateList Fields .................................. 48
5.1.1.1 tbsCertList ........................................... 48 5.1.1.1 tbsCertList ........................................... 48
5.1.1.2 signatureAlgorithm .................................... 48 5.1.1.2 signatureAlgorithm .................................... 49
5.1.1.3 signatureValue ........................................ 49 5.1.1.3 signatureValue ........................................ 49
5.1.2 Certificate List "To Be Signed" ......................... 49 5.1.2 Certificate List "To Be Signed" ......................... 49
5.1.2.1 Version ............................................... 49 5.1.2.1 Version ............................................... 49
5.1.2.2 Signature ............................................. 49 5.1.2.2 Signature ............................................. 49
5.1.2.3 Issuer Name ........................................... 50 5.1.2.3 Issuer Name ........................................... 50
5.1.2.4 This Update ........................................... 50 5.1.2.4 This Update ........................................... 50
5.1.2.5 Next Update ........................................... 50 5.1.2.5 Next Update ........................................... 50
5.1.2.6 Revoked Certificates .................................. 51 5.1.2.6 Revoked Certificates .................................. 51
5.1.2.7 Extensions ............................................ 51 5.1.2.7 Extensions ............................................ 51
5.2 CRL Extensions ............................................ 51 5.2 CRL Extensions ............................................ 51
skipping to change at page 5, line 14 skipping to change at page 5, line 14
6.3.3 CRL Processing .......................................... 77 6.3.3 CRL Processing .......................................... 77
7 References .................................................. 79 7 References .................................................. 79
8 Intellectual Property Rights ................................ 81 8 Intellectual Property Rights ................................ 81
9 Security Considerations ..................................... 81 9 Security Considerations ..................................... 81
Appendix A. ASN.1 Structures and OIDs ......................... 84 Appendix A. ASN.1 Structures and OIDs ......................... 84
A.1 Explicitly Tagged Module, 1988 Syntax ...................... 84 A.1 Explicitly Tagged Module, 1988 Syntax ...................... 84
A.2 Implicitly Tagged Module, 1988 Syntax ...................... 97 A.2 Implicitly Tagged Module, 1988 Syntax ...................... 97
Appendix B. ASN.1 Notes ....................................... 104 Appendix B. ASN.1 Notes ....................................... 104
Appendix C. Examples .......................................... 105 Appendix C. Examples .......................................... 105
C.1 Certificate ............................................... 106 C.1 Certificate ............................................... 106
C.2 Certificate ............................................... 108 C.2 Certificate ............................................... 109
C.3 End-Entity Certificate Using RSA .......................... 112 C.3 End-Entity Certificate Using RSA .......................... 112
C.4 Certificate Revocation List ............................... 115 C.4 Certificate Revocation List ............................... 115
Appendix D. Author Addresses .................................. 117 Appendix D. Author Addresses .................................. 117
Appendix E. Full Copyright Statement .......................... 117 Appendix E. Full Copyright Statement .......................... 117
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
skipping to change at page 19, line 7 skipping to change at page 19, line 7
Implementations SHOULD be prepared to accept any version certificate. Implementations SHOULD be prepared to accept any version certificate.
At a minimum, conforming implementations MUST recognize version 3 At a minimum, conforming implementations MUST recognize version 3
certificates. certificates.
Generation of version 2 certificates is not expected by Generation of version 2 certificates is not expected by
implementations based on this profile. implementations based on this profile.
4.1.2.2 Serial number 4.1.2.2 Serial number
The serial number is a positive integer assigned by the CA to each The serial number MUST be a positive integer assigned by the CA to
certificate. It MUST be unique for each certificate issued by a each certificate. It MUST be unique for each certificate issued by a
given CA (i.e., the issuer name and serial number identify a unique given CA (i.e., the issuer name and serial number identify a unique
certificate). CAs MUST force the serialNumber to be a non-negative certificate). CAs MUST force the serialNumber to be a non-negative
integer. integer.
Given the uniqueness requirements above serial numbers can be Given the uniqueness requirements above serial numbers can be
expected to contain long integers. Certificate users MUST be able to expected to contain long integers. Certificate users MUST be able to
handle serialNumber values up to 20 octets. Conformant CAs MUST NOT handle serialNumber values up to 20 octets. Conformant CAs MUST NOT
use serialNumber values longer than 20 octets. use serialNumber values longer than 20 octets.
Note: Non-conforming CAs may issue certificates with serial numbers Note: Non-conforming CAs may issue certificates with serial numbers
skipping to change at page 28, line 10 skipping to change at page 28, line 10
To facilitate chain building, this extension MUST appear in all con- To facilitate chain building, this extension MUST appear in all con-
forming CA certificates, that is, all certificates including the forming CA certificates, that is, all certificates including the
basic constraints extension (see sec. 4.2.1.10) where the value of cA basic constraints extension (see sec. 4.2.1.10) where the value of cA
is TRUE. The value of the subject key identifier MUST be the value is TRUE. The value of the subject key identifier MUST be the value
placed in the key identifier field of the Authority Key Identifier placed in the key identifier field of the Authority Key Identifier
extension (see sec. 4.2.1.1) of certificates issued by the subject of extension (see sec. 4.2.1.1) of certificates issued by the subject of
this certificate. this certificate.
For CA certificates, subject key identifiers SHOULD be derived from For CA certificates, subject key identifiers SHOULD be derived from
the public key or a method that generates unique values. Two common the public key or a method that generates unique values. The key
identifier is an explicit value placed in the certificate by the
issuer, not a value generated by a certificate user. Two common
methods for generating key identifiers from the public key are: methods for generating key identifiers from the public key are:
(1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
value of the BIT STRING subjectPublicKey (excluding the tag, value of the BIT STRING subjectPublicKey (excluding the tag,
length, and number of unused bits). length, and number of unused bits).
(2) The keyIdentifier is composed of a four bit type field with (2) The keyIdentifier is composed of a four bit type field with
the value 0100 followed by the least significant 60 bits of the the value 0100 followed by the least significant 60 bits of the
SHA-1 hash of the value of the BIT STRING subjectPublicKey. SHA-1 hash of the value of the BIT STRING subjectPublicKey.
skipping to change at page 41, line 9 skipping to change at page 41, line 9
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)
4.2.1.13 Extended key usage field 4.2.1.13 Extended key usage field
This field indicates one or more purposes for which the certified This field indicates one or more purposes for which the certified
public key may be used, in addition to or in place of the basic public key may be used, in addition to or in place of the basic
purposes indicated in the key usage extension field. This field is purposes indicated in the key usage extension field. In general,
defined as follows: this extension will appear only in end entity certificates. This
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 shall 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.
skipping to change at page 46, line 24 skipping to change at page 46, line 26
accessLocation GeneralName } accessLocation GeneralName }
Each entry in the sequence SubjectInfoAccessSyntax describes the Each entry in the sequence SubjectInfoAccessSyntax describes the
format and location of additional information provided by the subject format and location of additional information provided by the subject
of the certificate in which this extension appears. The type and of the certificate in which this extension appears. The type and
format of the information is specified by the accessMethod field; the format of the information is specified by the accessMethod field; the
accessLocation field specifies the location of the information. The accessLocation field specifies the location of the information. The
retrieval mechanism may be implied by the accessMethod or specified retrieval mechanism may be implied by the accessMethod or specified
by accessLocation. by accessLocation.
This profile defines one accessMethod to be used when the subject is This profile defines one access method to be used when the subject is
a CA, and one access mehod to be used when the subject is an end a CA, and one access method to be used when the subject is an end
entity. Additional access methods may be defined in the future in entity. Additional access methods may be defined in the future in
the protocol specifications for other services. the protocol specifications for other services.
The id-ad-caRepository OID is used when the subject is a CA, and The id-ad-caRepository OID is used when the subject is a CA, and
publishes its certificates and CRLs (if issued) in a repository. The publishes its certificates and CRLs (if issued) in a repository. The
accessLocation field is defined as a GeneralName, which can take accessLocation field is defined as a GeneralName, which can take
several forms. Where the information is available via http, ftp, or several forms. Where the information is available via http, ftp, or
ldap, accessLocation MUST be a uniformResourceIdentifier. Where the ldap, accessLocation MUST be a uniformResourceIdentifier. Where the
information is available via the directory access protocol (dap), information is available via the directory access protocol (dap),
accessLocation MUST be a directoryName. When the information is accessLocation MUST be a directoryName. When the information is
skipping to change at page 58, line 12 skipping to change at page 58, line 12
specification RECOMMENDS that implementations recognize this specification RECOMMENDS that implementations recognize this
extension. extension.
6 Certification Path Validation 6 Certification Path Validation
Certification path validation procedures for the Internet PKI are Certification path validation procedures for the Internet PKI are
based on the algorithm supplied in [X.509]. Certification path based on the algorithm supplied in [X.509]. Certification path
processing verifies the binding between the subject distinguished processing verifies the binding between the subject distinguished
name and/or subject alternative name and subject public key. The name and/or subject alternative name and subject public key. The
binding is limited by constraints which are specified in the binding is limited by constraints which are specified in the
certificates which comprise the path and the initial state variables certificates which comprise the path and inputs which are specified
which are specified by the relying party. The basic constraints and by the relying party. The basic constraints and policy constraints
policy constraints extensions allow the certification path processing extensions allow the certification path processing logic to automate
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 paths
begin with certificates issued by a "most-trusted CA". The algorithm begin with certificates issued by a "most-trusted CA". The algorithm
skipping to change at page 59, line 51 skipping to change at page 59, line 51
A particular certification path may not, however, be appropriate for A particular certification path may not, however, be appropriate for
all applications. The path validation process also determines the all applications. The path validation process also determines the
set of certificate policies that are valid for this path, based on set of certificate policies that are valid for this path, based on
the certificate policies extension, policy mapping extension, policy the certificate policies extension, policy mapping extension, policy
constraints extension, and inhibit any-policy extension. To achieve constraints extension, and inhibit any-policy extension. To achieve
this, the path validation algorithm constructs a valid policy tree. this, the path validation algorithm constructs a valid policy tree.
If the set of certificate policies that are valid for this path is If the set of certificate policies that are valid for this path is
not empty, then the result will be a valid policy tree of depth n, not empty, then the result will be a valid policy tree of depth n,
otherwise the result will be a NULL valid policy tree. otherwise the result will be a NULL valid policy tree.
A certificate is termed self-issued if the DNs that appear in the
subject and issuer fields are identical and are not empty. In
general, the issuer and subject of the certificates that make up a
path are different for each certificate. However, a CA may issue a
certificate to itself to support key rollover or changes in
certificate policies. These self-issued certificates are not counted
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 |
skipping to change at page 79, line 5 skipping to change at page 79, line 5
2. if the reasons extension is not present, set the 2. if the reasons extension is not present, set the
cert_status variable to the special value not-specified. cert_status variable to the special value not-specified.
if ((reasons_mask is all-reasons) OR (if cert_status is not if ((reasons_mask is all-reasons) OR (if cert_status is not
UNREVOKED) return cert_status UNREVOKED) return cert_status
If all CRLs named in the crl distribution points extension have If all CRLs named in the crl distribution points extension have
been exhausted, and the reasons_mask is not all-reasons and the been exhausted, and the reasons_mask is not all-reasons and the
cert_status is still UNREVOKED, the verifier must obtain cert_status is still UNREVOKED, the verifier must obtain
additional CRLs. If the additional CRLs.
The verifier must repeat the process above with the additional The verifier must repeat the process above with the additional
CRLs not specified in a distribution point. CRLs not specified in a distribution point.
If all CRLs are exhausted and the reasons_mask is not all-reasons If all CRLs are exhausted and the reasons_mask is not all-reasons
return the cert_status UNDETERMINED. return the cert_status UNDETERMINED.
7 References 7 References
[RFC 791] J. Postel, "Internet Protocol", September 1981. [RFC 791] J. Postel, "Internet Protocol", September 1981.
skipping to change at page 88, line 6 skipping to change at page 88, line 6
id-at-dnQualifier AttributeType ::= {id-at 46} id-at-dnQualifier AttributeType ::= {id-at 46}
X520dnQualifier ::= PrintableString X520dnQualifier ::= PrintableString
id-at-countryName AttributeType ::= {id-at 6} id-at-countryName AttributeType ::= {id-at 6}
X520countryName ::= PrintableString (SIZE (2)) -- IS 3166 codes X520countryName ::= PrintableString (SIZE (2)) -- IS 3166 codes
id-at-serialNumber AttributeType ::= { id-at 5 } id-at-serialNumber AttributeType ::= { id-at 5 }
X520SerialNumber PrintableString (SIZE (1..ub-serial-number)) X520SerialNumber PrintableString (SIZE (1..ub-serial-number))
-- domaincomponent and identifier from RFC 2247 -- domaincomponent and identifier from RFC 2247
id-domainComponent OBJECT IDENTIFIER := id-domainComponent OBJECT IDENTIFIER ::=
{ 0 9 2342 19200300 100 1 25 } { 0 9 2342 19200300 100 1 25 }
id-domainComponent AttributeType ::= id-domainComponent id-domainComponent AttributeType ::= id-domainComponent
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 }
 End of changes. 18 change blocks. 
24 lines changed or deleted 40 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/