< draft-ietf-pkix-new-part1-04.txt   draft-ietf-pkix-new-part1-05.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 January 2001 expires in six months March 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-04.txt> <draft-ietf-pkix-new-part1-05.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 1, line 44 skipping to change at page 1, line 43
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 fourth draft of a specification based upon RFC 2459. This is the fifth draft of a specification based upon RFC 2459. When
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
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 The most significant enhancement in draft five is a refinement of the
term self-issued in section 6.1. Also, the certificate serial number processing rules for path length constraints when applied to CA
MUST be positive integers. This is not a new requirement, but the certificates. This draft also completes the removal of processing
text has been modified to use the term MUST. rules for unique identifiers. This was generally performed in the
fourth draft, but some details were overlooked. This draft also
incorporates significant corrections to the ASN.1 modules in the
appendices.
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
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.
TTTTaaaabbbblllleeee ooooffff CCCCoooonnnntttteeeennnnttttssss Table of Contents
1 Introduction ................................................ 6 1 Introduction ................................................ 6
2 Requirements and Assumptions ................................ 7 2 Requirements and Assumptions ................................ 7
2.1 Communication and Topology ................................ 7 2.1 Communication and Topology ................................ 7
2.2 Acceptability Criteria .................................... 8 2.2 Acceptability Criteria .................................... 8
2.3 User Expectations ......................................... 8 2.3 User Expectations ......................................... 8
2.4 Administrator Expectations ................................ 8 2.4 Administrator Expectations ................................ 8
3 Overview of Approach ........................................ 8 3 Overview of Approach ........................................ 8
3.1 X.509 Version 3 Certificate ............................... 10 3.1 X.509 Version 3 Certificate ............................... 10
3.2 Certification Paths and Trust ............................. 11 3.2 Certification Paths and Trust ............................. 11
skipping to change at page 5, line 8 skipping to change at page 5, line 8
6.1.5 Wrap-up procedure ........................................ 73 6.1.5 Wrap-up procedure ........................................ 73
6.1.6 Outputs .................................................. 74 6.1.6 Outputs .................................................. 74
6.2 Extending Path Validation ................................. 75 6.2 Extending Path Validation ................................. 75
6.3 CRL Validation ............................................ 75 6.3 CRL Validation ............................................ 75
6.3.1 Revocation Inputs ....................................... 76 6.3.1 Revocation Inputs ....................................... 76
6.3.2 Initialization and Revocation State Variables ........... 76 6.3.2 Initialization and Revocation State Variables ........... 76
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 ......................... 85
A.1 Explicitly Tagged Module, 1988 Syntax ...................... 84 A.1 Explicitly Tagged Module, 1988 Syntax ...................... 85
A.2 Implicitly Tagged Module, 1988 Syntax ...................... 97 A.2 Implicitly Tagged Module, 1988 Syntax ...................... 98
Appendix B. ASN.1 Notes ....................................... 104 Appendix B. ASN.1 Notes ....................................... 105
Appendix C. Examples .......................................... 105 Appendix C. Examples .......................................... 106
C.1 Certificate ............................................... 106 C.1 Certificate ............................................... 107
C.2 Certificate ............................................... 109 C.2 Certificate ............................................... 110
C.3 End-Entity Certificate Using RSA .......................... 112 C.3 End-Entity Certificate Using RSA .......................... 113
C.4 Certificate Revocation List ............................... 115 C.4 Certificate Revocation List ............................... 116
Appendix D. Author Addresses .................................. 117 Appendix D. Author Addresses .................................. 118
Appendix E. Full Copyright Statement .......................... 117 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
skipping to change at page 13, line 45 skipping to change at page 13, line 45
the revoked certificate's validity period. the revoked certificate's validity period.
An advantage of this revocation method is that CRLs may be An advantage of this revocation method is that CRLs may be
distributed by exactly the same means as certificates themselves, distributed by exactly the same means as certificates themselves,
namely, via untrusted communications and server systems. namely, via untrusted communications and server systems.
One limitation of the CRL revocation method, using untrusted One limitation of the CRL revocation method, using untrusted
communications and servers, is that the time granularity of communications and servers, is that the time granularity of
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 the next periodic CRL is notified to certificate-using systems until all currently issued CRLs
issued -- this may be up to one hour, one day, or one week depending are updated -- this may be up to one hour, one day, or one week
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
skipping to change at page 37, line 37 skipping to change at page 37, line 37
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 the keyCertSign bit in the key usage extension (see 4.2.1.3)
MUST also be asserted. If the cA bit is not asserted, then the MUST also be asserted. If the cA bit is not asserted, then the
keyCertSign bit in the key usage extension MUST NOT be asserted. keyCertSign bit 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: One end- follow this certificate in a certification path. (Note: The last
entity certificate will follow the final CA certificate in the path. certificate may be an end-entity certificate or a CA certificate.
The last certificate in a path is considered an end-entity The cA bit, or its absence, determines the type of the last
certificate, whether the subject of the certificate is a CA or not.) certificate rather than the application.) A pathLenConstraint of
A pathLenConstrinat of zero indicates that only an end-entity zero indicates that only an end-entity certificate may follow in the
certificate may follow in the path. Where it appears, the path. Where it appears, the pathLenConstraint field MUST be greater
pathLenConstraint field MUST be greater than or equal to zero. Where than or equal to zero. Where pathLenConstraint does not appear, there
pathLenConstraint does not appear, there is no limit to the allowed is no limit to the allowed length of the certification path.
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 }
skipping to change at page 46, line 44 skipping to change at page 46, line 44
several forms. Where the information is available via http, ftp, or several forms. Where the information is available via http, ftp, or
ldap, accessLocation MUST be a uniformResourceIdentifier. Where the ldap, accessLocation MUST be a uniformResourceIdentifier. Where the
information is available via the directory access protocol (dap), information is available via the directory access protocol (dap),
accessLocation MUST be a directoryName. When the information is accessLocation MUST be a directoryName. When the information is
available via electronic mail, accessLocation MUST be an rfc822Name. available via electronic mail, accessLocation MUST be an rfc822Name.
The semantics of other name forms of of accessLocation (when The semantics of other name forms of of accessLocation (when
accessMethod is id-ad-caRepository) are not defined by this accessMethod is id-ad-caRepository) are not defined by this
specification. specification.
The id-ad-timeStamping OID is used when the subject offers The id-ad-timeStamping OID is used when the subject offers
timestamping services using the Time STamp Protocol defined in [PKIX timestamping services using the Time Stamp Protocol defined in [PKIX
TSA]. Where the timestamping services are available via http or ftp, TSA]. Where the timestamping services are available via http or ftp,
accessLocation MUST be a uniformResourceIdentifier. Where the accessLocation MUST be a uniformResourceIdentifier. Where the
timestamping services are available via electronic mail, timestamping services are available via electronic mail,
accessLocation MUST be an rfc822Name. Where timestamping services accessLocation MUST be an rfc822Name. Where timestamping services
are available using TCP/IP, the dNSName and ipAddress name forms may are available using TCP/IP, the dNSName and ipAddress name forms may
be used. The semantics of other name forms of accessLocation (when be used. The semantics of other name forms of accessLocation (when
accessMethod is id-ad-timeStamping) are not defined by this accessMethod is id-ad-timeStamping) are not defined by this
specification. specification.
Additional access descriptors may be defined in other PKIX Additional access descriptors may be defined in other PKIX
skipping to change at page 65, line 44 skipping to change at page 65, line 44
(2) The certificate validity period includes time T. (2) The certificate validity period includes time T.
(3) At time T, the certificate is not revoked and is not on (3) At time T, the certificate is not revoked and is not on
hold status. This may be determined by obtaining the hold status. This may be determined by obtaining the
appropriate CRL (see section 6.3), status information, or by appropriate CRL (see section 6.3), status information, or by
out-of-band mechanisms. out-of-band mechanisms.
(4) The certificate issuer name is the working_issuer_name. (4) The certificate issuer name is the working_issuer_name.
(5) The certificate issuer unique identifier is the
working_issuer_UID, meaning:
(i) working_issuer_UID is non-null and matches the value in
the issuerUID field, or
(ii) working_issuer_UID is null and the issuerUID field is
not present.
(b) If certificate i is not self-issued, verify that the subject (b) If certificate i is not self-issued, verify that the subject
name is within one of the permitted_subtrees for X.500 name is within one of the permitted_subtrees for X.500
distinguished names, and verify that each of the alternative names distinguished names, and verify that each of the alternative names
in the subjectAltName extension (critical or non-critical) is in the subjectAltName extension (critical or non-critical) is
within one of the permitted_subtrees for that name type. within one of the permitted_subtrees for that name type.
(c) If certificate i is not self-issued, verify that the subject (c) If certificate i is not self-issued, verify that the subject
name is not within one of the excluded_subtrees for X.500 name is not within one of the excluded_subtrees for X.500
distinguished names, and verify that each of the alternative names distinguished names, and verify that each of the alternative names
in the subjectAltName extension (critical or non-critical) is not in the subjectAltName extension (critical or non-critical) is not
skipping to change at page 74, line 46 skipping to change at page 74, line 46
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.
Upon completion of all steps, path processing has succeeded if the (h) If the certificate was not self-issued, verify that
value of explicit_policy variable is greater than zero, or the max_path_length is greater than zero and decrement
valid_policy_tree is not NULL. max_path_length by 1.
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
skipping to change at page 84, line 24 skipping to change at page 85, line 24
the new UNIVERSAL types in modules using the 1988 syntax. As a the new UNIVERSAL types in modules using the 1988 syntax. As a
result, this module does not conform to either version of the ASN.1 result, this module does not conform to either version of the ASN.1
standard. standard.
This appendix may be converted into 1988 ASN.1 by replacing the This appendix may be converted into 1988 ASN.1 by replacing the
defintions for the UNIVERSAL Types with the 1988 catch-all "ANY". defintions for the UNIVERSAL Types with the 1988 catch-all "ANY".
A.1 Explicitly Tagged Module, 1988 Syntax A.1 Explicitly Tagged Module, 1988 Syntax
PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1) PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-88(1)} security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18)}
DEFINITIONS EXPLICIT TAGS ::= DEFINITIONS EXPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS ALL -- -- EXPORTS ALL --
-- IMPORTS NONE -- -- IMPORTS NONE --
-- UNIVERSAL Types defined in '93 and '98 ASN.1 -- UNIVERSAL Types defined in '93 and '98 ASN.1
skipping to change at page 87, line 51 skipping to change at page 88, line 51
-- --
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 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 } emailAddress AttributeType ::= { pkcs-9 1 }
Pkcs9email ::= IA5String (SIZE (1..ub-emailaddress-length)) Pkcs9email ::= IA5String (SIZE (1..ub-emailaddress-length))
skipping to change at page 94, line 4 skipping to change at page 94, line 50
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
skipping to change at page 97, line 7 skipping to change at page 98, line 7
-- significantly greater number of octets will be required to hold -- significantly greater number of octets will be required to hold
-- such a value. As a minimum, 16 octets, or twice the specified upper -- such a value. As a minimum, 16 octets, or twice the specified upper
-- bound, whichever is the larger, should be allowed for TeletexString. -- bound, whichever is the larger, should be allowed for TeletexString.
-- For UTF8String or UniversalString at least four times the upper -- For UTF8String or UniversalString at least four times the upper
-- bound should be allowed. -- bound should be allowed.
END END
A.2 Implicitly Tagged Module, 1988 Syntax A.2 Implicitly Tagged Module, 1988 Syntax
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-88(2)} 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-pkix, id-pe, id-qt, id-kp, id-qt-unotice, id-qt-cps,
id-ad, id-ad-ocsp, id-ad-caIssuers, id-ad, id-ad-ocsp, id-ad-caIssuers,
skipping to change at page 98, line 32 skipping to change at page 99, line 32
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 shall 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-certificate-policies 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
 End of changes. 19 change blocks. 
53 lines changed or deleted 51 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/