+++ /dev/null
-
-
-
-
-
-
-Network Working Group R. Housley
-Request for Comments: 2459 SPYRUS
-Category: Standards Track W. Ford
- VeriSign
- W. Polk
- NIST
- D. Solo
- Citicorp
- January 1999
-
-
- Internet X.509 Public Key Infrastructure
- Certificate and CRL Profile
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
-Abstract
-
- 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
- as an introduction. The X.509 v3 certificate format is described in
- detail, with additional information regarding the format and
- semantics of Internet name forms (e.g., IP addresses). Standard
- certificate extensions are described and one new Internet-specific
- extension is defined. A required set of certificate extensions is
- specified. The X.509 v2 CRL format is described and a required
- extension set is defined as well. An algorithm for X.509 certificate
- path validation is described. Supplemental information is provided
- describing the format of public keys and digital signatures in X.509
- certificates for common Internet public key encryption algorithms
- (i.e., RSA, DSA, and Diffie-Hellman). ASN.1 modules and examples are
- provided in the appendices.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119.
-
-
-
-
-
-Housley, et. al. Standards Track [Page 1]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- Please send comments on this document to the ietf-pkix@imc.org mail
- list.
-
-
-
- T\bT\bT\bTa\ba\ba\bab\bb\bb\bbl\bl\bl\ble\be\be\be o\bo\bo\bof\bf\bf\bf C\bC\bC\bCo\bo\bo\bon\bn\bn\bnt\bt\bt\bte\be\be\ben\bn\bn\bnt\bt\bt\bts\bs\bs\bs
-
-
-
- 1 Introduction ................................................ 5
- 2 Requirements and Assumptions ................................ 6
- 2.1 Communication and Topology ................................ 6
- 2.2 Acceptability Criteria .................................... 7
- 2.3 User Expectations ......................................... 7
- 2.4 Administrator Expectations ................................ 7
- 3 Overview of Approach ........................................ 7
- 3.1 X.509 Version 3 Certificate ............................... 9
- 3.2 Certification Paths and Trust ............................. 10
- 3.3 Revocation ................................................ 12
- 3.4 Operational Protocols ..................................... 13
- 3.5 Management Protocols ...................................... 13
- 4 Certificate and Certificate Extensions Profile .............. 15
- 4.1 Basic Certificate Fields .................................. 15
- 4.1.1 Certificate Fields ...................................... 16
- 4.1.1.1 tbsCertificate ........................................ 16
- 4.1.1.2 signatureAlgorithm .................................... 16
- 4.1.1.3 signatureValue ........................................ 17
- 4.1.2 TBSCertificate .......................................... 17
- 4.1.2.1 Version ............................................... 17
- 4.1.2.2 Serial number ......................................... 18
- 4.1.2.3 Signature ............................................. 18
- 4.1.2.4 Issuer ................................................ 18
- 4.1.2.5 Validity .............................................. 21
- 4.1.2.5.1 UTCTime ............................................. 22
- 4.1.2.5.2 GeneralizedTime ..................................... 22
- 4.1.2.6 Subject ............................................... 22
- 4.1.2.7 Subject Public Key Info ............................... 23
- 4.1.2.8 Unique Identifiers .................................... 24
- 4.1.2.9 Extensions ............................................. 24
- 4.2 Certificate Extensions .................................... 24
- 4.2.1 Standard Extensions ..................................... 25
- 4.2.1.1 Authority Key Identifier .............................. 25
- 4.2.1.2 Subject Key Identifier ................................ 26
- 4.2.1.3 Key Usage ............................................. 27
- 4.2.1.4 Private Key Usage Period .............................. 29
- 4.2.1.5 Certificate Policies .................................. 29
- 4.2.1.6 Policy Mappings ....................................... 31
- 4.2.1.7 Subject Alternative Name .............................. 32
-
-
-
-Housley, et. al. Standards Track [Page 2]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- 4.2.1.8 Issuer Alternative Name ............................... 34
- 4.2.1.9 Subject Directory Attributes .......................... 34
- 4.2.1.10 Basic Constraints .................................... 35
- 4.2.1.11 Name Constraints ..................................... 35
- 4.2.1.12 Policy Constraints ................................... 37
- 4.2.1.13 Extended key usage field ............................. 38
- 4.2.1.14 CRL Distribution Points .............................. 39
- 4.2.2 Private Internet Extensions ............................. 40
- 4.2.2.1 Authority Information Access .......................... 41
- 5 CRL and CRL Extensions Profile .............................. 42
- 5.1 CRL Fields ................................................ 43
- 5.1.1 CertificateList Fields .................................. 43
- 5.1.1.1 tbsCertList ........................................... 44
- 5.1.1.2 signatureAlgorithm .................................... 44
- 5.1.1.3 signatureValue ........................................ 44
- 5.1.2 Certificate List "To Be Signed" ......................... 44
- 5.1.2.1 Version ............................................... 45
- 5.1.2.2 Signature ............................................. 45
- 5.1.2.3 Issuer Name ........................................... 45
- 5.1.2.4 This Update ........................................... 45
- 5.1.2.5 Next Update ........................................... 45
- 5.1.2.6 Revoked Certificates .................................. 46
- 5.1.2.7 Extensions ............................................ 46
- 5.2 CRL Extensions ............................................ 46
- 5.2.1 Authority Key Identifier ................................ 47
- 5.2.2 Issuer Alternative Name ................................. 47
- 5.2.3 CRL Number .............................................. 47
- 5.2.4 Delta CRL Indicator ..................................... 48
- 5.2.5 Issuing Distribution Point .............................. 48
- 5.3 CRL Entry Extensions ...................................... 49
- 5.3.1 Reason Code ............................................. 50
- 5.3.2 Hold Instruction Code ................................... 50
- 5.3.3 Invalidity Date ......................................... 51
- 5.3.4 Certificate Issuer ...................................... 51
- 6 Certificate Path Validation ................................. 52
- 6.1 Basic Path Validation ..................................... 52
- 6.2 Extending Path Validation ................................. 56
- 7 Algorithm Support ........................................... 57
- 7.1 One-way Hash Functions .................................... 57
- 7.1.1 MD2 One-way Hash Function ............................... 57
- 7.1.2 MD5 One-way Hash Function ............................... 58
- 7.1.3 SHA-1 One-way Hash Function ............................. 58
- 7.2 Signature Algorithms ...................................... 58
- 7.2.1 RSA Signature Algorithm ................................. 59
- 7.2.2 DSA Signature Algorithm ................................. 60
- 7.3 Subject Public Key Algorithms ............................. 60
- 7.3.1 RSA Keys ................................................ 61
- 7.3.2 Diffie-Hellman Key Exchange Key ......................... 61
-
-
-
-Housley, et. al. Standards Track [Page 3]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- 7.3.3 DSA Signature Keys ...................................... 63
- 8 References .................................................. 64
- 9 Intellectual Property Rights ................................ 66
- 10 Security Considerations .................................... 67
- Appendix A. ASN.1 Structures and OIDs ......................... 70
- A.1 Explicitly Tagged Module, 1988 Syntax ...................... 70
- A.2 Implicitly Tagged Module, 1988 Syntax ...................... 84
- Appendix B. 1993 ASN.1 Structures and OIDs .................... 91
- B.1 Explicitly Tagged Module, 1993 Syntax ...................... 91
- B.2 Implicitly Tagged Module, 1993 Syntax ...................... 108
- Appendix C. ASN.1 Notes ....................................... 116
- Appendix D. Examples .......................................... 117
- D.1 Certificate ............................................... 117
- D.2 Certificate ............................................... 120
- D.3 End-Entity Certificate Using RSA .......................... 123
- D.4 Certificate Revocation List ............................... 126
- Appendix E. Authors' Addresses ................................ 128
- Appendix F. Full Copyright Statement .......................... 129
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Housley, et. al. Standards Track [Page 4]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-1 Introduction
-
- This specification is one part of a family of standards for the X.509
- Public Key Infrastructure (PKI) for the Internet. This specification
- is a standalone document; implementations of this standard may
- proceed independent from the other parts.
-
- This specification profiles the format and semantics of certificates
- and certificate revocation lists for the Internet PKI. Procedures
- are described for processing of certification paths in the Internet
- environment. Encoding rules are provided for popular cryptographic
- algorithms. Finally, ASN.1 modules are provided in the appendices
- for all data structures defined or referenced.
-
- The specification describes the requirements which inspire the
- creation of this document and the assumptions which affect its scope
- in Section 2. Section 3 presents an architectural model and
- describes its relationship to previous IETF and ISO/IEC/ITU
- standards. In particular, this document's relationship with the IETF
- PEM specifications and the ISO/IEC/ITU X.509 documents are described.
-
- The specification profiles the X.509 version 3 certificate in Section
- 4, and the X.509 version 2 certificate revocation list (CRL) in
- Section 5. The profiles include the identification of ISO/IEC/ITU and
- ANSI extensions which may be useful in the Internet PKI. The profiles
- are presented in the 1988 Abstract Syntax Notation One (ASN.1) rather
- than the 1994 syntax used in the ISO/IEC/ITU standards.
-
- This specification also includes path validation procedures in
- Section 6. These procedures are based upon the ISO/IEC/ITU
- definition, but the presentation assumes one or more self-signed
- trusted CA certificates. Implementations are required to derive the
- same results but are not required to use the specified procedures.
-
- Section 7 of the specification describes procedures for
- identification and encoding of public key materials and digital
- signatures. Implementations are not required to use any particular
- cryptographic algorithms. However, conforming implementations which
- use the identified algorithms are required to identify and encode the
- public key materials and digital signatures as described.
-
- Finally, four appendices are provided to aid implementers. Appendix
- A contains all ASN.1 structures defined or referenced within this
- specification. As above, the material is presented in the 1988
- Abstract Syntax Notation One (ASN.1) rather than the 1994 syntax.
- Appendix B contains the same information in the 1994 ASN.1 notation
- as a service to implementers using updated toolsets. However,
- Appendix A takes precedence in case of conflict. Appendix C contains
-
-
-
-Housley, et. al. Standards Track [Page 5]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- notes on less familiar features of the ASN.1 notation used within
- this specification. Appendix D contains examples of a conforming
- certificate and a conforming CRL.
-
-2 Requirements and Assumptions
-
- The goal of this specification is to develop a profile to facilitate
- the use of X.509 certificates within Internet applications for those
- communities wishing to make use of X.509 technology. Such
- applications may include WWW, electronic mail, user authentication,
- and IPsec. In order to relieve some of the obstacles to using X.509
- certificates, this document defines a profile to promote the
- development of certificate management systems; development of
- application tools; and interoperability determined by policy.
-
- Some communities will need to supplement, or possibly replace, this
- profile in order to meet the requirements of specialized application
- domains or environments with additional authorization, assurance, or
- operational requirements. However, for basic applications, common
- representations of frequently used attributes are defined so that
- application developers can obtain necessary information without
- regard to the issuer of a particular certificate or certificate
- revocation list (CRL).
-
- A certificate user should review the certificate policy generated by
- the certification authority (CA) before relying on the authentication
- or non-repudiation services associated with the public key in a
- particular certificate. To this end, this standard does not
- prescribe legally binding rules or duties.
-
- As supplemental authorization and attribute management tools emerge,
- such as attribute certificates, it may be appropriate to limit the
- authenticated attributes that are included in a certificate. These
- other management tools may provide more appropriate methods of
- conveying many authenticated attributes.
-
-2.1 Communication and Topology
-
- The users of certificates will operate in a wide range of
- environments with respect to their communication topology, especially
- users of secure electronic mail. This profile supports users without
- high bandwidth, real-time IP connectivity, or high connection
- availability. In addition, the profile allows for the presence of
- firewall or other filtered communication.
-
-
-
-
-
-
-
-Housley, et. al. Standards Track [Page 6]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- 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,
- but other means of distributing certificates and certificate
- revocation lists (CRLs) may be used.
-
-2.2 Acceptability Criteria
-
- The goal of the Internet Public Key Infrastructure (PKI) is to meet
- the needs of deterministic, automated identification, authentication,
- access control, and authorization functions. Support for these
- services determines the attributes contained in the certificate as
- well as the ancillary control information in the certificate such as
- policy data and certification path constraints.
-
-2.3 User Expectations
-
- Users of the Internet PKI are people and processes who use client
- software and are the subjects named in certificates. These uses
- include readers and writers of electronic mail, the clients for WWW
- browsers, WWW servers, and the key manager for IPsec within a router.
- This profile recognizes the limitations of the platforms these users
- employ and the limitations in sophistication and attentiveness of the
- users themselves. This manifests itself in minimal user
- configuration responsibility (e.g., trusted CA keys, rules), explicit
- platform usage constraints within the certificate, certification path
- constraints which shield the user from many malicious actions, and
- applications which sensibly automate validation functions.
-
-2.4 Administrator Expectations
-
- As with user expectations, the Internet PKI profile is structured to
- support the individuals who generally operate CAs. Providing
- administrators with unbounded choices increases the chances that a
- subtle CA administrator mistake will result in broad compromise.
- Also, unbounded choices greatly complicate the software that shall
- process and validate the certificates created by the CA.
-
-3 Overview of Approach
-
- Following is a simplified view of the architectural model assumed by
- the PKIX specifications.
-
-
-
-
-
-
-
-
-
-
-Housley, et. al. Standards Track [Page 7]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- +---+
- | C | +------------+
- | e | <-------------------->| End entity |
- | r | Operational +------------+
- | t | transactions ^
- | | and management | Management
- | / | transactions | transactions
- | | | PKI users
- | C | v
- | R | -------------------+--+-----------+----------------
- | L | ^ ^
- | | | | PKI management
- | | v | entities
- | R | +------+ |
- | e | <---------------------| RA | <---+ |
- | p | Publish certificate +------+ | |
- | o | | |
- | s | | |
- | I | v v
- | t | +------------+
- | o | <------------------------------| CA |
- | r | Publish certificate +------------+
- | y | Publish CRL ^
- | | |
- +---+ Management |
- transactions |
- v
- +------+
- | CA |
- +------+
-
- Figure 1 - PKI Entities
-
- The components in this model are:
-
- end entity: user of PKI certificates and/or end user system that
- is the subject of a certificate;
- CA: certification authority;
- RA: registration authority, i.e., an optional system to
- which a CA delegates certain management functions;
- repository: a system or collection of distributed systems that
- store certificates and CRLs and serves as a means of
- distributing these certificates and CRLs to end
- entities.
-
-
-
-
-
-
-
-Housley, et. al. Standards Track [Page 8]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-3.1 X.509 Version 3 Certificate
-
- Users of a public key shall be confident that the associated private
- key is owned by the correct remote subject (person or system) with
- which an encryption or digital signature mechanism will be used.
- This confidence is obtained through the use of public key
- certificates, which are data structures that bind public key values
- to subjects. The binding is asserted by having a trusted CA
- digitally sign each certificate. The CA may base this assertion upon
- technical means (a.k.a., proof of posession through a challenge-
- response protocol), presentation of the private key, or on an
- assertion by the subject. A certificate has a limited valid lifetime
- which is indicated in its signed contents. Because a certificate's
- signature and timeliness can be independently checked by a
- certificate-using client, certificates can be distributed via
- untrusted communications and server systems, and can be cached in
- unsecured storage in certificate-using systems.
-
- 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
- recommendations, defines a standard certificate format [X.509]. The
- 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,
- resulting in the version 2 (v2) format. These two fields may be used
- to support directory access control.
-
- The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993,
- include specifications for a public key infrastructure based on X.509
- v1 certificates [RFC 1422]. The experience gained in attempts to
- deploy RFC 1422 made it clear that the v1 and v2 certificate formats
- are deficient in several respects. Most importantly, more fields
- were needed to carry information which PEM design and implementation
- experience has proven necessary. In response to these new
- requirements, ISO/IEC/ITU and ANSI X9 developed the X.509 version 3
- (v3) certificate format. The v3 format extends the v2 format by
- adding provision for additional extension fields. Particular
- extension field types may be specified in standards or may be defined
- and registered by any organization or community. In June 1996,
- standardization of the basic v3 format was completed [X.509].
-
- 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
- convey such data as additional subject identification information,
- key attribute information, policy information, and certification path
- constraints.
-
-
-
-
-
-
-Housley, et. al. Standards Track [Page 9]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- However, the ISO/IEC/ITU and ANSI X9 standard extensions are very
- broad in their applicability. In order to develop interoperable
- implementations of X.509 v3 systems for Internet use, it is necessary
- to specify a profile for use of the X.509 v3 extensions tailored for
- the Internet. It is one goal of this document to specify a profile
- for Internet WWW, electronic mail, and IPsec applications.
- Environments with additional requirements may build on this profile
- or may replace it.
-
-3.2 Certification Paths and Trust
-
- A user of a security service requiring knowledge of a public key
- generally needs to obtain and validate a certificate containing the
- required public key. If the public-key user does not already hold an
- assured copy of the public key of the CA that signed the certificate,
- the CA's name, and related information (such as the validity period
- or name constraints), then it might need an additional certificate to
- obtain that public key. In general, a chain of multiple certificates
- may be needed, comprising a certificate of the public key owner (the
- end entity) signed by one CA, and zero or more additional
- certificates of CAs signed by other CAs. Such chains, called
- certification paths, are required because a public key user is only
- initialized with a limited number of assured CA public keys.
-
- There are different ways in which CAs might be configured in order
- for public key users to be able to find certification paths. For
- PEM, RFC 1422 defined a rigid hierarchical structure of CAs. There
- are three types of PEM certification authority:
-
- (a) Internet Policy Registration Authority (IPRA): This
- authority, operated under the auspices of the Internet Society,
- acts as the root of the PEM certification hierarchy at level 1.
- It issues certificates only for the next level of authorities,
- PCAs. All certification paths start with the IPRA.
-
- (b) Policy Certification Authorities (PCAs): PCAs are at level 2
- of the hierarchy, each PCA being certified by the IPRA. A PCA
- shall establish and publish a statement of its policy with respect
- to certifying users or subordinate certification authorities.
- Distinct PCAs aim to satisfy different user needs. For example,
- one PCA (an organizational PCA) might support the general
- electronic mail needs of commercial organizations, and another PCA
- (a high-assurance PCA) might have a more stringent policy designed
- for satisfying legally binding digital signature requirements.
-
-
-
-
-
-
-
-Housley, et. al. Standards Track [Page 10]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- (c) Certification Authorities (CAs): CAs are at level 3 of the
- hierarchy and can also be at lower levels. Those at level 3 are
- certified by PCAs. CAs represent, for example, particular
- organizations, particular organizational units (e.g., departments,
- groups, sections), or particular geographical areas.
-
- RFC 1422 furthermore has a name subordination rule which requires
- 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.
- The trust associated with a PEM certification path is implied by the
- PCA name. The name subordination rule ensures that CAs below the PCA
- are sensibly constrained as to the set of subordinate entities they
- can certify (e.g., a CA for an organization can only certify entities
- in that organization's name tree). Certificate user systems are able
- to mechanically check that the name subordination rule has been
- followed.
-
- The RFC 1422 uses the X.509 v1 certificate formats. The limitations
- of X.509 v1 required imposition of several structural restrictions to
- clearly associate policy information or restrict the utility of
- certificates. These restrictions included:
-
- (a) a pure top-down hierarchy, with all certification paths
- starting from IPRA;
-
- (b) a naming subordination rule restricting the names of a CA's
- subjects; and
-
- (c) use of the PCA concept, which requires knowledge of individual
- PCAs to be built into certificate chain verification logic.
- Knowledge of individual PCAs was required to determine if a chain
- could be accepted.
-
- With X.509 v3, most of the requirements addressed by RFC 1422 can be
- addressed using certificate extensions, without a need to restrict
- the CA structures used. In particular, the certificate extensions
- relating to certificate policies obviate the need for PCAs and the
- constraint extensions obviate the need for the name subordination
- rule. As a result, this document supports a more flexible
- architecture, including:
-
- (a) Certification paths may start with a public key of a CA in a
- user's own domain, or with the public key of the top of a
- hierarchy. Starting with the public key of a CA in a user's own
- domain has certain advantages. In some environments, the local
- domain is the most trusted.
-
-
-
-
-
-Housley, et. al. Standards Track [Page 11]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- (b) Name constraints may be imposed through explicit inclusion of
- a name constraints extension in a certificate, but are not
- required.
-
- (c) Policy extensions and policy mappings replace the PCA
- concept, which permits a greater degree of automation. The
- application can determine if the certification path is acceptable
- based on the contents of the certificates instead of a priori
- knowledge of PCAs. This permits automation of certificate chain
- processing.
-
-3.3 Revocation
-
- When a certificate is issued, it is expected to be in use for its
- entire validity period. However, various circumstances may cause a
- certificate to become invalid prior to the expiration of the validity
- period. Such circumstances include change of name, change of
- association between subject and CA (e.g., an employee terminates
- employment with an organization), and compromise or suspected
- compromise of the corresponding private key. Under such
- circumstances, the CA needs to revoke the certificate.
-
- X.509 defines one method of certificate revocation. This method
- involves each CA periodically issuing a signed data structure called
- a certificate revocation list (CRL). A CRL is a time stamped list
- identifying revoked certificates which is signed by a CA and made
- freely available in a public repository. Each revoked certificate is
- identified in a CRL by its certificate serial number. When a
- certificate-using system uses a certificate (e.g., for verifying a
- remote user's digital signature), that system not only checks the
- certificate signature and validity but also acquires a suitably-
- recent CRL and checks that the certificate serial number is not on
- that CRL. The meaning of "suitably-recent" may vary with local
- 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
- weekly). An entry is added to the CRL as part of the next update
- following notification of revocation. An entry may be removed from
- the CRL after appearing on one regularly scheduled CRL issued beyond
- the revoked certificate's validity period.
-
- An advantage of this revocation method is that CRLs may be
- distributed by exactly the same means as certificates themselves,
- namely, via untrusted communications and server systems.
-
- One limitation of the CRL revocation method, using untrusted
- communications and servers, is that the time granularity of
- revocation is limited to the CRL issue period. For example, if a
- revocation is reported now, that revocation will not be reliably
-
-
-
-Housley, et. al. Standards Track [Page 12]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- notified to certificate-using systems until the next periodic CRL is
- issued -- this may be up to one hour, one day, or one week depending
- on the frequency that the CA issues CRLs.
-
- As with the X.509 v3 certificate format, in order to facilitate
- interoperable implementations from multiple vendors, the X.509 v2 CRL
- format needs to be profiled for Internet use. It is one goal of this
- document to specify that profile. However, this profile does not
- require CAs to issue CRLs. Message formats and protocols supporting
- on-line revocation notification may be defined in other PKIX
- specifications. On-line methods of revocation notification may be
- applicable in some environments as an alternative to the X.509 CRL.
- On-line revocation checking may significantly reduce the latency
- between a revocation report and the distribution of the information
- to relying parties. Once the CA accepts the report as authentic and
- valid, any query to the on-line service will correctly reflect the
- certificate validation impacts of the revocation. However, these
- methods impose new security requirements; the certificate validator
- shall trust the on-line validation service while the repository does
- not need to be trusted.
-
-3.4 Operational Protocols
-
- Operational protocols are required to deliver certificates and CRLs
- (or status information) to certificate using client systems.
- Provision is needed for a variety of different means of certificate
- and CRL delivery, including distribution procedures based on LDAP,
- HTTP, FTP, and X.500. Operational protocols supporting these
- functions are defined in other PKIX specifications. These
- specifications may include definitions of message formats and
- procedures for supporting all of the above operational environments,
- including definitions of or references to appropriate MIME content
- types.
-
-3.5 Management Protocols
-
- Management protocols are required to support on-line interactions
- between PKI user and management entities. For example, a management
- protocol might be used between a CA and a client system with which a
- key pair is associated, or between two CAs which cross-certify each
- other. The set of functions which potentially need to be supported
- by management protocols include:
-
- (a) registration: This is the process whereby a user first makes
- itself known to a CA (directly, or through an RA), prior to that
- CA issuing a certificate or certificates for that user.
-
-
-
-
-
-Housley, et. al. Standards Track [Page 13]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- (b) initialization: Before a client system can operate securely
- it is necessary to install key materials which have the
- appropriate relationship with keys stored elsewhere in the
- infrastructure. For example, the client needs to be securely
- initialized with the public key and other assured information of
- the trusted CA(s), to be used in validating certificate paths.
- Furthermore, a client typically needs to be initialized with its
- own key pair(s).
-
- (c) certification: This is the process in which a CA issues a
- certificate for a user's public key, and returns that certificate
- to the user's client system and/or posts that certificate in a
- repository.
-
- (d) key pair recovery: As an option, user client key materials
- (e.g., a user's private key used for encryption purposes) may be
- backed up by a CA or a key backup system. If a user needs to
- recover these backed up key materials (e.g., as a result of a
- forgotten password or a lost key chain file), an on-line protocol
- exchange may be needed to support such recovery.
-
- (e) key pair update: All key pairs need to be updated regularly,
- i.e., replaced with a new key pair, and new certificates issued.
-
- (f) revocation request: An authorized person advises a CA of an
- abnormal situation requiring certificate revocation.
-
- (g) cross-certification: Two CAs exchange information used in
- establishing a cross-certificate. A cross-certificate is a
- certificate issued by one CA to another CA which contains a CA
- signature key used for issuing certificates.
-
- Note that on-line protocols are not the only way of implementing the
- above functions. For all functions there are off-line methods of
- achieving the same result, and this specification does not mandate
- use of on-line protocols. For example, when hardware tokens are
- used, many of the functions may be achieved as part of the physical
- token delivery. Furthermore, some of the above functions may be
- combined into one protocol exchange. In particular, two or more of
- the registration, initialization, and certification functions can be
- combined into one protocol exchange.
-
- The PKIX series of specifications may define a set of standard
- message formats supporting the above functions in future
- specifications. In that case, the protocols for conveying these
- messages in different environments (e.g., on-line, file transfer, e-
- mail, and WWW) will also be described in those specifications.
-
-
-
-
-Housley, et. al. Standards Track [Page 14]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-4 Certificate and Certificate Extensions Profile
-
- This section presents a profile for public key certificates that will
- foster interoperability and a reusable PKI. This section is based
- upon the X.509 v3 certificate format and the standard certificate
- extensions defined in [X.509]. The ISO/IEC/ITU documents use the
- 1993 version of ASN.1; while this document uses the 1988 ASN.1
- syntax, the encoded certificate and standard extensions are
- equivalent. This section also defines private extensions required to
- support a PKI for the Internet community.
-
- Certificates may be used in a wide range of applications and
- environments covering a broad spectrum of interoperability goals and
- a broader spectrum of operational and assurance requirements. The
- goal of this document is to establish a common baseline for generic
- applications requiring broad interoperability and limited special
- purpose requirements. In particular, the emphasis will be on
- supporting the use of X.509 v3 certificates for informal Internet
- electronic mail, IPsec, and WWW applications.
-
-4.1 Basic Certificate Fields
-
- The X.509 v3 certificate basic syntax is as follows. For signature
- calculation, the certificate is encoded using the ASN.1 distinguished
- encoding rules (DER) [X.208]. ASN.1 DER encoding is a tag, length,
- value encoding system for each element.
-
- Certificate ::= SEQUENCE {
- tbsCertificate TBSCertificate,
- signatureAlgorithm AlgorithmIdentifier,
- signatureValue BIT STRING }
-
- TBSCertificate ::= SEQUENCE {
- version [0] EXPLICIT Version DEFAULT v1,
- serialNumber CertificateSerialNumber,
- signature AlgorithmIdentifier,
- issuer Name,
- validity Validity,
- subject Name,
- subjectPublicKeyInfo SubjectPublicKeyInfo,
- issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
- -- If present, version shall be v2 or v3
- subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
- -- If present, version shall be v2 or v3
- extensions [3] EXPLICIT Extensions OPTIONAL
- -- If present, version shall be v3
- }
-
-
-
-
-Housley, et. al. Standards Track [Page 15]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- Version ::= INTEGER { v1(0), v2(1), v3(2) }
-
- CertificateSerialNumber ::= INTEGER
-
- Validity ::= SEQUENCE {
- notBefore Time,
- notAfter Time }
-
- Time ::= CHOICE {
- utcTime UTCTime,
- generalTime GeneralizedTime }
-
- UniqueIdentifier ::= BIT STRING
-
- SubjectPublicKeyInfo ::= SEQUENCE {
- algorithm AlgorithmIdentifier,
- subjectPublicKey BIT STRING }
-
- Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
-
- Extension ::= SEQUENCE {
- extnID OBJECT IDENTIFIER,
- critical BOOLEAN DEFAULT FALSE,
- extnValue OCTET STRING }
-
- The following items describe the X.509 v3 certificate for use in the
- Internet.
-
-4.1.1 Certificate Fields
-
- The Certificate is a SEQUENCE of three required fields. The fields
- are described in detail in the following subsections.
-
-4.1.1.1 tbsCertificate
-
- The field contains the names of the subject and issuer, a public key
- associated with the subject, a validity period, and other associated
- information. The fields are described in detail in section 4.1.2;
- the tbscertificate may also include extensions which are described in
- section 4.2.
-
-4.1.1.2 signatureAlgorithm
-
- The signatureAlgorithm field contains the identifier for the
- cryptographic algorithm used by the CA to sign this certificate.
- Section 7.2 lists the supported signature algorithms.
-
- An algorithm identifier is defined by the following ASN.1 structure:
-
-
-
-Housley, et. al. Standards Track [Page 16]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- AlgorithmIdentifier ::= SEQUENCE {
- algorithm OBJECT IDENTIFIER,
- parameters ANY DEFINED BY algorithm OPTIONAL }
-
- The algorithm identifier is used to identify a cryptographic
- algorithm. The OBJECT IDENTIFIER component identifies the algorithm
- (such as DSA with SHA-1). The contents of the optional parameters
- field will vary according to the algorithm identified. Section 7.2
- lists the supported algorithms for this specification.
-
- This field MUST contain the same algorithm identifier as the
- signature field in the sequence tbsCertificate (see sec. 4.1.2.3).
-
-4.1.1.3 signatureValue
-
- The signatureValue field contains a digital signature computed upon
- the ASN.1 DER encoded tbsCertificate. The ASN.1 DER encoded
- tbsCertificate 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 Certificate's signature field. The details of this process are
- specified for each of the supported algorithms in Section 7.2.
-
- By generating this signature, a CA certifies the validity of the
- information in the tbsCertificate field. In particular, the CA
- certifies the binding between the public key material and the subject
- of the certificate.
-
-4.1.2 TBSCertificate
-
- The sequence TBSCertificate contains information associated with the
- subject of the certificate and the CA who issued it. Every
- TBSCertificate contains the names of the subject and issuer, a public
- key associated with the subject, a validity period, a version number,
- and a serial number; some may contain optional unique identifier
- fields. The remainder of this section describes the syntax and
- semantics of these fields. A TBSCertificate may also include
- extensions. Extensions for the Internet PKI are described in Section
- 4.2.
-
-4.1.2.1 Version
-
- This field describes the version of the encoded certificate. When
- extensions are used, as expected in this profile, use X.509 version 3
- (value is 2). If no extensions are present, but a UniqueIdentifier
- is present, use version 2 (value is 1). If only basic fields are
- present, use version 1 (the value is omitted from the certificate as
- the default value).
-
-
-
-
-Housley, et. al. Standards Track [Page 17]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- Implementations SHOULD be prepared to accept any version certificate.
- At a minimum, conforming implementations MUST recognize version 3
- certificates.
-
- Generation of version 2 certificates is not expected by
- implementations based on this profile.
-
-4.1.2.2 Serial number
-
- The serial number is an integer assigned by the CA to 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
- certificate).
-
-4.1.2.3 Signature
-
- This field contains the algorithm identifier for the algorithm used
- by the CA to sign the certificate.
-
- This field MUST contain the same algorithm identifier as the
- signatureAlgorithm field in the sequence Certificate (see sec.
- 4.1.1.2). The contents of the optional parameters field will vary
- according to the algorithm identified. Section 7.2 lists the
- supported signature algorithms.
-
-4.1.2.4 Issuer
-
- The issuer field identifies the entity who has signed and issued the
- certificate. The issuer field MUST contain a non-empty distinguished
- name (DN). The issuer field is defined as the X.501 type Name.
- [X.501] Name is defined by the following ASN.1 structures:
-
- Name ::= CHOICE {
- RDNSequence }
-
- RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
-
- RelativeDistinguishedName ::=
- SET OF AttributeTypeAndValue
-
- AttributeTypeAndValue ::= SEQUENCE {
- type AttributeType,
- value AttributeValue }
-
- AttributeType ::= OBJECT IDENTIFIER
-
- AttributeValue ::= ANY DEFINED BY AttributeType
-
-
-
-
-Housley, et. al. Standards Track [Page 18]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- DirectoryString ::= CHOICE {
- teletexString TeletexString (SIZE (1..MAX)),
- printableString PrintableString (SIZE (1..MAX)),
- universalString UniversalString (SIZE (1..MAX)),
- utf8String UTF8String (SIZE (1.. MAX)),
- bmpString BMPString (SIZE (1..MAX)) }
-
- The Name describes a hierarchical name composed of attributes, such
- as country name, and corresponding values, such as US. The type of
- the component AttributeValue is determined by the AttributeType; in
- general it will be a DirectoryString.
-
- The DirectoryString type is defined as a choice of PrintableString,
- TeletexString, BMPString, UTF8String, and UniversalString. The
- UTF8String encoding is the preferred encoding, and all certificates
- issued after December 31, 2003 MUST use the UTF8String encoding of
- DirectoryString (except as noted below). Until that date, conforming
- CAs MUST choose from the following options when creating a
- distinguished name, including their own:
-
- (a) if the character set is sufficient, the string MAY be
- represented as a PrintableString;
-
- (b) failing (a), if the BMPString character set is sufficient the
- string MAY be represented as a BMPString; and
-
- (c) failing (a) and (b), the string MUST be represented as a
- UTF8String. If (a) or (b) is satisfied, the CA MAY still choose
- to represent the string as a UTF8String.
-
- Exceptions to the December 31, 2003 UTF8 encoding requirements are as
- follows:
-
- (a) CAs MAY issue "name rollover" certificates to support an
- orderly migration to UTF8String encoding. Such certificates would
- include the CA's UTF8String encoded name as issuer and and the old
- name encoding as subject, or vice-versa.
-
- (b) As stated in section 4.1.2.6, the subject field MUST be
- populated with a non-empty distinguished name matching the
- contents of the issuer field in all certificates issued by the
- subject CA regardless of encoding.
-
- The TeletexString and UniversalString are included for backward
- compatibility, and should not be used for certificates for new
- subjects. However, these types may be used in certificates where the
- name was previously established. Certificate users SHOULD be
- prepared to receive certificates with these types.
-
-
-
-Housley, et. al. Standards Track [Page 19]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- In addition, many legacy implementations support names encoded in the
- ISO 8859-1 character set (Latin1String) but tag them as
- TeletexString. The Latin1String includes characters used in Western
- European countries which are not part of the TeletexString charcter
- set. Implementations that process TeletexString SHOULD be prepared
- to handle the entire ISO 8859-1 character set.[ISO 8859-1]
-
- As noted above, distinguished names are composed of attributes. This
- specification does not restrict the set of attribute types that may
- appear in names. However, conforming implementations MUST be
- prepared to receive certificates with issuer names containing the set
- of attribute types defined below. This specification also recommends
- support for additional attribute types.
-
- Standard sets of attributes have been defined in the X.500 series of
- specifications.[X.520] Implementations of this specification MUST be
- prepared to receive the following standard attribute types in issuer
- names: country, organization, organizational-unit, distinguished name
- qualifier, state or province name, and common name (e.g., "Susan
- Housley"). In addition, implementations of this specification SHOULD
- be prepared to receive the following standard attribute types in
- issuer names: locality, title, surname, given name, initials, and
- generation qualifier (e.g., "Jr.", "3rd", or "IV"). The syntax and
- associated object identifiers (OIDs) for these attribute types are
- provided in the ASN.1 modules in Appendices A and B.
-
- In addition, implementations of this specification MUST be prepared
- to receive the domainComponent attribute, as defined in [RFC 2247].
- The Domain (Nameserver) System (DNS) provides a hierarchical resource
- labeling system. This attribute provides is a convenient mechanism
- for organizations that wish to use DNs that parallel their DNS names.
- This is not a replacement for the dNSName component of the
- alternative name field. Implementations are not required to convert
- such names into DNS names. The syntax and associated OID for this
- attribute type is provided in the ASN.1 modules in Appendices A and
- B.
-
- Certificate users MUST be prepared to process the issuer
- distinguished name and subject distinguished name (see sec. 4.1.2.6)
- fields to perform name chaining for certification path validation
- (see section 6). Name chaining is performed by matching the issuer
- distinguished name in one certificate with the subject name in a CA
- certificate.
-
- This specification requires only a subset of the name comparison
- functionality specified in the X.500 series of specifications. The
- requirements for conforming implementations are as follows:
-
-
-
-
-Housley, et. al. Standards Track [Page 20]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- (a) attribute values encoded in different types (e.g.,
- PrintableString and BMPString) may be assumed to represent
- different strings;
-
- (b) attribute values in types other than PrintableString are case
- sensitive (this permits matching of attribute values as binary
- objects);
-
- (c) attribute values in PrintableString are not case sensitive
- (e.g., "Marianne Swanson" is the same as "MARIANNE SWANSON"); and
-
- (d) attribute values in PrintableString are compared after
- removing leading and trailing white space and converting internal
- substrings of one or more consecutive white space characters to a
- single space.
-
- These name comparison rules permit a certificate user to validate
- certificates issued using languages or encodings unfamiliar to the
- certificate user.
-
- In addition, implementations of this specification MAY use these
- comparison rules to process unfamiliar attribute types for name
- chaining. This allows implementations to process certificates with
- unfamiliar attributes in the issuer name.
-
- Note that the comparison rules defined in the X.500 series of
- specifications indicate that the character sets used to encode data
- in distinguished names are irrelevant. The characters themselves are
- compared without regard to encoding. Implementations of the profile
- are permitted to use the comparison algorithm defined in the X.500
- series. Such an implementation will recognize a superset of name
- matches recognized by the algorithm specified above.
-
-4.1.2.5 Validity
-
- The certificate validity period is the time interval during which the
- CA warrants that it will maintain information about the status of the
- certificate. The field is represented as a SEQUENCE of two dates:
- the date on which the certificate validity period begins (notBefore)
- and the date on which the certificate validity period ends
- (notAfter). Both notBefore and notAfter may be encoded as UTCTime or
- GeneralizedTime.
-
- CAs conforming to this profile MUST always encode certificate
- validity dates through the year 2049 as UTCTime; certificate validity
- dates in 2050 or later MUST be encoded as GeneralizedTime.
-
-
-
-
-
-Housley, et. al. Standards Track [Page 21]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-4.1.2.5.1 UTCTime
-
- The universal time type, UTCTime, is a standard ASN.1 type intended
- for international applications where local time alone is not
- adequate. UTCTime specifies the year through the two low order
- digits and time is specified to the precision of one minute or one
- second. UTCTime includes either Z (for Zulu, or Greenwich Mean Time)
- or a time differential.
-
- For the purposes of this profile, UTCTime values MUST be expressed
- Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are
- YYMMDDHHMMSSZ), even where the number of seconds is zero. Conforming
- systems MUST interpret the year field (YY) as follows:
-
- Where YY is greater than or equal to 50, the year shall be
- interpreted as 19YY; and
-
- Where YY is less than 50, the year shall be interpreted as 20YY.
-
-4.1.2.5.2 GeneralizedTime
-
- The generalized time type, GeneralizedTime, is a standard ASN.1 type
- for variable precision representation of time. Optionally, the
- GeneralizedTime field can include a representation of the time
- differential between local and Greenwich Mean Time.
-
- For the purposes of this profile, GeneralizedTime values MUST be
- expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e.,
- times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero.
- GeneralizedTime values MUST NOT include fractional seconds.
-
-4.1.2.6 Subject
-
- The subject field identifies the entity associated with the public
- key stored in the subject public key field. The subject name may be
- carried in the subject field and/or the subjectAltName extension. If
- the subject is a CA (e.g., the basic constraints extension, as
- discussed in 4.2.1.10, is present and the value of cA is TRUE,) then
- the subject field MUST be populated with a non-empty distinguished
- name matching the contents of the issuer field (see sec. 4.1.2.4) in
- all certificates issued by the subject CA. If subject naming
- information is present only in the subjectAltName extension (e.g., a
- key bound only to an email address or URI), then the subject name
- MUST be an empty sequence and the subjectAltName extension MUST be
- critical.
-
-
-
-
-
-
-Housley, et. al. Standards Track [Page 22]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- Where it is non-empty, the subject field MUST contain an X.500
- distinguished name (DN). 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 certificate with the same DN to the same
- subject entity.
-
- The subject name field is defined as the X.501 type Name.
- Implementation requirements for this field are those defined for the
- issuer field (see sec. 4.1.2.4). When encoding attribute values of
- type DirectoryString, the encoding rules for the issuer field MUST be
- implemented. Implementations of this specification MUST be prepared
- to receive subject names containing the attribute types required for
- the issuer field. Implementations of this specification SHOULD be
- prepared to receive subject names containing the recommended
- attribute types for the issuer field. The syntax and associated
- object identifiers (OIDs) for these attribute types are provided in
- the ASN.1 modules in Appendices A and B. Implementations of this
- specification MAY use these comparison rules to process unfamiliar
- attribute types (i.e., for name chaining). This allows
- implementations to process certificates with unfamiliar attributes in
- the subject name.
-
- In addition, legacy implementations exist where an RFC 822 name is
- embedded in the subject distinguished name as an EmailAddress
- attribute. The attribute value for EmailAddress is of type IA5String
- to permit inclusion of the character '@', which is not part of the
- PrintableString character set. EmailAddress attribute values are not
- case sensitive (e.g., "fanfeedback@redsox.com" is the same as
- "FANFEEDBACK@REDSOX.COM").
-
- Conforming implementations generating new certificates with
- electronic mail addresses MUST use the rfc822Name in the subject
- alternative name field (see sec. 4.2.1.7) to describe such
- identities. Simultaneous inclusion of the EmailAddress attribute in
- the subject distinguished name to support legacy implementations is
- deprecated but permitted.
-
-4.1.2.7 Subject Public Key Info
-
- 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
- AlgorithmIdentifier structure specified in section 4.1.1.2. The
- object identifiers for the supported algorithms and the methods for
- encoding the public key materials (public key and parameters) are
- specified in section 7.3.
-
-
-
-
-
-
-Housley, et. al. Standards Track [Page 23]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-4.1.2.8 Unique Identifiers
-
- 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
- the certificate to handle the possibility of reuse of subject and/or
- issuer names over time. This profile recommends that names not be
- reused for 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
- conforming to this profile SHOULD be capable of parsing unique
- identifiers and making comparisons.
-
-4.1.2.9 Extensions
-
- 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
- extensions. The format and content of certificate extensions in the
- Internet PKI is defined in section 4.2.
-
-4.2 Standard Certificate Extensions
-
- The extensions defined for X.509 v3 certificates provide methods for
- associating additional attributes with users or public keys and for
- managing the certification hierarchy. The X.509 v3 certificate
- format also allows communities to define private extensions to carry
- information unique to those communities. Each extension in a
- certificate may be designated as critical or non-critical. A
- certificate using system MUST reject the certificate if it encounters
- a critical extension it does not recognize; however, a non-critical
- extension may be ignored if it is not recognized. The following
- sections present recommended extensions used within Internet
- certificates and standard locations for information. Communities may
- elect to use additional extensions; however, caution should be
- exercised in adopting any critical extensions in certificates which
- might prevent use in a general context.
-
- Each extension includes an OID and an ASN.1 structure. When an
- extension appears in a certificate, the OID appears as the field
- extnID and the corresponding ASN.1 encoded structure is the value of
- the octet string extnValue. Only one instance of a particular
- extension may appear in a particular certificate. For example, a
- certificate may contain only one authority key identifier extension
- (see sec. 4.2.1.1). An extension includes the boolean critical, with
- a default value of FALSE. The text for each extension specifies the
- acceptable values for the critical field.
-
-
-
-
-
-
-Housley, et. al. Standards Track [Page 24]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- Conforming CAs MUST support key identifiers (see sec. 4.2.1.1 and
- 4.2.1.2), basic constraints (see sec. 4.2.1.10), key usage (see sec.
- 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
- field, the CA MUST support the subject alternative name extension
- (see sec. 4.2.1.7). Support for the remaining extensions is
- OPTIONAL. Conforming CAs may support extensions that are not
- identified within this specification; certificate issuers are
- cautioned that marking such extensions as critical may inhibit
- interoperability.
-
- At a minimum, applications conforming to this profile MUST recognize
- the extensions which must or may be critical in this specification.
- These extensions are: key usage (see sec. 4.2.1.3), certificate
- 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
- (see sec. 4.2.1.11), policy constraints (see sec. 4.2.1.12), and
- extended key usage (see sec. 4.2.1.13).
-
- 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)
- extensions.
-
-4.2.1 Standard Extensions
-
- This section identifies standard certificate extensions defined in
- [X.509] for use in the Internet PKI. Each extension is associated
- with an OID defined in [X.509]. These OIDs are members of the id-ce
- arc, which is defined by the following:
-
- id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29}
-
-4.2.1.1 Authority Key Identifier
-
- The authority key identifier extension provides a means of
- identifying the public key corresponding to the private key used to
- sign a certificate. This extension is used where an issuer has
- multiple signing keys (either due to multiple concurrent key pairs or
- due to changeover). The identification may be based on either the
- key identifier (the subject key identifier in the issuer's
- certificate) or on the issuer name and serial number.
-
- The keyIdentifier field of the authorityKeyIdentifier extension MUST
- be included in all certificates generated by conforming CAs to
- facilitate chain building. There is one exception; where a CA
- distributes its public key in the form of a "self-signed"
- certificate, the authority key identifier may be omitted. In this
- case, the subject and authority key identifiers would be identical.
-
-
-
-Housley, et. al. Standards Track [Page 25]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- The value of the keyIdentifier field SHOULD be derived from the
- public key used to verify the certificate's signature or a method
- that generates unique values. Two common methods for generating key
- identifiers from the public key are described in (sec. 4.2.1.2). One
- common method for generating unique values isdescribed in (sec.
- 4.2.1.2). Where a key identifier has not been previously
- established, this specification recommends use of one of these
- methods for generating keyIdentifiers.
-
- This profile recommends support for the key identifier method by all
- certificate users.
-
- This extension MUST NOT be marked critical.
-
- id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 }
-
- AuthorityKeyIdentifier ::= SEQUENCE {
- keyIdentifier [0] KeyIdentifier OPTIONAL,
- authorityCertIssuer [1] GeneralNames OPTIONAL,
- authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }
-
- KeyIdentifier ::= OCTET STRING
-
-4.2.1.2 Subject Key Identifier
-
- The subject key identifier extension provides a means of identifying
- certificates that contain a particular public key.
-
- To facilitate chain building, this extension MUST appear in all con-
- forming CA certificates, that is, all certificates including the
- 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
- 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
- this certificate.
-
- For CA certificates, subject key identifiers SHOULD be derived from
- the public key or a method that generates unique values. Two common
- methods for generating key identifiers from the public key are:
-
- (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
- value of the BIT STRING subjectPublicKey (excluding the tag,
- length, and number of unused bits).
-
- (2) The keyIdentifier is composed of a four bit type field with
- the value 0100 followed by the least significant 60 bits of the
- SHA-1 hash of the value of the BIT STRING subjectPublicKey.
-
-
-
-
-Housley, et. al. Standards Track [Page 26]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- One common method for generating unique values is a monotomically
- increasing sequence of integers.
-
- For end entity certificates, the subject key identifier extension
- provides a means for identifying certificates containing the
- particular public key used in an application. Where an end entity has
- obtained multiple certificates, especially from multiple CAs, the
- subject key identifier provides a means to quickly identify the set
- of certificates containing a particular public key. To assist
- applications in identificiation the appropriate end entity
- certificate, this extension SHOULD be included in all end entity
- certificates.
-
- For end entity certificates, subject key identifiers SHOULD be
- derived from the public key. Two common methods for generating key
- identifiers from the public key are identifed above.
-
- Where a key identifier has not been previously established, this
- specification recommends use of one of these methods for generating
- keyIdentifiers.
-
- This extension MUST NOT be marked critical.
-
- id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 }
-
- SubjectKeyIdentifier ::= KeyIdentifier
-
-4.2.1.3 Key Usage
-
- The key usage extension defines the purpose (e.g., encipherment,
- signature, certificate signing) of the key contained in the
- certificate. The usage restriction might be employed when a key that
- could be used for more than one operation is to be restricted. For
- example, when an RSA key should be used only for signing, the
- digitalSignature and/or nonRepudiation bits would be asserted.
- Likewise, when an RSA key should be used only for key management, the
- keyEncipherment bit would be asserted. When used, this extension
- SHOULD be marked critical.
-
- id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 }
-
- KeyUsage ::= BIT STRING {
- digitalSignature (0),
- nonRepudiation (1),
- keyEncipherment (2),
- dataEncipherment (3),
- keyAgreement (4),
- keyCertSign (5),
-
-
-
-Housley, et. al. Standards Track [Page 27]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- cRLSign (6),
- encipherOnly (7),
- decipherOnly (8) }
-
-
- Bits in the KeyUsage type are used as follows:
-
- The digitalSignature bit is asserted when the subject public key
- is used with a digital signature mechanism to support security
- services other than non-repudiation (bit 1), certificate signing
- (bit 5), or revocation information signing (bit 6). Digital
- signature mechanisms are often used for entity authentication and
- data origin authentication with integrity.
-
- The nonRepudiation bit is asserted when the subject public key is
- used to verify digital signatures used to provide a non-
- repudiation service which protects against the signing entity
- falsely denying some action, excluding certificate or CRL signing.
-
- 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 management, then this bit shall asserted.
-
- The dataEncipherment bit is asserted when the subject public key
- is used for enciphering user data, other than cryptographic keys.
-
- The keyAgreement bit is asserted when the subject public 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.
-
- The keyCertSign bit is asserted when the subject public key is
- used for verifying a signature on certificates. This bit may only
- be asserted in CA certificates.
-
- The cRLSign bit is asserted when the subject public key is used
- for verifying a signature on revocation information (e.g., a CRL).
-
- 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 is also set, the subject public key may be
- used only for enciphering data while performing key agreement.
-
- 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 is also set, the subject public key may be
- used only for deciphering data while performing key agreement.
-
-
-
-
-
-Housley, et. al. Standards Track [Page 28]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- This profile does not restrict the combinations of bits that may be
- set in an instantiation of the keyUsage extension. However,
- appropriate values for keyUsage extensions for particular algorithms
- are specified in section 7.3.
-
-4.2.1.4 Private Key Usage Period
-
- This profile recommends against the use of this extension. CAs
- conforming to this profile MUST NOT generate certificates with
- critical private key usage period extensions.
-
- The private key usage period extension allows the certificate issuer
- to specify a different validity period for the private key than the
- certificate. This extension is intended for use with digital
- signature keys. This extension consists of two optional components,
- notBefore and notAfter. The private key associated with the
- certificate should not be used to sign objects before or after the
- times specified by the two components, respectively. CAs conforming
- to this profile MUST NOT generate certificates with private key usage
- period extensions unless at least one of the two components is
- present.
-
- Where used, notBefore and notAfter are represented as GeneralizedTime
- and MUST be specified and interpreted as defined in section
- 4.1.2.5.2.
-
- id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 }
-
- PrivateKeyUsagePeriod ::= SEQUENCE {
- notBefore [0] GeneralizedTime OPTIONAL,
- notAfter [1] GeneralizedTime OPTIONAL }
-
-4.2.1.5 Certificate Policies
-
- The certificate policies extension contains a sequence of one or more
- policy information terms, each of which consists of an object
- identifier (OID) and optional qualifiers. These policy information
- terms indicate the policy under which the certificate has been issued
- and the purposes for which the certificate may be used. Optional
- qualifiers, which may be present, are not expected to change the
- definition of the policy.
-
- Applications with specific policy requirements are expected to have a
- list of those policies which they will accept and to compare the
- policy OIDs in the certificate to that list. If this extension is
- critical, the path validation software MUST be able to interpret this
- extension (including the optional qualifier), or MUST reject the
- certificate.
-
-
-
-Housley, et. al. Standards Track [Page 29]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- To promote interoperability, this profile RECOMMENDS that policy
- information terms consist of only an OID. Where an OID alone is
- insufficient, this profile strongly recommends that use of qualifiers
- be limited to those identified in this section.
-
- This specification defines two policy qualifier types for use by
- certificate policy writers and certificate issuers. The qualifier
- types are the CPS Pointer and User Notice qualifiers.
-
- The CPS Pointer qualifier contains a pointer to a Certification
- Practice Statement (CPS) published by the CA. The pointer is in the
- form of a URI.
-
- User notice is intended for display to a relying party when a
- certificate is used. The application software SHOULD display all
- user notices in all certificates of the certification path used,
- except that if a notice is duplicated only one copy need be
- displayed. To prevent such duplication, this qualifier SHOULD only
- be present in end-entity certificates and CA certificates issued to
- other organizations.
-
- The user notice has two optional fields: the noticeRef field and the
- explicitText field.
-
- The noticeRef field, if used, names an organization and
- identifies, by number, a particular textual statement prepared by
- that organization. For example, it might identify the
- organization "CertsRUs" and notice number 1. In a typical
- implementation, the application software will have a notice file
- containing the current set of notices for CertsRUs; the
- application will extract the notice text from the file and display
- it. Messages may be multilingual, allowing the software to select
- the particular language message for its own environment.
-
- An explicitText field includes the textual statement directly in
- the certificate. The explicitText field is a string with a
- maximum size of 200 characters.
-
- If both the noticeRef and explicitText options are included in the
- one qualifier and if the application software can locate the notice
- text indicated by the noticeRef option then that text should be
- displayed; otherwise, the explicitText string should be displayed.
-
- id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 }
-
- certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
-
-
-
-
-
-Housley, et. al. Standards Track [Page 30]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- PolicyInformation ::= SEQUENCE {
- policyIdentifier CertPolicyId,
- policyQualifiers SEQUENCE SIZE (1..MAX) OF
- PolicyQualifierInfo OPTIONAL }
-
- CertPolicyId ::= OBJECT IDENTIFIER
-
- PolicyQualifierInfo ::= SEQUENCE {
- policyQualifierId PolicyQualifierId,
- qualifier ANY DEFINED BY policyQualifierId }
-
- -- policyQualifierIds for Internet policy qualifiers
-
- id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
- id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 }
- id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 }
-
- PolicyQualifierId ::=
- OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )
-
- Qualifier ::= CHOICE {
- cPSuri CPSuri,
- userNotice UserNotice }
-
- CPSuri ::= IA5String
-
- UserNotice ::= SEQUENCE {
- noticeRef NoticeReference OPTIONAL,
- explicitText DisplayText OPTIONAL}
-
- NoticeReference ::= SEQUENCE {
- organization DisplayText,
- noticeNumbers SEQUENCE OF INTEGER }
-
- DisplayText ::= CHOICE {
- visibleString VisibleString (SIZE (1..200)),
- bmpString BMPString (SIZE (1..200)),
- utf8String UTF8String (SIZE (1..200)) }
-
-4.2.1.6 Policy Mappings
-
- This extension is used in CA certificates. It lists one or more
- pairs of OIDs; each pair includes an issuerDomainPolicy and a
- subjectDomainPolicy. The pairing indicates the issuing CA considers
- its issuerDomainPolicy equivalent to the subject CA's
- subjectDomainPolicy.
-
-
-
-
-
-Housley, et. al. Standards Track [Page 31]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- The issuing CA's users may accept an issuerDomainPolicy for certain
- applications. The policy mapping tells the issuing CA's users which
- policies associated with the subject CA are comparable to the policy
- they accept.
-
- This extension may be supported by CAs and/or applications, and it
- MUST be non-critical.
-
- id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 }
-
- PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
- issuerDomainPolicy CertPolicyId,
- subjectDomainPolicy CertPolicyId }
-
-4.2.1.7 Subject Alternative Name
-
- The subject alternative names extension allows additional identities
- to be bound to the subject of the certificate. Defined options
- include an Internet electronic mail address, a DNS name, an IP
- address, and a uniform resource identifier (URI). Other options
- exist, including completely local definitions. Multiple name forms,
- and multiple instances of each name form, may be included. Whenever
- such identities are to be bound into a certificate, the subject
- alternative name (or issuer alternative name) extension MUST be used.
-
- Because the subject alternative name is considered to be
- definitiviely bound to the public key, all parts of the subject
- alternative name MUST be verified by the CA.
-
- Further, if the only subject identity included in the certificate is
- an alternative name form (e.g., an electronic mail address), then the
- subject distinguished name MUST be empty (an empty sequence), and the
- subjectAltName extension MUST be present. If the subject field
- contains an empty sequence, the subjectAltName extension MUST be
- marked critical.
-
- When the subjectAltName extension contains an Internet mail address,
- 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
- 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
- surrounded in parentheses) after it, and is not surrounded by "<" and
- ">". Note that while upper and lower case letters are allowed in an
- RFC 822 addr-spec, no significance is attached to the case.
-
- When the subjectAltName extension contains a iPAddress, the address
- MUST be stored in the octet string in "network byte order," as
- specified in RFC 791 [RFC 791]. The least significant bit (LSB) of
-
-
-
-Housley, et. al. Standards Track [Page 32]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- 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
- MUST contain exactly four octets. For IP Version 6, as specified in
- RFC 1883, the octet string MUST contain exactly sixteen octets [RFC
- 1883].
-
- When the subjectAltName extension contains a domain name service
- label, the domain name MUST be stored in the dNSName (an IA5String).
- The name MUST be in the "preferred name syntax," as specified by RFC
- 1034 [RFC 1034]. Note that while upper and lower case letters are
- allowed in domain names, no signifigance is attached to the case. In
- addition, while the string " " is a legal domain name, subjectAltName
- extensions with a dNSName " " are not permitted. Finally, the use of
- the DNS representation for Internet mail addresses (wpolk.nist.gov
- instead of wpolk@nist.gov) is not permitted; such identities are to
- be encoded as rfc822Name.
-
- When the subjectAltName extension contains a URI, the name MUST be
- stored in the uniformResourceIdentifier (an IA5String). The name MUST
- 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
- (e.g., "http" or "ftp") and a scheme-specific-part. The scheme-
- specific-part must include a fully qualified domain name or IP
- address as the host.
-
- 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
- case-sensitive, but other components of the scheme-specific-part may
- be case-sensitive. When comparing URIs, conforming implementations
- MUST compare the scheme and host without regard to case, but assume
- the remainder of the scheme-specific-part is case sensitive.
-
- Subject alternative names may be constrained in the same manner as
- subject distinguished names using the name constraints extension as
- described in section 4.2.1.11.
-
- If the subjectAltName extension is present, the sequence MUST contain
- at least one entry. Unlike the subject field, conforming CAs MUST
- NOT issue certificates with subjectAltNames containing empty
- GeneralName fields. For example, an rfc822Name is represented as an
- IA5String. While an empty string is a valid IA5String, such an
- rfc822Name is not permitted by this profile. The behavior of clients
- that encounter such a certificate when processing a certificication
- path is not defined by this profile.
-
-
-
-
-
-
-
-Housley, et. al. Standards Track [Page 33]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- Finally, the semantics of subject alternative names that include
- wildcard characters (e.g., as a placeholder for a set of names) are
- not addressed by this specification. Applications with specific
- requirements may use such names but shall define the semantics.
-
-
- id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 }
-
- SubjectAltName ::= GeneralNames
-
- GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
-
- GeneralName ::= CHOICE {
- otherName [0] OtherName,
- rfc822Name [1] IA5String,
- dNSName [2] IA5String,
- x400Address [3] ORAddress,
- directoryName [4] Name,
- ediPartyName [5] EDIPartyName,
- uniformResourceIdentifier [6] IA5String,
- iPAddress [7] OCTET STRING,
- registeredID [8] OBJECT IDENTIFIER}
-
- OtherName ::= SEQUENCE {
- type-id OBJECT IDENTIFIER,
- value [0] EXPLICIT ANY DEFINED BY type-id }
-
- EDIPartyName ::= SEQUENCE {
- nameAssigner [0] DirectoryString OPTIONAL,
- partyName [1] DirectoryString }
-
-4.2.1.8 Issuer Alternative Names
-
- As with 4.2.1.7, this extension is used to associate Internet style
- identities with the certificate issuer. Issuer alternative names MUST
- be encoded as in 4.2.1.7.
-
- Where present, this extension SHOULD NOT be marked critical.
-
- id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 }
-
- IssuerAltName ::= GeneralNames
-
-4.2.1.9 Subject Directory Attributes
-
- The subject directory attributes extension is not recommended as an
- essential part of this profile, but it may be used in local
- environments. This extension MUST be non-critical.
-
-
-
-Housley, et. al. Standards Track [Page 34]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 }
-
- SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute
-
-4.2.1.10 Basic Constraints
-
- The basic constraints extension identifies whether the subject of the
- certificate is a CA and how deep a certification path may exist
- through that CA.
-
- 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
- follow this certificate in a certification path. A value of zero
- indicates that only an end-entity certificate may follow in the path.
- Where it appears, the pathLenConstraint field MUST be greater than or
- equal to zero. Where pathLenConstraint does not appear, there is no
- limit to the allowed length of the certification path.
-
- This extension MUST appear as a critical extension in all CA
- certificates. This extension SHOULD NOT appear in end entity
- certificates.
-
- id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 }
-
- BasicConstraints ::= SEQUENCE {
- cA BOOLEAN DEFAULT FALSE,
- pathLenConstraint INTEGER (0..MAX) OPTIONAL }
-
-4.2.1.11 Name Constraints
-
- The name constraints extension, which MUST be used only in a CA
- certificate, indicates a name space within which all subject names in
- subsequent certificates in a certification path shall be located.
- Restrictions may apply to the subject distinguished name or subject
- alternative names. Restrictions apply only when the specified name
- form is present. If no name of the type is in the certificate, the
- certificate is acceptable.
-
- Restrictions are defined in terms of permitted or excluded name
- subtrees. Any name matching a restriction in the excludedSubtrees
- field is invalid regardless of information appearing in the
- permittedSubtrees. This extension MUST be critical.
-
- Within this profile, the minimum and maximum fields are not used with
- any name forms, thus minimum is always zero, and maximum is always
- absent.
-
-
-
-
-
-Housley, et. al. Standards Track [Page 35]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- For URIs, the constraint applies to the host part of the name. The
- constraint may specify a host or a domain. Examples would be
- "foo.bar.com"; and ".xyz.com". When the the constraint begins with
- a period, it may be expanded with one or more subdomains. That is,
- the constraint ".xyz.com" is satisfied by both abc.xyz.com and
- abc.def.xyz.com. However, the constraint ".xyz.com" is not satisfied
- by "xyz.com". When the constraint does not begin with a period, it
- specifies a host.
-
- A name constraint for Internat mail addresses may specify a
- particular mailbox, all addresses at a particular host, or all
- mailboxes in a domain. To indicate a particular mailbox, the
- constraint is the complete mail address. For example, "root@xyz.com"
- indicates the root mailbox on the host "xyz.com". To indicate all
- Internet mail addresses on a particular host, the constraint is
- specified as the host name. For example, the constraint "xyz.com" is
- satisfied by any mail address at the host "xyz.com". To specify any
- address within a domain, the constraint is specified with a leading
- period (as with URIs). For example, ".xyz.com" indicates all the
- Internet mail addresses in the domain "xyz.com", but Internet mail
- addresses on the host "xyz.com".
-
- DNS name restrictions are expressed as foo.bar.com. Any subdomain
- satisfies the name constraint. For example, www.foo.bar.com would
- satisfy the constraint but bigfoo.bar.com would not.
-
- Legacy implementations exist where an RFC 822 name is embedded in the
- subject distinguished name in an attribute of type EmailAddress (see
- sec. 4.1.2.6). When rfc822 names are constrained, but the certificate
- does not include a subject alternative name, the rfc822 name
- constraint MUST be applied to the attribute of type EmailAddress in
- the subject distinguished name. The ASN.1 syntax for EmailAddress
- and the corresponding OID are supplied in Appendix A and B.
-
- Restrictions of the form directoryName MUST be applied to the subject
- field in the certificate and to the subjectAltName extensions of type
- directoryName. Restrictions of the form x400Address MUST be applied
- to subjectAltName extensions of type x400Address.
-
- When applying restrictions of the form directoryName, an
- implementation MUST compare DN attributes. At a minimum,
- implementations MUST perform the DN comparison rules specified in
- Section 4.1.2.4. CAs issuing certificates with a restriction of the
- form directoryName SHOULD NOT rely on implementation of the full ISO
- DN name comparison algorithm. This implies name restrictions shall
- be stated identically to the encoding used in the subject field or
- subjectAltName extension.
-
-
-
-
-Housley, et. al. Standards Track [Page 36]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- The syntax of iPAddress MUST be as described in section 4.2.1.7 with
- the following additions specifically for Name Constraints. For IPv4
- addresses, the ipAddress field of generalName MUST contain eight (8)
- octets, encoded in the style of RFC 1519 (CIDR) to represent an
- address range.[RFC 1519] For IPv6 addresses, the ipAddress field
- MUST contain 32 octets similarly encoded. For example, a name
- constraint for "class C" subnet 10.9.8.0 shall be represented as the
- octets 0A 09 08 00 FF FF FF 00, representing the CIDR notation
- 10.9.8.0/255.255.255.0.
-
- The syntax and semantics for name constraints for otherName,
- ediPartyName, and registeredID are not defined by this specification.
-
- id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 }
-
- NameConstraints ::= SEQUENCE {
- permittedSubtrees [0] GeneralSubtrees OPTIONAL,
- excludedSubtrees [1] GeneralSubtrees OPTIONAL }
-
- GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
-
- GeneralSubtree ::= SEQUENCE {
- base GeneralName,
- minimum [0] BaseDistance DEFAULT 0,
- maximum [1] BaseDistance OPTIONAL }
-
- BaseDistance ::= INTEGER (0..MAX)
-
-4.2.1.12 Policy Constraints
-
- The policy constraints extension can be used in certificates issued
- to CAs. The policy constraints extension constrains path validation
- in two ways. It can be used to prohibit policy mapping or require
- that each certificate in a path contain an acceptable policy
- identifier.
-
- If the inhibitPolicyMapping field is present, the value indicates the
- number of additional certificates that may appear in the path before
- policy mapping is no longer permitted. For example, a value of one
- indicates that policy mapping may be processed in certificates issued
- by the subject of this certificate, but not in additional
- certificates in the path.
-
- If the requireExplicitPolicy field is present, subsequent
- certificates shall include an acceptable policy identifier. The value
- of requireExplicitPolicy indicates the number of additional
- certificates that may appear in the path before an explicit policy is
- required. An acceptable policy identifier is the identifier of a
-
-
-
-Housley, et. al. Standards Track [Page 37]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- policy required by the user of the certification path or the
- identifier of a policy which has been declared equivalent through
- policy mapping.
-
- Conforming CAs MUST NOT issue certificates where policy constraints
- is a null sequence. That is, at least one of the inhibitPolicyMapping
- field or the requireExplicitPolicy field MUST be present. The
- behavior of clients that encounter a null policy constraints field is
- not addressed in this profile.
-
- This extension may be critical or non-critical.
-
- id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 }
-
- PolicyConstraints ::= SEQUENCE {
- requireExplicitPolicy [0] SkipCerts OPTIONAL,
- inhibitPolicyMapping [1] SkipCerts OPTIONAL }
-
- SkipCerts ::= INTEGER (0..MAX)
-
-4.2.1.13 Extended key usage field
-
- 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
- purposes indicated in the key usage extension field. This field is
- defined as follows:
-
- id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37}
-
- ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
-
- KeyPurposeId ::= OBJECT IDENTIFIER
-
- Key purposes may be defined by any organization with a need. Object
- identifiers used to identify key purposes shall be assigned in
- 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
- either critical or non-critical.
-
- If the extension is flagged critical, then the certificate MUST be
- used only for one of the purposes indicated.
-
- If the extension is flagged non-critical, then it indicates the
- intended purpose or purposes of the key, and may be used in finding
- the correct key/certificate of an entity that has multiple
- keys/certificates. It is an advisory field and does not imply that
- usage of the key is restricted by the certification authority to the
-
-
-
-Housley, et. al. Standards Track [Page 38]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- purpose indicated. Certificate using applications may nevertheless
- require that a particular purpose be indicated in order for the
- certificate to be acceptable to that application.
-
- If a certificate contains both a critical key usage field and a
- critical extended key usage field, then both fields MUST be processed
- independently and the certificate MUST only be used for a purpose
- consistent with both fields. If there is no purpose consistent with
- both fields, then the certificate MUST NOT be used for any purpose.
-
- The following key usage purposes are defined by this profile:
-
- id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
-
- id-kp-serverAuth OBJECT IDENTIFIER ::= {id-kp 1}
- -- TLS Web server authentication
- -- Key usage bits that may be consistent: digitalSignature,
- -- keyEncipherment or keyAgreement
- --
- id-kp-clientAuth OBJECT IDENTIFIER ::= {id-kp 2}
- -- TLS Web client authentication
- -- Key usage bits that may be consistent: digitalSignature and/or
- -- keyAgreement
- --
- id-kp-codeSigning OBJECT IDENTIFIER ::= {id-kp 3}
- -- Signing of downloadable executable code
- -- Key usage bits that may be consistent: digitalSignature
- --
- id-kp-emailProtection OBJECT IDENTIFIER ::= {id-kp 4}
- -- E-mail protection
- -- Key usage bits that may be consistent: digitalSignature,
- -- nonRepudiation, and/or (keyEncipherment
- -- or keyAgreement)
- --
- id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }
- -- Binding the hash of an object to a time from an agreed-upon time
- -- source. Key usage bits that may be consistent: digitalSignature,
- -- nonRepudiation
-
-4.2.1.14 CRL Distribution Points
-
- The CRL distribution points extension identifies how CRL information
- is obtained. The extension SHOULD be non-critical, but this profile
- recommends support for this extension by CAs and applications.
- Further discussion of CRL management is contained in section 5.
-
-
-
-
-
-
-Housley, et. al. Standards Track [Page 39]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- If the cRLDistributionPoints extension contains a
- DistributionPointName of type URI, the following semantics MUST be
- assumed: the URI is a pointer to the current CRL for the associated
- 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
- other values are not defined by this specification. If the
- distributionPoint omits reasons, the CRL MUST include revocations for
- all reasons. If the distributionPoint omits cRLIssuer, the CRL MUST
- be issued by the CA that issued the certificate.
-
- id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 }
-
- cRLDistributionPoints ::= {
- CRLDistPointsSyntax }
-
- CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
-
- DistributionPoint ::= SEQUENCE {
- distributionPoint [0] DistributionPointName OPTIONAL,
- reasons [1] ReasonFlags OPTIONAL,
- cRLIssuer [2] GeneralNames OPTIONAL }
-
- DistributionPointName ::= CHOICE {
- fullName [0] GeneralNames,
- nameRelativeToCRLIssuer [1] RelativeDistinguishedName }
-
- ReasonFlags ::= BIT STRING {
- unused (0),
- keyCompromise (1),
- cACompromise (2),
- affiliationChanged (3),
- superseded (4),
- cessationOfOperation (5),
- certificateHold (6) }
-
-4.2.2 Private Internet Extensions
-
- This section defines one new extension for use in the Internet Public
- Key Infrastructure. This extension may be used to direct
- applications to identify an on-line validation service supporting the
- issuing CA. As the information may be available in multiple forms,
- each extension is a sequence of IA5String values, each of which
- represents a URI. The URI implicitly specifies the location and
- format of the information and the method for obtaining the
- information.
-
-
-
-
-
-
-Housley, et. al. Standards Track [Page 40]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- An object identifier is defined for the private extension. The
- object identifier associated with the private extension is defined
- under the arc id-pe within the id-pkix name space. Any future
- extensions defined for the Internet PKI will also be defined under
- the arc id-pe.
-
- id-pkix OBJECT IDENTIFIER ::=
- { iso(1) identified-organization(3) dod(6) internet(1)
- security(5) mechanisms(5) pkix(7) }
-
- id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
-
-4.2.2.1 Authority Information Access
-
- The authority information access extension indicates how to access CA
- information and services for the issuer of the certificate in which
- the extension appears. Information and services may include on-line
- validation services and CA policy data. (The location of CRLs is not
- specified in this extension; that information is provided by the
- cRLDistributionPoints extension.) This extension may be included in
- subject or CA certificates, and it MUST be non-critical.
-
- id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }
-
- AuthorityInfoAccessSyntax ::=
- SEQUENCE SIZE (1..MAX) OF AccessDescription
-
- AccessDescription ::= SEQUENCE {
- accessMethod OBJECT IDENTIFIER,
- accessLocation GeneralName }
-
- id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
-
- id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }
-
- Each entry in the sequence AuthorityInfoAccessSyntax describes the
- format and location of additional information about the CA who issued
- the certificate in which this extension appears. The type and format
- of the information is specified by the accessMethod field; the
- accessLocation field specifies the location of the information. The
- retrieval mechanism may be implied by the accessMethod or specified
- by accessLocation.
-
- This profile defines one OID for accessMethod. The id-ad-caIssuers
- OID is used when the additional information lists CAs that have
- issued certificates superior to the CA that issued the certificate
-
-
-
-
-
-Housley, et. al. Standards Track [Page 41]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- containing this extension. The referenced CA Issuers description is
- intended to aid certificate users in the selection of a certification
- path that terminates at a point trusted by the certificate user.
-
- When id-ad-caIssuers appears as accessInfoType, the accessLocation
- field describes the referenced description server and the access
- protocol to obtain the referenced description. The accessLocation
- field is defined as a GeneralName, which can take several forms.
- Where the information is available via http, ftp, or ldap,
- accessLocation MUST be a uniformResourceIdentifier. Where the
- information is available via the directory access protocol (dap),
- accessLocation MUST be a directoryName. When the information is
- available via electronic mail, accessLocation MUST be an rfc822Name.
- The semantics of other name forms of accessLocation (when
- accessMethod is id-ad-caIssuers) are not defined by this
- specification.
-
- Additional access descriptors may be defined in other PKIX
- specifications.
-
-5 CRL and CRL Extensions Profile
-
- As described above, one goal of this X.509 v2 CRL profile is to
- foster the creation of an interoperable and reusable Internet PKI.
- To achieve this goal, guidelines for the use of extensions are
- specified, and some assumptions are made about the nature of
- information included in the CRL.
-
- CRLs may be used in a wide range of applications and environments
- covering a broad spectrum of interoperability goals and an even
- broader spectrum of operational and assurance requirements. This
- profile establishes a common baseline for generic applications
- requiring broad interoperability. The profile defines a baseline set
- of information that can be expected in every CRL. Also, the profile
- defines common locations within the CRL for frequently used
- attributes as well as common representations for these attributes.
-
- This profile does not define any private Internet CRL extensions or
- CRL entry extensions.
-
- Environments with additional or special purpose requirements may
- build on this profile or may replace it.
-
- Conforming CAs are not required to issue CRLs if other revocation or
- certificate status mechanisms are provided. Conforming CAs that
- issue CRLs MUST issue version 2 CRLs, and CAs MUST include the date
- by which the next CRL will be issued in the nextUpdate field (see
-
-
-
-
-Housley, et. al. Standards Track [Page 42]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- sec. 5.1.2.5), the CRL number extension (see sec. 5.2.3) and the
- authority key identifier extension (see sec. 5.2.1). Conforming
- applications are required to process version 1 and 2 CRLs.
-
-5.1 CRL Fields
-
- The X.509 v2 CRL syntax is as follows. For signature calculation,
- the data that is to be signed is ASN.1 DER encoded. ASN.1 DER
- encoding is a tag, length, value encoding system for each element.
-
- CertificateList ::= SEQUENCE {
- tbsCertList TBSCertList,
- signatureAlgorithm AlgorithmIdentifier,
- signatureValue BIT STRING }
-
- TBSCertList ::= SEQUENCE {
- version Version OPTIONAL,
- -- if present, shall be v2
- signature AlgorithmIdentifier,
- issuer Name,
- thisUpdate Time,
- nextUpdate Time OPTIONAL,
- revokedCertificates SEQUENCE OF SEQUENCE {
- userCertificate CertificateSerialNumber,
- revocationDate Time,
- crlEntryExtensions Extensions OPTIONAL
- -- if present, shall be v2
- } OPTIONAL,
- crlExtensions [0] EXPLICIT Extensions OPTIONAL
- -- if present, shall be v2
- }
-
- -- Version, Time, CertificateSerialNumber, and Extensions
- -- are all defined in the ASN.1 in section 4.1
-
- -- AlgorithmIdentifier is defined in section 4.1.1.2
-
- The following items describe the use of the X.509 v2 CRL in the
- Internet PKI.
-
-5.1.1 CertificateList Fields
-
- The CertificateList is a SEQUENCE of three required fields. The
- fields are described in detail in the following subsections.
-
-
-
-
-
-
-
-Housley, et. al. Standards Track [Page 43]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-5.1.1.1 tbsCertList
-
- The first field in the sequence is the tbsCertList. This field is
- itself a sequence containing the name of the issuer, issue date,
- issue date of the next list, the list of revoked certificates, and
- optional CRL extensions. Further, each entry on the revoked
- certificate list is defined by a sequence of user certificate serial
- number, revocation date, and optional CRL entry extensions.
-
-5.1.1.2 signatureAlgorithm
-
- The signatureAlgorithm field contains the algorithm identifier for
- the algorithm used by the CA to sign the CertificateList. The field
- is of type AlgorithmIdentifier, which is defined in section 4.1.1.2.
- Section 7.2 lists the supported algorithms for this specification.
- Conforming CAs MUST use the algorithm identifiers presented in
- section 7.2 when signing with a supported signature algorithm.
-
- This field MUST contain the same algorithm identifier as the
- signature field in the sequence tbsCertList (see sec. 5.1.2.2).
-
-5.1.1.3 signatureValue
-
- The signatureValue field contains a digital signature computed upon
- 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 then ASN.1 encoded as a BIT STRING and included in the CRL's
- signatureValue field. The details of this process are specified for
- each of the supported algorithms in section 7.2.
-
-5.1.2 Certificate List "To Be Signed"
-
- The certificate list to be signed, or TBSCertList, is a SEQUENCE of
- required and optional fields. The required fields identify 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
- CRL.
-
- Optional fields include lists of revoked certificates and CRL
- extensions. The revoked certificate list is optional to support the
- case where a CA has not revoked any unexpired certificates that it
- has issued. The profile requires conforming CAs to use the CRL
- extension cRLNumber in all CRLs issued.
-
-
-
-
-
-
-
-
-Housley, et. al. Standards Track [Page 44]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-5.1.2.1 Version
-
- This optional field describes the version of the encoded CRL. When
- extensions are used, as required by this profile, this field MUST be
- present and MUST specify version 2 (the integer value is 1).
-
-5.1.2.2 Signature
-
- This field contains the algorithm identifier for the algorithm used
- to sign the CRL. Section 7.2 lists OIDs for the most popular
- signature algorithms used in the Internet PKI.
-
- This field MUST contain the same algorithm identifier as the
- signatureAlgorithm field in the sequence CertificateList (see section
- 5.1.1.2).
-
-5.1.2.3 Issuer Name
-
- The issuer name identifies the entity who has signed and issued the
- CRL. The issuer identity is carried in the issuer name field.
- Alternative name forms may also appear in the issuerAltName extension
- (see sec. 5.2.2). The issuer name field MUST contain an X.500
- distinguished name (DN). The issuer name field is defined as the
- X.501 type Name, and MUST follow the encoding rules for the issuer
- name field in the certificate (see sec. 4.1.2.4).
-
-5.1.2.4 This Update
-
- This field indicates the issue date of this CRL. ThisUpdate may be
- encoded as UTCTime or GeneralizedTime.
-
- CAs conforming to this profile that issue CRLs MUST encode thisUpdate
- as UTCTime for dates through the year 2049. CAs conforming to this
- profile that issue CRLs MUST encode thisUpdate as GeneralizedTime for
- dates in the year 2050 or later.
-
- Where encoded as UTCTime, thisUpdate MUST be specified and
- interpreted as defined in section 4.1.2.5.1. Where encoded as
- GeneralizedTime, thisUpdate MUST be specified and interpreted as
- defined in section 4.1.2.5.2.
-
-5.1.2.5 Next Update
-
- 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
- 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.
- nextUpdate may be encoded as UTCTime or GeneralizedTime.
-
-
-
-Housley, et. al. Standards Track [Page 45]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- This profile requires inclusion of nextUpdate in all CRLs issued by
- conforming CAs. Note that the ASN.1 syntax of TBSCertList describes
- this field as OPTIONAL, which is consistent with the ASN.1 structure
- defined in [X.509]. The behavior of clients processing CRLs which
- omit nextUpdate is not specified by this profile.
-
- CAs conforming to this profile that issue CRLs MUST encode nextUpdate
- as UTCTime for dates through the year 2049. CAs conforming to this
- profile that issue CRLs MUST encode nextUpdate as GeneralizedTime for
- dates in the year 2050 or later.
-
- Where encoded as UTCTime, nextUpdate MUST be specified and
- interpreted as defined in section 4.1.2.5.1. Where encoded as
- GeneralizedTime, nextUpdate MUST be specified and interpreted as
- defined in section 4.1.2.5.2.
-
-5.1.2.6 Revoked Certificates
-
- Revoked certificates are listed. The revoked certificates are named
- by their serial numbers. Certificates revoked by the CA are uniquely
- identified by the certificate serial number. The date on which the
- revocation occurred is specified. The time for revocationDate MUST
- be expressed as described in section 5.1.2.4. Additional information
- may be supplied in CRL entry extensions; CRL entry extensions are
- discussed in section 5.3.
-
-5.1.2.7 Extensions
-
- This field may only appear if the version is 2 (see sec. 5.1.2.1).
- If present, this field is a SEQUENCE of one or more CRL extensions.
- CRL extensions are discussed in section 5.2.
-
-5.2 CRL Extensions
-
- The extensions defined by ANSI X9 and ISO/IEC/ITU for X.509 v2 CRLs
- [X.509] [X9.55] provide methods for associating additional attributes
- with CRLs. The X.509 v2 CRL format also allows communities to define
- private extensions to carry information unique to those communities.
- Each extension in a CRL may be designated as critical or non-
- critical. A CRL validation MUST fail if it encounters a critical
- extension which it does not know how to process. However, an
- unrecognized non-critical extension may be ignored. The following
- subsections present those extensions used within Internet CRLs.
- Communities may elect to include extensions in CRLs which are not
- defined in this specification. However, caution should be exercised
- in adopting any critical extensions in CRLs which might be used in a
- general context.
-
-
-
-
-Housley, et. al. Standards Track [Page 46]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- Conforming CAs that issue CRLs are required to include the authority
- key identifier (see sec. 5.2.1) and the CRL number (see sec. 5.2.3)
- extensions in all CRLs issued.
-
-5.2.1 Authority Key Identifier
-
- The authority key identifier extension provides a means of
- identifying the public key corresponding to the private key used to
- sign a CRL. The identification can be based on either the key
- identifier (the subject key identifier in the CRL signer's
- certificate) or on the issuer name and serial number. This extension
- is especially useful where an issuer has more than one signing key,
- either due to multiple concurrent key pairs or due to changeover.
-
- Conforming CAs MUST use the key identifier method, and MUST include
- this extension in all CRLs issued.
-
- The syntax for this CRL extension is defined in section 4.2.1.1.
-
-5.2.2 Issuer Alternative Name
-
- The issuer alternative names extension allows additional identities
- to be associated with the issuer of the CRL. Defined options include
- an rfc822 name (electronic mail address), a DNS name, an IP address,
- and a URI. Multiple instances of a name and multiple name forms may
- be included. Whenever such identities are used, the issuer
- alternative name extension MUST be used.
-
- The issuerAltName extension SHOULD NOT be marked critical.
-
- The OID and syntax for this CRL extension are defined in section
- 4.2.1.8.
-
-5.2.3 CRL Number
-
- The CRL number is a non-critical CRL extension which conveys a
- monotonically increasing sequence number for each CRL issued by a CA.
- This extension allows users to easily determine when a particular CRL
- supersedes another CRL. CAs conforming to this profile MUST include
- this extension in all CRLs.
-
- id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }
-
- cRLNumber ::= INTEGER (0..MAX)
-
-
-
-
-
-
-
-Housley, et. al. Standards Track [Page 47]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-5.2.4 Delta CRL Indicator
-
- The delta CRL indicator is a critical CRL extension that identifies a
- delta-CRL. The use of delta-CRLs can significantly improve
- processing time for applications which store revocation information
- in a format other than the CRL structure. This allows changes to be
- added to the local database while ignoring unchanged information that
- is already in the local database.
-
- When a delta-CRL is issued, the CAs MUST also issue a complete CRL.
-
- The value of BaseCRLNumber identifies the CRL number of the base CRL
- that was used as the starting point in the generation of this delta-
- CRL. The delta-CRL contains the changes between the base CRL and the
- current CRL issued along with the delta-CRL. It is the decision of a
- CA as to whether to provide delta-CRLs. Again, a delta-CRL MUST NOT
- be issued without a corresponding complete CRL. The value of
- CRLNumber for both the delta-CRL and the corresponding complete CRL
- MUST be identical.
-
- A CRL user constructing a locally held CRL from delta-CRLs MUST
- consider the constructed CRL incomplete and unusable if the CRLNumber
- of the received delta-CRL is more than one greater than the CRLnumber
- of the delta-CRL last processed.
-
- id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }
-
- deltaCRLIndicator ::= BaseCRLNumber
-
- BaseCRLNumber ::= CRLNumber
-
-5.2.5 Issuing Distribution Point
-
- The issuing distribution point is a critical CRL extension that
- identifies the CRL distribution point for a particular CRL, and it
- indicates whether the CRL covers revocation for end entity
- certificates only, CA certificates only, or a limitied set of reason
- codes. Although the extension is critical, conforming
- implementations are not required to support this extension.
-
- 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
- X.500 Directory, it is stored in the Directory entry corresponding to
- the CRL distribution point, which may be different than the Directory
- entry of the CA.
-
-
-
-
-
-
-Housley, et. al. Standards Track [Page 48]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- The reason codes associated with a distribution point shall be
- specified in onlySomeReasons. If onlySomeReasons does not appear, the
- distribution point shall contain revocations for all reason codes.
- CAs may use CRL distribution points to partition the CRL on the basis
- of compromise and routine revocation. In this case, the revocations
- with reason code keyCompromise (1) and cACompromise (2) appear in one
- distribution point, and the revocations with other reason codes
- appear in another distribution point.
-
- Where the issuingDistributionPoint extension contains a URL, 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,
- mailto [RFC1738] and ldap [RFC1778] are defined for this purpose.
- The URI MUST be an absolute, not relative, pathname and MUST specify
- the host.
-
- id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 }
-
- issuingDistributionPoint ::= SEQUENCE {
- distributionPoint [0] DistributionPointName OPTIONAL,
- onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE,
- onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE,
- onlySomeReasons [3] ReasonFlags OPTIONAL,
- indirectCRL [4] BOOLEAN DEFAULT FALSE }
-
-5.3 CRL Entry Extensions
-
- The CRL entry extensions already defined by ANSI X9 and ISO/IEC/ITU
- for X.509 v2 CRLs provide methods for associating additional
- attributes with CRL entries [X.509] [X9.55]. The X.509 v2 CRL format
- also allows communities to define private CRL entry extensions to
- carry information unique to those communities. Each extension in a
- CRL entry may be designated as critical or non-critical. A CRL
- validation MUST fail if it encounters a critical CRL entry extension
- which it does not know how to process. However, an unrecognized
- non-critical CRL entry extension may be ignored. The following
- subsections present recommended extensions used within Internet CRL
- entries and standard locations for information. Communities may
- elect to use additional CRL entry extensions; however, caution should
- be exercised in adopting any critical extensions in CRL entries which
- might be used in a general context.
-
- All CRL entry extensions used in this specification are non-critical.
- Support for these extensions is optional for conforming CAs and
- applications. However, CAs that issue CRLs SHOULD include reason
- codes (see sec. 5.3.1) and invalidity dates (see sec. 5.3.3) whenever
- this information is available.
-
-
-
-
-Housley, et. al. Standards Track [Page 49]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-5.3.1 Reason Code
-
- The reasonCode is a non-critical CRL entry extension that identifies
- the reason for the certificate revocation. CAs are strongly
- encouraged to include meaningful reason codes in CRL entries;
- however, the reason code CRL entry extension SHOULD be absent instead
- of using the unspecified (0) reasonCode value.
-
- id-ce-cRLReason OBJECT IDENTIFIER ::= { id-ce 21 }
-
- -- reasonCode ::= { CRLReason }
-
- CRLReason ::= ENUMERATED {
- unspecified (0),
- keyCompromise (1),
- cACompromise (2),
- affiliationChanged (3),
- superseded (4),
- cessationOfOperation (5),
- certificateHold (6),
- removeFromCRL (8) }
-
-5.3.2 Hold Instruction Code
-
- The hold instruction code is a non-critical CRL entry extension that
- provides a registered instruction identifier which indicates the
- action to be taken after encountering a certificate that has been
- placed on hold.
-
- id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 }
-
- holdInstructionCode ::= OBJECT IDENTIFIER
-
- The following instruction codes have been defined. Conforming
- applications that process this extension MUST recognize the following
- instruction codes.
-
- holdInstruction OBJECT IDENTIFIER ::=
- { iso(1) member-body(2) us(840) x9-57(10040) 2 }
-
- id-holdinstruction-none OBJECT IDENTIFIER ::= {holdInstruction 1}
- id-holdinstruction-callissuer
- OBJECT IDENTIFIER ::= {holdInstruction 2}
- id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3}
-
- Conforming applications which encounter an id-holdinstruction-
- callissuer MUST call the certificate issuer or reject the
- certificate. Conforming applications which encounter an id-
-
-
-
-Housley, et. al. Standards Track [Page 50]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- holdinstruction-reject MUST reject the certificate. The hold
- instruction id-holdinstruction-none is semantically equivalent to the
- absence of a holdInstructionCode, and its use is strongly deprecated
- for the Internet PKI.
-
-5.3.3 Invalidity Date
-
- The invalidity date is a non-critical CRL entry extension that
- provides the date on which it is known or suspected that the private
- key was compromised or that the certificate otherwise became invalid.
- This date may be earlier than the revocation date in the CRL entry,
- which is the date at which the CA processed the revocation. When a
- revocation is first posted by a CA in a CRL, the invalidity date may
- precede the date of issue of earlier CRLs, but the revocation date
- SHOULD NOT precede the date of issue of earlier CRLs. Whenever this
- information is available, CAs are strongly encouraged to share it
- with CRL users.
-
- The GeneralizedTime values included in this field MUST be expressed
- in Greenwich Mean Time (Zulu), and MUST be specified and interpreted
- as defined in section 4.1.2.5.2.
-
- id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 }
-
- invalidityDate ::= GeneralizedTime
-
-5.3.4 Certificate Issuer
-
- This CRL entry extension identifies the certificate issuer associated
- with an entry in an indirect CRL, i.e. a CRL that has the indirectCRL
- indicator set in its issuing distribution point extension. If this
- extension is not present on the first entry in an indirect CRL, the
- certificate issuer defaults to the CRL issuer. On subsequent entries
- in an indirect CRL, if this extension is not present, the certificate
- issuer for the entry is the same as that for the preceding entry.
- This field is defined as follows:
-
- id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 }
-
- certificateIssuer ::= GeneralNames
-
- If used by conforming CAs that issue CRLs, this extension is always
- critical. If an implementation ignored this extension it could not
- correctly attribute CRL entries to certificates. This specification
- RECOMMENDS that implementations recognize this extension.
-
-
-
-
-
-
-Housley, et. al. Standards Track [Page 51]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-6 Certification Path Validation
-
- Certification path validation procedures for the Internet PKI are
- based on section 12.4.3 of [X.509]. Certification path processing
- verifies the binding between the subject distinguished name and/or
- subject alternative name and subject public key. The binding is
- limited by constraints which are specified in the certificates which
- comprise the path. The basic constraints and policy constraints
- extensions allow the certification path processing logic to automate
- the decision making process.
-
- This section describes an algorithm for validating certification
- paths. Conforming implementations of this specification are not
- required to implement this algorithm, but MUST be functionally
- equivalent to the external behavior resulting from this procedure.
- Any algorithm may be used by a particular implementation so long as
- it derives the correct result.
-
- In section 6.1, the text describes basic path validation. This text
- assumes that all valid paths begin with certificates issued by a
- single "most-trusted CA". The algorithm requires the public key of
- the CA, the CA's name, the validity period of the public key, and any
- constraints upon the set of paths which may be validated using this
- key.
-
- The "most-trusted CA" is a matter of policy: it could be a root CA in
- a hierarchical PKI; the CA that issued 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 "most-
- trusted CA."
-
- section 6.2 describes extensions to the basic path validation
- algorithm. Two specific cases are discussed: the case where paths may
- begin with one of several trusted CAs; and where compatibility with
- the PEM architecture is required.
-
-6.1 Basic Path Validation
-
- The text assumes that the trusted public key (and related
- information) is contained in a "self-signed" certificate. This
- simplifies the description of the path processing procedure. Note
- that the signature on the self-signed certificate does not provide
- any security services. The trusted public key (and related
- information) may be obtained in other formats; the information is
- trusted because of other procedures used to obtain and protect it.
-
-
-
-
-
-
-Housley, et. al. Standards Track [Page 52]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- The goal of path validation is to verify the binding between a
- subject distinguished name or subject alternative name and subject
- public key, as represented in the "end entity" certificate, based on
- the public key of the "most-trusted CA". This requires obtaining a
- sequence of certificates that support that binding. The procedures
- performed to obtain this sequence is outside the scope of this
- section.
-
- The following text also assumes that certificates do not use subject
- or unique identifier fields or private critical extensions, as
- recommended within this profile. However, if these components appear
- in certificates, they MUST be processed. Finally, policy qualifiers
- are also neglected for the sake of clarity.
-
- A certification path is a sequence of n certificates where:
-
- * for all x in {1,(n-1)}, the subject of certificate x is the
- issuer of certificate x+1.
- * certificate x=1 is the the self-signed certificate, and
- * certificate x=n is the end entity certificate.
-
- This section assumes the following inputs are provided to the path
- processing logic:
-
- (a) a certification path of length n;
-
- (b) a set of initial policy identifiers (each comprising a
- sequence of policy element identifiers), which identifies one or
- more certificate policies, any one of which would be acceptable
- for the purposes of certification path processing, or the special
- value "any-policy";
-
- (c) the current date/time (if not available internally to the
- certification path processing module); and
-
- (d) the time, T, for which the validity of the path should be
- determined. (This may be the current date/time, or some point in
- the past.)
-
- From the inputs, the procedure intializes five state variables:
-
- (a) acceptable policy set: A set of certificate policy
- identifiers comprising the policy or policies recognized by the
- public key user together with policies deemed equivalent through
- policy mapping. The initial value of the acceptable policy set is
- the special value "any-policy".
-
-
-
-
-
-Housley, et. al. Standards Track [Page 53]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- (b) constrained subtrees: A set of root names defining a set of
- subtrees within which all subject names in subsequent certificates
- in the certification path shall fall. The initial value is
- "unbounded".
-
- (c) excluded subtrees: A set of root names defining a set of
- subtrees within which no subject name in subsequent certificates
- in the certification path may fall. The initial value is "empty".
-
- (d) explicit policy: an integer which indicates if an explicit
- policy identifier is required. The integer indicates the first
- certificate in the path where this requirement is imposed. Once
- set, this variable may be decreased, but may not be increased.
- (That is, if a certificate in the path requires explicit policy
- identifiers, a later certificate can not remove this requirement.)
- The initial value is n+1.
-
- (e) policy mapping: an integer which indicates if policy mapping
- is permitted. The integer indicates the last certificate on which
- policy mapping may be applied. Once set, this variable may be
- decreased, but may not be increased. (That is, if a certificate in
- the path specifies policy mapping is not permitted, it can not be
- overriden by a later certificate.) The initial value is n+1.
-
- The actions performed by the path processing software for each
- certificate i=1 through n are described below. The self-signed
- certificate is certificate i=1, the end entity certificate is i=n.
- The processing is performed sequentially, so that processing
- certificate i affects the state variables for processing certificate
- (i+1). Note that actions (h) through (m) are not applied to the end
- entity certificate (certificate n).
-
- The path processing actions to be performed are:
-
- (a) Verify the basic certificate information, including:
-
- (1) the certificate was signed using the subject public key
- from certificate i-1 (in the special case i=1, this step may be
- omitted; if not, use the subject public key from the same
- certificate),
-
- (2) the certificate validity period includes time T,
-
- (3) the certificate had not been revoked at time T and is not
- currently on hold status that commenced before time T, (this
- may be determined by obtaining the appropriate CRL or status
- information, or by out-of-band mechanisms), and
-
-
-
-
-Housley, et. al. Standards Track [Page 54]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- (4) the subject and issuer names chain correctly (that is, the
- issuer of this certificate was the subject of the previous
- certificate.)
-
- (b) Verify that the subject name and subjectAltName extension
- (critical or noncritical) is consistent with the constrained
- subtrees state variables.
-
- (c) Verify that the subject name and subjectAltName extension
- (critical or noncritical) is consistent with the excluded subtrees
- state variables.
-
- (d) Verify that policy information is consistent with the initial
- policy set:
-
- (1) if the explicit policy state variable is less than or equal
- to i, a policy identifier in the certificate shall be in the
- initial policy set; and
-
- (2) if the policy mapping variable is less than or equal to i,
- the policy identifier may not be mapped.
-
- (e) Verify that policy information is consistent with the
- acceptable policy set:
-
- (1) if the certificate policies extension is marked critical,
- the intersection of the policies extension and the acceptable
- policy set shall be non-null;
-
- (2) the acceptable policy set is assigned the resulting
- intersection as its new value.
-
- (g) Verify that the intersection of the acceptable policy set and
- the initial policy set is non-null.
-
- (h) Recognize and process any other critical extension present in
- the certificate.
-
- (i) Verify that the certificate is a CA certificate (as specified
- in a basicConstraints extension or as verified out-of-band).
-
- (j) If permittedSubtrees is present in the certificate, set the
- constrained subtrees state variable to the intersection of its
- previous value and the value indicated in the extension field.
-
- (k) If excludedSubtrees is present in the certificate, set the
- excluded subtrees state variable to the union of its previous
- value and the value indicated in the extension field.
-
-
-
-Housley, et. al. Standards Track [Page 55]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- (l) If a policy constraints extension is included in the
- certificate, modify the explicit policy and policy mapping state
- variables as follows:
-
- (1) If requireExplicitPolicy is present and has value r, the
- explicit policy state variable is set to the minimum of its
- current value and the sum of r and i (the current certificate
- in the sequence).
-
- (2) If inhibitPolicyMapping is present and has value q, the
- policy mapping state variable is set to the minimum of its
- current value and the sum of q and i (the current certificate
- in the sequence).
-
- (m) If a key usage extension is marked critical, ensure the
- keyCertSign bit is set.
-
- If any one of the above checks fail, the procedure terminates,
- returning a failure indication and an appropriate reason. If none of
- the above checks fail on the end-entity certificate, the procedure
- terminates, returning a success indication together with the set of
- all policy qualifier values encountered in the set of certificates.
-
-6.2 Extending Path Validation
-
- The path validation algorithm presented in 6.1 is based on several
- simplifying assumptions (e.g., a single trusted CA that starts all
- valid paths). This algorithm may be extended for cases where the
- assumptions do not hold.
-
- This procedure may be extended for multiple trusted CAs by providing
- a set of self-signed certificates to the validation module. In this
- case, a valid path could begin with any one of the self-signed
- certificates. Limitations in the trust paths for any particular key
- may be incorporated into the self-signed certificate's extensions. In
- this way, the self-signed certificates permit the path validation
- module to automatically incorporate local security policy and
- requirements.
-
- It is also possible to specify an extended version of the above
- certification path processing procedure which results in default
- behavior identical to the rules of PEM [RFC 1422]. In this extended
- version, additional inputs to the procedure are a list of one or more
- Policy Certification Authorities (PCAs) names and an indicator of the
- position in the certification path where the PCA is expected. At the
- nominated PCA position, the CA name is compared against this list.
- If a recognized PCA name is found, then a constraint of
- SubordinateToCA is implicitly assumed for the remainder of the
-
-
-
-Housley, et. al. Standards Track [Page 56]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- certification path and processing continues. If no valid PCA name is
- found, and if the certification path cannot be validated on the basis
- of identified policies, then the certification path is considered
- invalid.
-
-7 Algorithm Support
-
- This section describes cryptographic algorithms which may be used
- with this profile. The section describes one-way hash functions and
- digital signature algorithms which may be used to sign certificates
- and CRLs, and identifies OIDs for public keys contained in a
- certificate.
-
- Conforming CAs and applications are not required to support the
- algorithms or algorithm identifiers described in this section.
- However, conforming CAs and applications that use the algorithms
- identified here MUST support them as specified.
-
-7.1 One-way Hash Functions
-
- This section identifies one-way hash functions for use in the
- Internet PKI. One-way hash functions are also called message digest
- algorithms. SHA-1 is the preferred one-way hash function for the
- Internet PKI. However, PEM uses MD2 for certificates [RFC 1422] [RFC
- 1423] and MD5 is used in other legacy applications. For this reason,
- MD2 and MD5 are included in this profile.
-
-7.1.1 MD2 One-way Hash Function
-
- MD2 was developed by Ron Rivest for RSA Data Security. RSA Data
- Security has not placed the MD2 algorithm in the public domain.
- Rather, RSA Data Security has granted license to use MD2 for non-
- commercial Internet Privacy-Enhanced Mail. For this reason, MD2 may
- continue to be used with PEM certificates, but SHA-1 is preferred.
- MD2 produces a 128-bit "hash" of the input. MD2 is fully described
- in RFC 1319 [RFC 1319].
-
- At the Selected Areas in Cryptography '95 conference in May 1995,
- Rogier and Chauvaud presented an attack on MD2 that can nearly find
- collisions [RC95]. Collisions occur when one can find two different
- messages that generate the same message digest. A checksum operation
- in MD2 is the only remaining obstacle to the success of the attack.
- For this reason, the use of MD2 for new applications is discouraged.
- It is still reasonable to use MD2 to verify existing signatures, as
- the ability to find collisions in MD2 does not enable an attacker to
- find new messages having a previously computed hash value.
-
-
-
-
-
-Housley, et. al. Standards Track [Page 57]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-7.1.2 MD5 One-way Hash Function
-
- MD5 was developed by Ron Rivest for RSA Data Security. RSA Data
- Security has placed the MD5 algorithm in the public domain. MD5
- produces a 128-bit "hash" of the input. MD5 is fully described in
- RFC 1321 [RFC 1321].
-
- Den Boer and Bosselaers [DB94] have found pseudo-collisions for MD5,
- but there are no other known cryptanalytic results. The use of MD5
- for new applications is discouraged. It is still reasonable to use
- MD5 to verify existing signatures.
-
-7.1.3 SHA-1 One-way Hash Function
-
- SHA-1 was developed by the U.S. Government. SHA-1 produces a 160-bit
- "hash" of the input. SHA-1 is fully described in FIPS 180-1 [FIPS
- 180-1].
-
- SHA-1 is the one-way hash function of choice for use with both the
- RSA and DSA signature algorithms (see sec. 7.2).
-
-7.2 Signature Algorithms
-
- Certificates and CRLs described by this standard may be signed with
- any public key signature algorithm. The certificate or CRL indicates
- the algorithm through an algorithm identifier which appears in the
- signatureAlgorithm field in a Certificate or CertificateList. This
- algorithm identifier is an OID and has optionally associated
- parameters. This section identifies algorithm identifiers and
- parameters that shall be used in the signatureAlgorithm field in a
- Certificate or CertificateList.
-
- RSA and DSA are the most popular signature algorithms used in the
- Internet. Signature algorithms are always used in conjunction with a
- one-way hash function identified in section 7.1.
-
- The signature algorithm and one-way hash function used to sign a
- certificate or CRL is indicated by use of an algorithm identifier.
- An algorithm identifier is an OID, and may include associated
- parameters. This section identifies OIDS for RSA and DSA. The
- contents of the parameters component for each algorithm vary; details
- are provided for each algorithm.
-
- The data to be signed (e.g., the one-way hash function output value)
- is formatted for the signature algorithm to be used. Then, a private
- key operation (e.g., RSA encryption) is performed to generate the
-
-
-
-
-
-Housley, et. al. Standards Track [Page 58]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- signature value. This signature value is then ASN.1 encoded as a BIT
- STRING and included in the Certificate or CertificateList in the
- signature field.
-
-7.2.1 RSA Signature Algorithm
-
- A patent statement regarding the RSA algorithm can be found at the
- end of this profile.
-
- The RSA algorithm is named for its inventors: Rivest, Shamir, and
- Adleman. This profile includes three signature algorithms based on
- the RSA asymmetric encryption algorithm. The signature algorithms
- combine RSA with either the MD2, MD5, or the SHA-1 one-way hash
- functions.
-
- The signature algorithm with MD2 and the RSA encryption algorithm is
- defined in PKCS #1 [RFC 2313]. As defined in RFC 2313, the ASN.1 OID
- used to identify this signature algorithm is:
-
- md2WithRSAEncryption OBJECT IDENTIFIER ::= {
- iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
- pkcs-1(1) 2 }
-
- The signature algorithm with MD5 and the RSA encryption algorithm is
- defined in PKCS #1 [RFC 2313]. As defined in RFC 2313, the ASN.1 OID
- used to identify this signature algorithm is:
-
- md5WithRSAEncryption OBJECT IDENTIFIER ::= {
- iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
- pkcs-1(1) 4 }
-
- The signature algorithm with SHA-1 and the RSA encryption algorithm
- is implemented using the padding and encoding conventions described
- in PKCS #1 [RFC 2313]. The message digest is computed using the SHA-1
- hash algorithm. The ASN.1 object identifier used to identify this
- signature algorithm is:
-
- sha-1WithRSAEncryption OBJECT IDENTIFIER ::= {
- iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
- pkcs-1(1) 5 }
-
- When any of these three OIDs appears within the ASN.1 type
- AlgorithmIdentifier, the parameters component of that type shall be
- the ASN.1 type NULL.
-
- The RSA signature generation process and the encoding of the result
- is described in detail in RFC 2313.
-
-
-
-
-Housley, et. al. Standards Track [Page 59]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-7.2.2 DSA Signature Algorithm
-
- A patent statement regarding the DSA can be found at the end of this
- profile.
-
- The Digital Signature Algorithm (DSA) is also called the Digital
- Signature Standard (DSS). DSA was developed by the U.S. Government,
- and DSA is used in conjunction with the the SHA-1 one-way hash
- function. DSA is fully described in FIPS 186 [FIPS 186]. The ASN.1
- OIDs used to identify this signature algorithm are:
-
- id-dsa-with-sha1 ID ::= {
- iso(1) member-body(2) us(840) x9-57 (10040)
- x9cm(4) 3 }
-
- Where the id-dsa-with-sha1 algorithm identifier appears as the
- algorithm field in an AlgorithmIdentifier, the encoding shall omit
- the parameters field. That is, the AlgorithmIdentifier shall be a
- SEQUENCE of one component - the OBJECT IDENTIFIER id-dsa-with-sha1.
-
- The DSA parameters in the subjectPublicKeyInfo field of the
- certificate of the issuer shall apply to the verification of the
- signature.
-
- When signing, the DSA algorithm generates two values. These values
- are commonly referred to as r and s. To easily transfer these two
- values as one signature, they shall be ASN.1 encoded using the
- following ASN.1 structure:
-
- Dss-Sig-Value ::= SEQUENCE {
- r INTEGER,
- s INTEGER }
-
-7.3 Subject Public Key Algorithms
-
- Certificates described by this profile may convey a public key for
- any public key algorithm. The certificate indicates the algorithm
- through an algorithm identifier. This algorithm identifier is an OID
- and optionally associated parameters.
-
- This section identifies preferred OIDs and parameters for the RSA,
- DSA, and Diffie-Hellman algorithms. Conforming CAs shall use the
- identified OIDs when issuing certificates containing public keys for
- these algorithms. Conforming applications supporting any of these
- algorithms shall, at a minimum, recognize the OID identified in this
- section.
-
-
-
-
-
-Housley, et. al. Standards Track [Page 60]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-7.3.1 RSA Keys
-
- The OID rsaEncryption identifies RSA public keys.
-
- pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
- rsadsi(113549) pkcs(1) 1 }
-
- rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1}
-
- The rsaEncryption OID is intended to be used in the algorithm field
- of a value of type AlgorithmIdentifier. The parameters field shall
- have ASN.1 type NULL for this algorithm identifier.
-
- The RSA public key shall be encoded using the ASN.1 type
- RSAPublicKey:
-
- RSAPublicKey ::= SEQUENCE {
- modulus INTEGER, -- n
- publicExponent INTEGER -- e -- }
-
- where modulus is the modulus n, and publicExponent is the public
- exponent e. The DER encoded RSAPublicKey is the value of the BIT
- STRING subjectPublicKey.
-
- This OID is used in public key certificates for both RSA signature
- keys and RSA encryption keys. The intended application for the key
- may be indicated in the key usage field (see sec. 4.2.1.3). The use
- of a single key for both signature and encryption purposes is not
- recommended, but is not forbidden.
-
- If the keyUsage extension is present in an end entity certificate
- which conveys an RSA public key, any combination of the following
- values may be present: digitalSignature; nonRepudiation;
- keyEncipherment; and dataEncipherment. If the keyUsage extension is
- present in a CA certificate which conveys an RSA public key, any
- combination of the following values may be present:
- digitalSignature; nonRepudiation; keyEncipherment; dataEncipherment;
- keyCertSign; and cRLSign. However, this specification RECOMMENDS
- that if keyCertSign or cRLSign is present, both keyEncipherment and
- dataEncipherment should not be present.
-
-7.3.2 Diffie-Hellman Key Exchange Key
-
- The Diffie-Hellman OID supported by this profile is defined by ANSI
- X9.42 [X9.42].
-
- dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) member-body(2)
- us(840) ansi-x942(10046) number-type(2) 1 }
-
-
-
-Housley, et. al. Standards Track [Page 61]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- The dhpublicnumber OID is intended to be used in the algorithm field
- of a value of type AlgorithmIdentifier. The parameters field of that
- type, which has the algorithm-specific syntax ANY DEFINED BY
- algorithm, have the ASN.1 type DomainParameters for this algorithm.
-
- DomainParameters ::= SEQUENCE {
- p INTEGER, -- odd prime, p=jq +1
- g INTEGER, -- generator, g
- q INTEGER, -- factor of p-1
- j INTEGER OPTIONAL, -- subgroup factor
- validationParms ValidationParms OPTIONAL }
-
- ValidationParms ::= SEQUENCE {
- seed BIT STRING,
- pgenCounter INTEGER }
-
- The fields of type DomainParameters have the following meanings:
-
- p identifies the prime p defining the Galois field;
-
- g specifies the generator of the multiplicative subgroup of order
- g;
-
- q specifies the prime factor of p-1;
-
- j optionally specifies the value that satisfies the equation
- p=jq+1 to support the optional verification of group parameters;
-
- seed optionally specifies the bit string parameter used as the
- seed for the system parameter generation process; and
-
- pgenCounter optionally specifies the integer value output as part
- of the of the system parameter prime generation process.
-
- If either of the parameter generation components (pgencounter or
- seed) is provided, the other shall be present as well.
-
- The Diffie-Hellman public key shall be ASN.1 encoded as an INTEGER;
- this encoding shall be used as the contents (i.e., the value) of the
- subjectPublicKey component (a BIT STRING) of the subjectPublicKeyInfo
- data element.
-
- DHPublicKey ::= INTEGER -- public key, y = g^x mod p
-
-
-
-
-
-
-
-
-Housley, et. al. Standards Track [Page 62]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- If the keyUsage extension is present in a certificate which conveys a
- DH public key, the following values may be present: keyAgreement;
- encipherOnly; and decipherOnly. At most one of encipherOnly and
- decipherOnly shall be asserted in keyUsage extension.
-
-7.3.3 DSA Signature Keys
-
- The Digital Signature Algorithm (DSA) is also known as the Digital
- Signature Standard (DSS). The DSA OID supported by this profile is
-
- id-dsa ID ::= { iso(1) member-body(2) us(840) x9-57(10040)
- x9cm(4) 1 }
-
- The id-dsa algorithm syntax includes optional parameters. These
- parameters are commonly referred to as p, q, and g. When omitted,
- the parameters component shall be omitted entirely. That is, the
- AlgorithmIdentifier shall be a SEQUENCE of one component - the OBJECT
- IDENTIFIER id-dsa.
-
- If the DSA algorithm parameters are present in the
- subjectPublicKeyInfo AlgorithmIdentifier, the parameters are included
- using the following ASN.1 structure:
-
- Dss-Parms ::= SEQUENCE {
- p INTEGER,
- q INTEGER,
- g INTEGER }
-
-
- If the DSA algorithm parameters are absent from the
- subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the
- subject certificate using DSA, then the certificate issuer's DSA
- parameters apply to the subject's DSA key. If the DSA algorithm
- parameters are absent from the subjectPublicKeyInfo
- AlgorithmIdentifier and the CA signed the subject certificate using a
- signature algorithm other than DSA, then the subject's DSA parameters
- are distributed by other means. If the subjectPublicKeyInfo
- AlgorithmIdentifier field omits the parameters component and the CA
- signed the subject with a signature algorithm other than DSA, then
- clients shall reject the certificate.
-
- When signing, DSA algorithm generates two values. These values are
- commonly referred to as r and s. To easily transfer these two values
- as one signature, they are ASN.1 encoded using the following ASN.1
- structure:
-
-
-
-
-
-
-Housley, et. al. Standards Track [Page 63]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- Dss-Sig-Value ::= SEQUENCE {
- r INTEGER,
- s INTEGER }
-
- The encoded signature is conveyed as the value of the BIT STRING
- signature in a Certificate or CertificateList.
-
- The DSA public key shall be ASN.1 DER encoded as an INTEGER; this
- encoding shall be used as the contents (i.e., the value) of the
- subjectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo
- data element.
-
- DSAPublicKey ::= INTEGER -- public key, Y
-
- If the keyUsage extension is present in an end entity certificate
- which conveys a DSA public key, any combination of the following
- values may be present: digitalSignature; and nonRepudiation.
-
- If the keyUsage extension is present in an CA certificate which
- conveys a DSA public key, any combination of the following values may
- be present: digitalSignature; nonRepudiation; keyCertSign; and
- cRLSign.
-
-8 References
-
- [FIPS 180-1] Federal Information Processing Standards Publication
- (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995.
- [Supersedes FIPS PUB 180 dated 11 May 1993.]
-
- [FIPS 186] Federal Information Processing Standards Publication
- (FIPS PUB) 186, Digital Signature Standard, 18 May
- 1994.
-
- [RC95] Rogier, N. and Chauvaud, P., "The compression function
- of MD2 is not collision free," Presented at Selected
- Areas in Cryptography '95, May 1995.
-
- [RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791,
- September 1981.
-
- [RFC 822] Crocker, D., "Standard for the format of ARPA Internet
- text messages", STD 11, RFC 822, August 1982.
-
- [RFC 1034] Mockapetris, P., "Domain names - concepts and
- facilities", STD 13, RFC 1034, November 1987.
-
- [RFC 1319] Kaliski, B., "The MD2 Message-Digest Algorithm," RFC
- 1319, April 1992.
-
-
-
-Housley, et. al. Standards Track [Page 64]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- [RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC
- 1321, April 1992.
-
- [RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic
- Mail: Part II: Certificate-Based Key Management," RFC
- 1422, February 1993.
-
- [RFC 1423] Balenson, D., "Privacy Enhancement for Internet
- Electronic Mail: Part III: Algorithms, Modes, and
- Identifiers," RFC 1423, February 1993.
-
- [RFC 1519] Fuller, V., Li, T., Yu, J. and K. Varadhan. "Classless
- Inter-Domain Routing (CIDR): an Address Assignment and
- Aggregation Strategy", RFC 1519, September 1993.
-
- [RFC 1738] Berners-Lee, T., Masinter L., and M. McCahill.
- "Uniform Resource Locators (URL)", RFC 1738, December
- 1994.
-
- [RFC 1778] Howes, T., Kille S., Yeong, W. and C. Robbins. "The
- String Representation of Standard Attribute Syntaxes,"
- RFC 1778, March 1995.
-
- [RFC 1883] Deering, S. and R. Hinden. "Internet Protocol, Version
- 6 (IPv6) Specification", RFC 1883, December 1995.
-
- [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC 2247] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S.
- Sataluri. "Using Domains in LDAP/X.500 Distinguished
- Names", RFC 2247, January 1998.
-
- [RFC 2277] Alvestrand, H., "IETF Policy on Character Sets and
- Languages", RFC 2277, January 1998.
-
- [RFC 2279] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", RFC 2279, January 1998.
-
- [RFC 2313] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", RFC
- 2313, March 1998.
-
- [SDN.701] SDN.701, "Message Security Protocol 4.0", Revision A
- 1997-02-06.
-
- [X.208] CCITT Recommendation X.208: Specification of Abstract
- Syntax Notation One (ASN.1), 1988.
-
-
-
-
-Housley, et. al. Standards Track [Page 65]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- [X.501] ITU-T Recommendation X.501: Information Technology -
- Open Systems Interconnection - The Directory: Models,
- 1993.
-
- [X.509] ITU-T Recommendation X.509 (1997 E): Information
- Technology - Open Systems Interconnection - The
- Directory: Authentication Framework, June 1997.
-
- [X.520] ITU-T Recommendation X.520: Information Technology -
- Open Systems Interconnection - The Directory: Selected
- Attribute Types, 1993.
-
- [X9.42] ANSI X9.42-199x, Public Key Cryptography for The
- Financial Services Industry: Agreement of Symmetric
- Algorithm Keys Using Diffie-Hellman (Working Draft),
- December 1997.
-
- [X9.55] ANSI X9.55-1995, Public Key Cryptography For The
- Financial Services Industry: Extensions To Public Key
- Certificates And Certificate Revocation Lists, 8
- December, 1995.
-
- [X9.57] ANSI X9.57-199x, Public Key Cryptography For The
- Financial Services Industry: Certificate Management
- (Working Draft), 21 June, 1996.
-
-9 Intellectual Property Rights
-
- The IETF has been notified of intellectual property rights claimed in
- regard to some or all of the specification contained in this
- document. For more information consult the online list of claimed
- rights.
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication and any assurances of
- licenses to be made available, or the result of an attempt made to
-
-
-
-
-
-
-
-
-Housley, et. al. Standards Track [Page 66]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- obtain a general license or permission for the use of such
- proprietary rights by implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
-10 Security Considerations
-
- The majority of this specification is devoted to the format and
- content of certificates and CRLs. Since certificates and CRLs are
- digitally signed, no additional integrity service is necessary.
- Neither certificates nor CRLs need be kept secret, and unrestricted
- and anonymous access to certificates and CRLs has no security
- implications.
-
- However, security factors outside the scope of this specification
- will affect the assurance provided to certificate users. This
- section highlights critical issues that should be considered by
- implementors, administrators, and users.
-
- The procedures performed by CAs and RAs to validate the binding of
- the subject's identity of their public key greatly affect the
- assurance that should be placed in the certificate. Relying parties
- may wish to review the CA's certificate practice statement. This may
- be particularly important when issuing certificates to other CAs.
-
- The use of a single key pair for both signature and other purposes is
- strongly discouraged. Use of separate key pairs for signature and key
- management provides several benefits to the users. The ramifications
- associated with loss or disclosure of a signature key are different
- from loss or disclosure of a key management key. Using separate key
- pairs permits a balanced and flexible response. Similarly, different
- validity periods or key lengths for each key pair may be appropriate
- in some application environments. Unfortunately, some legacy
- applications (e.g., SSL) use a single key pair for signature and key
- management.
-
- The protection afforded private keys is a critical factor in
- maintaining security. On a small scale, failure of users to protect
- their private keys will permit an attacker to masquerade as them, or
- decrypt their personal information. On a larger scale, compromise of
- a CA's private signing key may have a catastrophic effect. If an
- attacker obtains the private key unnoticed, the attacker may issue
- bogus certificates and CRLs. Existence of bogus certificates and
- CRLs will undermine confidence in the system. If the compromise is
- detected, all certificates issued to the CA shall be revoked,
- preventing services between its users and users of other CAs.
- Rebuilding after such a compromise will be problematic, so CAs are
- advised to implement a combination of strong technical measures
- (e.g., tamper-resistant cryptographic modules) and appropriate
-
-
-
-Housley, et. al. Standards Track [Page 67]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- management procedures (e.g., separation of duties) to avoid such an
- incident.
-
- 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.
- CAs are advised to maintain secure backup for signing keys. The
- security of the key backup procedures is a critical factor in
- avoiding key compromise.
-
- The availability and freshness of revocation information will affect
- the degree of assurance that should be placed in a certificate.
- While certificates expire naturally, events may occur during its
- natural lifetime which negate the binding between the subject and
- public key. If revocation information is untimely or unavailable,
- the assurance associated with the binding is clearly reduced.
- Similarly, implementations of the Path Validation mechanism described
- in section 6 that omit revocation checking provide less assurance
- than those that support it.
-
- The path validation algorithm depends on the certain knowledge of the
- public keys (and other information) about one or more trusted CAs.
- The decision to trust a CA is an important decision as it ultimately
- determines the trust afforded a certificate. The authenticated
- distribution of trusted CA public keys (usually in the form of a
- "self-signed" certificate) is a security critical out of band process
- that is beyond the scope of this specification.
-
- In addition, where a key compromise or CA failure occurs for a
- trusted CA, the user will need to modify the information provided to
- the path validation routine. Selection of too many trusted CAs will
- make the trusted CA information difficult to maintain. On the other
- hand, selection of only one trusted CA may limit users to a closed
- community of users until a global PKI emerges.
-
- The quality of implementations that process certificates may also
- affect the degree of assurance provided. The path validation
- algorithm described in section 6 relies upon the integrity of the
- trusted CA information, and especially the integrity of the public
- keys associated with the trusted CAs. By substituting public keys
- for which an attacker has the private key, an attacker could trick
- the user into accepting false certificates.
-
- The binding between a key and certificate subject cannot be stronger
- than the cryptographic module implementation and algorithms used to
- generate the signature. Short key lengths or weak hash algorithms
- will limit the utility of a certificate. CAs are encouraged to note
- advances in cryptology so they can employ strong cryptographic
- techniques. In addition, CAs should decline to issue certificates to
-
-
-
-Housley, et. al. Standards Track [Page 68]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- CAs or end entities that generate weak signatures.
-
- Inconsistent application of name comparison rules may result in
- acceptance of invalid X.509 certification paths, or rejection of
- valid ones. The X.500 series of specifications defines rules for
- comparing distinguished names require comparison of strings without
- regard to case, character set, multi-character white space substring,
- or leading and trailing white space. This specification relaxes
- these requirements, requiring support for binary comparison at a
- minimum.
-
- CAs shall encode the distinguished name in the subject field of a CA
- certificate identically to the distinguished name in the issuer field
- in certificates issued by the latter CA. If CAs use different
- encodings, implementations of this specification may fail to
- recognize name chains for paths that include this certificate. As a
- consequence, valid paths could be rejected.
-
- In addition, name constraints for distinguished names shall be stated
- identically to the encoding used in the subject field or
- subjectAltName extension. If not, (1) name constraints stated as
- excludedSubTrees will not match and invalid paths will be accepted
- and (2) name constraints expressed as permittedSubtrees will not
- match and valid paths will be rejected. To avoid acceptance of
- invalid paths, CAs should state name constraints for distinguished
- names as permittedSubtrees where ever possible.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Housley, et. al. Standards Track [Page 69]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-Appendix A. Psuedo-ASN.1 Structures and OIDs
-
- This section describes data objects used by conforming PKI components
- in an "ASN.1-like" syntax. This syntax is a hybrid of the 1988 and
- 1993 ASN.1 syntaxes. The 1988 ASN.1 syntax is augmented with 1993
- UNIVERSAL Types UniversalString, BMPString and UTF8String.
-
- The ASN.1 syntax does not permit the inclusion of type statements in
- the ASN.1 module, and the 1993 ASN.1 standard does not permit use of
- 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
- standard.
-
- This appendix may be converted into 1988 ASN.1 by replacing the
- defintions for the UNIVERSAL Types with the 1988 catch-all "ANY".
-
-A.1 Explicitly Tagged Module, 1988 Syntax
-
-PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1)
- security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-88(1)}
-
-
-DEFINITIONS EXPLICIT TAGS ::=
-
-BEGIN
-
--- EXPORTS ALL --
-
--- IMPORTS NONE --
-
--- UNIVERSAL Types defined in '93 and '98 ASN.1
--- but required by this specification
-
-UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING
- -- UniversalString is defined in ASN.1:1993
-
-BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING
- -- BMPString is the subtype of UniversalString and models
- -- the Basic Multilingual Plane of ISO/IEC/ITU 10646-1
-
-UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
- -- The content of this type conforms to RFC 2279.
-
---
--- PKIX specific OIDs
-
-id-pkix OBJECT IDENTIFIER ::=
- { iso(1) identified-organization(3) dod(6) internet(1)
-
-
-
-Housley, et. al. Standards Track [Page 70]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- security(5) mechanisms(5) pkix(7) }
--- PKIX arcs
-
-id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
- -- arc for private certificate extensions
-id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
- -- arc for policy qualifier types
-id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
- -- arc for extended key purpose OIDS
-id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
- -- arc for access descriptors
-
--- policyQualifierIds for Internet policy qualifiers
-
-id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 }
- -- OID for CPS qualifier
-id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 }
- -- OID for user notice qualifier
-
--- access descriptor definitions
-
-id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }
-id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }
-
--- attribute data types --
-
-Attribute ::= SEQUENCE {
- type AttributeType,
- values SET OF AttributeValue
- -- at least one value is required -- }
-
-AttributeType ::= OBJECT IDENTIFIER
-
-AttributeValue ::= ANY
-
-AttributeTypeAndValue ::= SEQUENCE {
- type AttributeType,
- value AttributeValue }
-
--- suggested naming attributes: Definition of the following
--- information object set may be augmented to meet local
--- requirements. Note that deleting members of the set may
--- prevent interoperability with conforming implementations.
--- presented in pairs: the AttributeType followed by the
--- type definition for the corresponding AttributeValue
-
---Arc for standard naming attributes
-id-at OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 4}
-
-
-
-Housley, et. al. Standards Track [Page 71]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
--- Attributes of type NameDirectoryString
-id-at-name AttributeType ::= {id-at 41}
-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 {
- teletexString TeletexString (SIZE (1..ub-name)),
- printableString PrintableString (SIZE (1..ub-name)),
- universalString UniversalString (SIZE (1..ub-name)),
- utf8String UTF8String (SIZE (1..ub-name)),
- bmpString BMPString (SIZE(1..ub-name)) }
-
---
-
-id-at-commonName AttributeType ::= {id-at 3}
-
-X520CommonName ::= CHOICE {
- teletexString TeletexString (SIZE (1..ub-common-name)),
- printableString PrintableString (SIZE (1..ub-common-name)),
- universalString UniversalString (SIZE (1..ub-common-name)),
- utf8String UTF8String (SIZE (1..ub-common-name)),
- bmpString BMPString (SIZE(1..ub-common-name)) }
-
---
-
-id-at-localityName AttributeType ::= {id-at 7}
-
-X520LocalityName ::= CHOICE {
- teletexString TeletexString (SIZE (1..ub-locality-name)),
- printableString PrintableString (SIZE (1..ub-locality-name)),
- universalString UniversalString (SIZE (1..ub-locality-name)),
- utf8String UTF8String (SIZE (1..ub-locality-name)),
- bmpString BMPString (SIZE(1..ub-locality-name)) }
-
---
-
-id-at-stateOrProvinceName AttributeType ::= {id-at 8}
-
-X520StateOrProvinceName ::= CHOICE {
- teletexString TeletexString (SIZE (1..ub-state-name)),
- printableString PrintableString (SIZE (1..ub-state-name)),
- universalString UniversalString (SIZE (1..ub-state-name)),
- utf8String UTF8String (SIZE (1..ub-state-name)),
- bmpString BMPString (SIZE(1..ub-state-name)) }
-
---
-
-
-
-Housley, et. al. Standards Track [Page 72]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-id-at-organizationName AttributeType ::= {id-at 10}
-
-X520OrganizationName ::= CHOICE {
- teletexString TeletexString (SIZE (1..ub-organization-name)),
- printableString PrintableString (SIZE (1..ub-organization-name)),
- universalString UniversalString (SIZE (1..ub-organization-name)),
- utf8String UTF8String (SIZE (1..ub-organization-name)),
- bmpString BMPString (SIZE(1..ub-organization-name)) }
-
---
-
-id-at-organizationalUnitName AttributeType ::= {id-at 11}
-
-X520OrganizationalUnitName ::= CHOICE {
- teletexString TeletexString (SIZE (1..ub-organizational-unit-name)),
- printableString PrintableString
- (SIZE (1..ub-organizational-unit-name)),
- universalString UniversalString
- (SIZE (1..ub-organizational-unit-name)),
- utf8String UTF8String (SIZE (1..ub-organizational-unit-name)),
- bmpString BMPString (SIZE(1..ub-organizational-unit-name)) }
-
---
-
-id-at-title AttributeType ::= {id-at 12}
-
-X520Title ::= CHOICE {
- teletexString TeletexString (SIZE (1..ub-title)),
- printableString PrintableString (SIZE (1..ub-title)),
- universalString UniversalString (SIZE (1..ub-title)),
- utf8String UTF8String (SIZE (1..ub-title)),
- bmpString BMPString (SIZE(1..ub-title)) }
-
---
-
-id-at-dnQualifier AttributeType ::= {id-at 46}
-X520dnQualifier ::= PrintableString
-
-id-at-countryName AttributeType ::= {id-at 6}
-X520countryName ::= PrintableString (SIZE (2)) -- IS 3166 codes
-
-
- -- Legacy attributes
-
-pkcs-9 OBJECT IDENTIFIER ::=
- { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 }
-
-emailAddress AttributeType ::= { pkcs-9 1 }
-
-
-
-Housley, et. al. Standards Track [Page 73]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-Pkcs9email ::= IA5String (SIZE (1..ub-emailaddress-length))
-
--- naming data types --
-
-Name ::= CHOICE { -- only one possibility for now --
- rdnSequence RDNSequence }
-
-RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
-
-DistinguishedName ::= RDNSequence
-
-RelativeDistinguishedName ::=
- SET SIZE (1 .. MAX) OF AttributeTypeAndValue
-
--- Directory string type --
-
-DirectoryString ::= CHOICE {
- teletexString TeletexString (SIZE (1..MAX)),
- printableString PrintableString (SIZE (1..MAX)),
- universalString UniversalString (SIZE (1..MAX)),
- utf8String UTF8String (SIZE (1..MAX)),
- bmpString BMPString (SIZE(1..MAX)) }
-
--- certificate and CRL specific structures begin here
-
-Certificate ::= SEQUENCE {
- tbsCertificate TBSCertificate,
- signatureAlgorithm AlgorithmIdentifier,
- signature BIT STRING }
-
-TBSCertificate ::= SEQUENCE {
- version [0] Version DEFAULT v1,
- serialNumber CertificateSerialNumber,
- signature AlgorithmIdentifier,
- issuer Name,
- validity Validity,
- subject Name,
- subjectPublicKeyInfo SubjectPublicKeyInfo,
- issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
- -- If present, version shall be v2 or v3
- subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
- -- If present, version shall be v2 or v3
- extensions [3] Extensions OPTIONAL
- -- If present, version shall be v3 -- }
-
-Version ::= INTEGER { v1(0), v2(1), v3(2) }
-
-CertificateSerialNumber ::= INTEGER
-
-
-
-Housley, et. al. Standards Track [Page 74]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-Validity ::= SEQUENCE {
- notBefore Time,
- notAfter Time }
-
-Time ::= CHOICE {
- utcTime UTCTime,
- generalTime GeneralizedTime }
-
-UniqueIdentifier ::= BIT STRING
-
-SubjectPublicKeyInfo ::= SEQUENCE {
- algorithm AlgorithmIdentifier,
- subjectPublicKey BIT STRING }
-
-Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
-
-Extension ::= SEQUENCE {
- extnID OBJECT IDENTIFIER,
- critical BOOLEAN DEFAULT FALSE,
- extnValue OCTET STRING }
-
--- CRL structures
-
-CertificateList ::= SEQUENCE {
- tbsCertList TBSCertList,
- signatureAlgorithm AlgorithmIdentifier,
- signature BIT STRING }
-
-TBSCertList ::= SEQUENCE {
- version Version OPTIONAL,
- -- if present, shall be v2
- signature AlgorithmIdentifier,
- issuer Name,
- thisUpdate Time,
- nextUpdate Time OPTIONAL,
- revokedCertificates SEQUENCE OF SEQUENCE {
- userCertificate CertificateSerialNumber,
- revocationDate Time,
- crlEntryExtensions Extensions OPTIONAL
- -- if present, shall be v2
- } OPTIONAL,
- crlExtensions [0] Extensions OPTIONAL
- -- if present, shall be v2 -- }
-
--- Version, Time, CertificateSerialNumber, and Extensions were
--- defined earlier for use in the certificate structure
-
-AlgorithmIdentifier ::= SEQUENCE {
-
-
-
-Housley, et. al. Standards Track [Page 75]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- algorithm OBJECT IDENTIFIER,
- parameters ANY DEFINED BY algorithm OPTIONAL }
- -- contains a value of the type
- -- registered for use with the
- -- algorithm object identifier value
-
--- Algorithm OIDs and parameter structures
-
-pkcs-1 OBJECT IDENTIFIER ::= {
- iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 }
-
-rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 }
-
-md2WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 2 }
-
-md5WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 4 }
-
-sha1WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 5 }
-
-id-dsa-with-sha1 OBJECT IDENTIFIER ::= {
- iso(1) member-body(2) us(840) x9-57 (10040) x9algorithm(4) 3 }
-
-Dss-Sig-Value ::= SEQUENCE {
- r INTEGER,
- s INTEGER }
-
-dhpublicnumber OBJECT IDENTIFIER ::= {
- iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 }
-
-DomainParameters ::= SEQUENCE {
- p INTEGER, -- odd prime, p=jq +1
- g INTEGER, -- generator, g
- q INTEGER, -- factor of p-1
- j INTEGER OPTIONAL, -- subgroup factor, j>= 2
- validationParms ValidationParms OPTIONAL }
-
-ValidationParms ::= SEQUENCE {
- seed BIT STRING,
- pgenCounter INTEGER }
-
-id-dsa OBJECT IDENTIFIER ::= {
- iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 }
-
-Dss-Parms ::= SEQUENCE {
- p INTEGER,
- q INTEGER,
- g INTEGER }
-
-
-
-
-Housley, et. al. Standards Track [Page 76]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
--- x400 address syntax starts here
--- OR Names
-
-ORAddress ::= SEQUENCE {
- built-in-standard-attributes BuiltInStandardAttributes,
- built-in-domain-defined-attributes
- BuiltInDomainDefinedAttributes OPTIONAL,
- -- see also teletex-domain-defined-attributes
- 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 {
- country-name CountryName OPTIONAL,
- administration-domain-name AdministrationDomainName OPTIONAL,
- network-address [0] NetworkAddress OPTIONAL,
- -- see also extended-network-address
- terminal-identifier [1] TerminalIdentifier OPTIONAL,
- private-domain-name [2] PrivateDomainName OPTIONAL,
- organization-name [3] OrganizationName OPTIONAL,
- -- see also teletex-organization-name
- numeric-user-identifier [4] NumericUserIdentifier OPTIONAL,
- personal-name [5] PersonalName OPTIONAL,
- -- see also teletex-personal-name
- organizational-unit-names [6] OrganizationalUnitNames OPTIONAL
- -- see also teletex-organizational-unit-names -- }
-
-CountryName ::= [APPLICATION 1] CHOICE {
- x121-dcc-code NumericString
- (SIZE (ub-country-name-numeric-length)),
- iso-3166-alpha2-code PrintableString
- (SIZE (ub-country-name-alpha-length)) }
-
-AdministrationDomainName ::= [APPLICATION 2] CHOICE {
- numeric NumericString (SIZE (0..ub-domain-name-length)),
- printable PrintableString (SIZE (0..ub-domain-name-length)) }
-
-NetworkAddress ::= X121Address -- see also extended-network-address
-
-X121Address ::= NumericString (SIZE (1..ub-x121-address-length))
-
-TerminalIdentifier ::= PrintableString (SIZE (1..ub-terminal-id-length))
-
-PrivateDomainName ::= CHOICE {
-
-
-
-Housley, et. al. Standards Track [Page 77]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- numeric NumericString (SIZE (1..ub-domain-name-length)),
- printable PrintableString (SIZE (1..ub-domain-name-length)) }
-
-OrganizationName ::= PrintableString
- (SIZE (1..ub-organization-name-length))
--- see also teletex-organization-name
-
-NumericUserIdentifier ::= NumericString
- (SIZE (1..ub-numeric-user-id-length))
-
-PersonalName ::= SET {
- surname [0] PrintableString (SIZE (1..ub-surname-length)),
- given-name [1] PrintableString
- (SIZE (1..ub-given-name-length)) OPTIONAL,
- initials [2] PrintableString (SIZE (1..ub-initials-length)) OPTIONAL,
- generation-qualifier [3] PrintableString
- (SIZE (1..ub-generation-qualifier-length)) OPTIONAL }
--- see also teletex-personal-name
-
-OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units)
- OF OrganizationalUnitName
--- see also teletex-organizational-unit-names
-
-OrganizationalUnitName ::= PrintableString (SIZE
- (1..ub-organizational-unit-name-length))
-
--- Built-in Domain-defined Attributes
-
-BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE
- (1..ub-domain-defined-attributes) OF
- BuiltInDomainDefinedAttribute
-
-BuiltInDomainDefinedAttribute ::= SEQUENCE {
- type PrintableString (SIZE
- (1..ub-domain-defined-attribute-type-length)),
- value PrintableString (SIZE
- (1..ub-domain-defined-attribute-value-length))}
-
--- Extension Attributes
-
-ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) OF
- ExtensionAttribute
-
-ExtensionAttribute ::= SEQUENCE {
- extension-attribute-type [0] INTEGER (0..ub-extension-attributes),
- extension-attribute-value [1]
- ANY DEFINED BY extension-attribute-type }
-
-
-
-
-Housley, et. al. Standards Track [Page 78]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
--- Extension types and attribute values
---
-
-common-name INTEGER ::= 1
-
-CommonName ::= PrintableString (SIZE (1..ub-common-name-length))
-
-teletex-common-name INTEGER ::= 2
-
-TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length))
-
-teletex-organization-name INTEGER ::= 3
-
-TeletexOrganizationName ::=
- TeletexString (SIZE (1..ub-organization-name-length))
-
-teletex-personal-name INTEGER ::= 4
-
-TeletexPersonalName ::= SET {
- surname [0] TeletexString (SIZE (1..ub-surname-length)),
- given-name [1] TeletexString
- (SIZE (1..ub-given-name-length)) OPTIONAL,
- initials [2] TeletexString (SIZE (1..ub-initials-length)) OPTIONAL,
- generation-qualifier [3] TeletexString (SIZE
- (1..ub-generation-qualifier-length)) OPTIONAL }
-
-teletex-organizational-unit-names INTEGER ::= 5
-
-TeletexOrganizationalUnitNames ::= SEQUENCE SIZE
- (1..ub-organizational-units) OF TeletexOrganizationalUnitName
-
-TeletexOrganizationalUnitName ::= TeletexString
- (SIZE (1..ub-organizational-unit-name-length))
-
-pds-name INTEGER ::= 7
-
-PDSName ::= PrintableString (SIZE (1..ub-pds-name-length))
-
-physical-delivery-country-name INTEGER ::= 8
-
-PhysicalDeliveryCountryName ::= CHOICE {
- x121-dcc-code NumericString (SIZE (ub-country-name-numeric-length)),
- iso-3166-alpha2-code PrintableString
- (SIZE (ub-country-name-alpha-length)) }
-
-postal-code INTEGER ::= 9
-
-PostalCode ::= CHOICE {
-
-
-
-Housley, et. al. Standards Track [Page 79]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- numeric-code NumericString (SIZE (1..ub-postal-code-length)),
- printable-code PrintableString (SIZE (1..ub-postal-code-length)) }
-
-physical-delivery-office-name INTEGER ::= 10
-
-PhysicalDeliveryOfficeName ::= PDSParameter
-
-physical-delivery-office-number INTEGER ::= 11
-
-PhysicalDeliveryOfficeNumber ::= PDSParameter
-
-extension-OR-address-components INTEGER ::= 12
-
-ExtensionORAddressComponents ::= PDSParameter
-
-physical-delivery-personal-name INTEGER ::= 13
-
-PhysicalDeliveryPersonalName ::= PDSParameter
-
-physical-delivery-organization-name INTEGER ::= 14
-
-PhysicalDeliveryOrganizationName ::= PDSParameter
-
-extension-physical-delivery-address-components INTEGER ::= 15
-
-ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter
-
-unformatted-postal-address INTEGER ::= 16
-
-UnformattedPostalAddress ::= SET {
- printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines) OF
- PrintableString (SIZE (1..ub-pds-parameter-length)) OPTIONAL,
- teletex-string TeletexString
- (SIZE (1..ub-unformatted-address-length)) OPTIONAL }
-
-street-address INTEGER ::= 17
-
-StreetAddress ::= PDSParameter
-
-post-office-box-address INTEGER ::= 18
-
-PostOfficeBoxAddress ::= PDSParameter
-
-poste-restante-address INTEGER ::= 19
-
-PosteRestanteAddress ::= PDSParameter
-
-unique-postal-name INTEGER ::= 20
-
-
-
-Housley, et. al. Standards Track [Page 80]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-UniquePostalName ::= PDSParameter
-
-local-postal-attributes INTEGER ::= 21
-
-LocalPostalAttributes ::= PDSParameter
-
-PDSParameter ::= SET {
- printable-string PrintableString
- (SIZE(1..ub-pds-parameter-length)) OPTIONAL,
- teletex-string TeletexString
- (SIZE(1..ub-pds-parameter-length)) OPTIONAL }
-
-extended-network-address INTEGER ::= 22
-
-ExtendedNetworkAddress ::= CHOICE {
- e163-4-address SEQUENCE {
- number [0] NumericString (SIZE (1..ub-e163-4-number-length)),
- sub-address [1] NumericString
- (SIZE (1..ub-e163-4-sub-address-length)) OPTIONAL },
- psap-address [0] PresentationAddress }
-
-PresentationAddress ::= SEQUENCE {
- pSelector [0] EXPLICIT OCTET STRING OPTIONAL,
- sSelector [1] EXPLICIT OCTET STRING OPTIONAL,
- tSelector [2] EXPLICIT OCTET STRING OPTIONAL,
- nAddresses [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING }
-
-terminal-type INTEGER ::= 23
-
-TerminalType ::= INTEGER {
- telex (3),
- teletex (4),
- g3-facsimile (5),
- g4-facsimile (6),
- ia5-terminal (7),
- videotex (8) } (0..ub-integer-options)
-
--- Extension Domain-defined Attributes
-
-teletex-domain-defined-attributes INTEGER ::= 6
-
-TeletexDomainDefinedAttributes ::= SEQUENCE SIZE
- (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute
-
-TeletexDomainDefinedAttribute ::= SEQUENCE {
- type TeletexString
- (SIZE (1..ub-domain-defined-attribute-type-length)),
- value TeletexString
-
-
-
-Housley, et. al. Standards Track [Page 81]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- (SIZE (1..ub-domain-defined-attribute-value-length)) }
-
--- specifications of Upper Bounds shall be regarded as mandatory
--- from Annex B of ITU-T X.411 Reference Definition of MTS Parameter
--- Upper Bounds
-
--- Upper Bounds
-ub-name INTEGER ::= 32768
-ub-common-name INTEGER ::= 64
-ub-locality-name INTEGER ::= 128
-ub-state-name INTEGER ::= 128
-ub-organization-name INTEGER ::= 64
-ub-organizational-unit-name INTEGER ::= 64
-ub-title INTEGER ::= 64
-ub-match INTEGER ::= 128
-
-ub-emailaddress-length INTEGER ::= 128
-
-ub-common-name-length INTEGER ::= 64
-ub-country-name-alpha-length INTEGER ::= 2
-ub-country-name-numeric-length INTEGER ::= 3
-ub-domain-defined-attributes INTEGER ::= 4
-ub-domain-defined-attribute-type-length INTEGER ::= 8
-ub-domain-defined-attribute-value-length INTEGER ::= 128
-ub-domain-name-length INTEGER ::= 16
-ub-extension-attributes INTEGER ::= 256
-ub-e163-4-number-length INTEGER ::= 15
-ub-e163-4-sub-address-length INTEGER ::= 40
-ub-generation-qualifier-length INTEGER ::= 3
-ub-given-name-length INTEGER ::= 16
-ub-initials-length INTEGER ::= 5
-ub-integer-options INTEGER ::= 256
-ub-numeric-user-id-length INTEGER ::= 32
-ub-organization-name-length INTEGER ::= 64
-ub-organizational-unit-name-length INTEGER ::= 32
-ub-organizational-units INTEGER ::= 4
-ub-pds-name-length INTEGER ::= 16
-ub-pds-parameter-length INTEGER ::= 30
-ub-pds-physical-address-lines INTEGER ::= 6
-ub-postal-code-length INTEGER ::= 16
-ub-surname-length INTEGER ::= 40
-ub-terminal-id-length INTEGER ::= 24
-ub-unformatted-address-length INTEGER ::= 180
-ub-x121-address-length INTEGER ::= 16
-
--- Note - upper bounds on string types, such as TeletexString, are
--- measured in characters. Excepting PrintableString or IA5String, a
--- significantly greater number of octets will be required to hold
-
-
-
-Housley, et. al. Standards Track [Page 82]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
--- such a value. As a minimum, 16 octets, or twice the specified upper
--- bound, whichever is the larger, should be allowed for TeletexString.
--- For UTF8String or UniversalString at least four times the upper
--- bound should be allowed.
-
-END
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Housley, et. al. Standards Track [Page 83]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-A.2 Implicitly Tagged Module, 1988 Syntax
-
-PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1)
- security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2)}
-
-DEFINITIONS IMPLICIT TAGS ::=
-
-BEGIN
-
--- EXPORTS ALL --
-
-IMPORTS
- id-pkix, id-pe, id-qt, id-kp, id-qt-unotice, id-qt-cps,
- id-ad, id-ad-ocsp, id-ad-caIssuers,
- -- delete following line if "new" types are supported --
- BMPString, UniversalString, UTF8String, -- end "new" types
- ORAddress, Name, RelativeDistinguishedName,
- CertificateSerialNumber,
- CertificateList, AlgorithmIdentifier, ub-name,
- Attribute, DirectoryString
- 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
-
-id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29}
-
--- authority key identifier OID and syntax
-
-id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 }
-
-AuthorityKeyIdentifier ::= SEQUENCE {
- keyIdentifier [0] KeyIdentifier OPTIONAL,
- authorityCertIssuer [1] GeneralNames OPTIONAL,
- authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }
- -- authorityCertIssuer and authorityCertSerialNumber shall both
- -- be present or both be absent
-
-KeyIdentifier ::= OCTET STRING
-
--- subject key identifier OID and syntax
-
-id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 }
-
-SubjectKeyIdentifier ::= KeyIdentifier
-
-
-
-
-Housley, et. al. Standards Track [Page 84]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
--- key usage extension OID and syntax
-
-id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 }
-
-KeyUsage ::= BIT STRING {
- digitalSignature (0),
- nonRepudiation (1),
- keyEncipherment (2),
- dataEncipherment (3),
- keyAgreement (4),
- keyCertSign (5),
- cRLSign (6),
- encipherOnly (7),
- decipherOnly (8) }
-
--- private key usage period extension OID and syntax
-
-id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 }
-
-PrivateKeyUsagePeriod ::= SEQUENCE {
- notBefore [0] GeneralizedTime OPTIONAL,
- notAfter [1] GeneralizedTime OPTIONAL }
- -- either notBefore or notAfter shall be present
-
--- certificate policies extension OID and syntax
-
-id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 }
-
-CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
-
-PolicyInformation ::= SEQUENCE {
- policyIdentifier CertPolicyId,
- policyQualifiers SEQUENCE SIZE (1..MAX) OF
- PolicyQualifierInfo OPTIONAL }
-
-CertPolicyId ::= OBJECT IDENTIFIER
-
-PolicyQualifierInfo ::= SEQUENCE {
- policyQualifierId PolicyQualifierId,
- qualifier ANY DEFINED BY policyQualifierId }
-
--- Implementations that recognize additional policy qualifiers shall
--- augment the following definition for PolicyQualifierId
-
-PolicyQualifierId ::=
- OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )
-
--- CPS pointer qualifier
-
-
-
-Housley, et. al. Standards Track [Page 85]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-CPSuri ::= IA5String
-
--- user notice qualifier
-
-UserNotice ::= SEQUENCE {
- noticeRef NoticeReference OPTIONAL,
- explicitText DisplayText OPTIONAL}
-
-NoticeReference ::= SEQUENCE {
- organization DisplayText,
- noticeNumbers SEQUENCE OF INTEGER }
-
-DisplayText ::= CHOICE {
- visibleString VisibleString (SIZE (1..200)),
- bmpString BMPString (SIZE (1..200)),
- utf8String UTF8String (SIZE (1..200)) }
-
--- policy mapping extension OID and syntax
-
-id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 }
-
-PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
- issuerDomainPolicy CertPolicyId,
- subjectDomainPolicy CertPolicyId }
-
--- subject alternative name extension OID and syntax
-
-id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 }
-
-SubjectAltName ::= GeneralNames
-
-GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
-
-GeneralName ::= CHOICE {
- otherName [0] AnotherName,
- rfc822Name [1] IA5String,
- dNSName [2] IA5String,
- x400Address [3] ORAddress,
- directoryName [4] Name,
- ediPartyName [5] EDIPartyName,
- uniformResourceIdentifier [6] IA5String,
- iPAddress [7] OCTET STRING,
- registeredID [8] OBJECT IDENTIFIER }
-
--- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as
--- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax
-
-AnotherName ::= SEQUENCE {
-
-
-
-Housley, et. al. Standards Track [Page 86]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- type-id OBJECT IDENTIFIER,
- value [0] EXPLICIT ANY DEFINED BY type-id }
-
-EDIPartyName ::= SEQUENCE {
- nameAssigner [0] DirectoryString OPTIONAL,
- partyName [1] DirectoryString }
-
--- issuer alternative name extension OID and syntax
-
-id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 }
-
-IssuerAltName ::= GeneralNames
-
-id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 }
-
-SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute
-
--- basic constraints extension OID and syntax
-
-id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 }
-
-BasicConstraints ::= SEQUENCE {
- cA BOOLEAN DEFAULT FALSE,
- pathLenConstraint INTEGER (0..MAX) OPTIONAL }
-
--- name constraints extension OID and syntax
-
-id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 }
-
-NameConstraints ::= SEQUENCE {
- permittedSubtrees [0] GeneralSubtrees OPTIONAL,
- excludedSubtrees [1] GeneralSubtrees OPTIONAL }
-
-GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
-
-GeneralSubtree ::= SEQUENCE {
- base GeneralName,
- minimum [0] BaseDistance DEFAULT 0,
- maximum [1] BaseDistance OPTIONAL }
-
-BaseDistance ::= INTEGER (0..MAX)
-
--- policy constraints extension OID and syntax
-
-id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 }
-
-PolicyConstraints ::= SEQUENCE {
- requireExplicitPolicy [0] SkipCerts OPTIONAL,
-
-
-
-Housley, et. al. Standards Track [Page 87]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- inhibitPolicyMapping [1] SkipCerts OPTIONAL }
-
-SkipCerts ::= INTEGER (0..MAX)
-
--- CRL distribution points extension OID and syntax
-
-id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31}
-
-CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
-
-DistributionPoint ::= SEQUENCE {
- distributionPoint [0] DistributionPointName OPTIONAL,
- reasons [1] ReasonFlags OPTIONAL,
- cRLIssuer [2] GeneralNames OPTIONAL }
-
-DistributionPointName ::= CHOICE {
- fullName [0] GeneralNames,
- nameRelativeToCRLIssuer [1] RelativeDistinguishedName }
-
-ReasonFlags ::= BIT STRING {
- unused (0),
- keyCompromise (1),
- cACompromise (2),
- affiliationChanged (3),
- superseded (4),
- cessationOfOperation (5),
- certificateHold (6) }
-
--- extended key usage extension OID and syntax
-
-id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37}
-
-ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
-
-KeyPurposeId ::= OBJECT IDENTIFIER
-
--- extended key purpose OIDs
-id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
-id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 }
-id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 }
-id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 }
-id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 }
-id-kp-ipsecTunnel OBJECT IDENTIFIER ::= { id-kp 6 }
-id-kp-ipsecUser OBJECT IDENTIFIER ::= { id-kp 7 }
-id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }
-
--- authority info access
-
-
-
-
-Housley, et. al. Standards Track [Page 88]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }
-
-AuthorityInfoAccessSyntax ::=
- SEQUENCE SIZE (1..MAX) OF AccessDescription
-
-AccessDescription ::= SEQUENCE {
- accessMethod OBJECT IDENTIFIER,
- accessLocation GeneralName }
-
--- CRL number extension OID and syntax
-
-id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }
-
-CRLNumber ::= INTEGER (0..MAX)
-
--- issuing distribution point extension OID and syntax
-
-id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 }
-
-IssuingDistributionPoint ::= SEQUENCE {
- distributionPoint [0] DistributionPointName OPTIONAL,
- onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE,
- onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE,
- onlySomeReasons [3] ReasonFlags OPTIONAL,
- indirectCRL [4] BOOLEAN DEFAULT FALSE }
-
-
-id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }
-
--- deltaCRLIndicator ::= BaseCRLNumber
-
-BaseCRLNumber ::= CRLNumber
-
--- CRL reasons extension OID and syntax
-
-id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 }
-
-CRLReason ::= ENUMERATED {
- unspecified (0),
- keyCompromise (1),
- cACompromise (2),
- affiliationChanged (3),
- superseded (4),
- cessationOfOperation (5),
- certificateHold (6),
- removeFromCRL (8) }
-
--- certificate issuer CRL entry extension OID and syntax
-
-
-
-Housley, et. al. Standards Track [Page 89]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 }
-
-CertificateIssuer ::= GeneralNames
-
--- hold instruction extension OID and syntax
-
-id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 }
-
-HoldInstructionCode ::= OBJECT IDENTIFIER
-
--- ANSI x9 holdinstructions
-
--- ANSI x9 arc holdinstruction arc
-holdInstruction OBJECT IDENTIFIER ::=
- {joint-iso-itu-t(2) member-body(2) us(840) x9cm(10040) 2}
-
--- ANSI X9 holdinstructions referenced by this standard
-id-holdinstruction-none OBJECT IDENTIFIER ::=
- {holdInstruction 1} -- deprecated
-id-holdinstruction-callissuer OBJECT IDENTIFIER ::=
- {holdInstruction 2}
-id-holdinstruction-reject OBJECT IDENTIFIER ::=
- {holdInstruction 3}
-
--- invalidity date CRL entry extension OID and syntax
-
-id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 }
-
-InvalidityDate ::= GeneralizedTime
-
-END
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Housley, et. al. Standards Track [Page 90]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-Appendix B. 1993 ASN.1 Structures and OIDs
-
-
-B.1 Explicitly Tagged Module, 1993 Syntax
-
-PKIX1Explicit93 {iso(1) identified-organization(3) dod(6) internet(1)
- security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-93(3)}
-
-
-DEFINITIONS EXPLICIT TAGS ::=
-
-BEGIN
-
--- EXPORTS ALL --
-
-IMPORTS
- authorityKeyIdentifier, subjectKeyIdentifier, keyUsage,
- extendedKeyUsage, privateKeyUsagePeriod, certificatePolicies,
- policyMappings, subjectAltName, issuerAltName,
- basicConstraints, nameConstraints, policyConstraints,
- cRLDistributionPoints, subjectDirectoryAttributes,
- cRLNumber, reasonCode, instructionCode, invalidityDate,
- issuingDistributionPoint, certificateIssuer,
- deltaCRLIndicator, authorityInfoAccess, id-ce
- FROM PKIX1Implicit93 {iso(1) identified-organization(3)
- dod(6) internet(1) security(5) mechanisms(5) pkix(7)
- id-mod(0) id-pkix1-implicit-93(4)} ;
-
---
- -- Locally defined OIDs --
-
-id-pkix OBJECT IDENTIFIER ::=
- { iso(1) identified-organization(3) dod(6) internet(1)
- security(5) mechanisms(5) pkix(7) }
-
--- PKIX arcs
--- arc for private certificate extensions
-id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
- -- arc for policy qualifier types
-id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
--- arc for extended key purpose OIDS
-id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
--- arc for access descriptors
-id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
-
--- policyQualifierIds for Internet policy qualifiers
-id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 }
- -- OID for CPS qualifier
-
-
-
-Housley, et. al. Standards Track [Page 91]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 }
- -- OID for user notice qualifier
-
--- based on excerpts from AuthenticationFramework
--- {joint-iso-ccitt ds(5) modules(1) authenticationFramework(7) 2}
-
- -- Public Key Certificate --
-
-Certificate ::= SIGNED { SEQUENCE {
- version [0] Version DEFAULT v1,
- serialNumber CertificateSerialNumber,
- signature AlgorithmIdentifier,
- issuer Name,
- validity Validity,
- subject Name,
- subjectPublicKeyInfo SubjectPublicKeyInfo,
- issuerUniqueIdentifier [1] IMPLICIT UniqueIdentifier OPTIONAL,
- ---if present, version shall be v2 or v3--
- subjectUniqueIdentifier [2] IMPLICIT UniqueIdentifier OPTIONAL,
- ---if present, version shall be v2 or v3--
- extensions [3] Extensions OPTIONAL
- --if present, version shall be v3--} }
-
-UniqueIdentifier ::= BIT STRING
-
-Version ::= INTEGER { v1(0), v2(1), v3(2) }
-
-CertificateSerialNumber ::= INTEGER
-
-Validity ::= SEQUENCE {
- notBefore Time,
- notAfter Time }
-
-Time ::= CHOICE {
- utcTime UTCTime,
- generalTime GeneralizedTime }
-
-SubjectPublicKeyInfo ::= SEQUENCE{
- algorithm AlgorithmIdentifier,
- subjectPublicKey BIT STRING}
-
-Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
-
-Extension ::= SEQUENCE {
- extnId EXTENSION.&id ({ExtensionSet}),
- critical BOOLEAN DEFAULT FALSE,
- extnValue OCTET STRING }
- -- contains a DER encoding of a value of type
-
-
-
-Housley, et. al. Standards Track [Page 92]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- -- &ExtnType for the
- -- extension object identified by extnId --
-
--- The following information object set is defined to constrain the
--- set of legal certificate extensions.
-
-ExtensionSet EXTENSION ::= { authorityKeyIdentifier |
- subjectKeyIdentifier |
- keyUsage |
- extendedKeyUsage |
- privateKeyUsagePeriod |
- certificatePolicies |
- policyMappings |
- subjectAltName |
- issuerAltName |
- basicConstraints |
- nameConstraints |
- policyConstraints |
- cRLDistributionPoints |
- subjectDirectoryAttributes |
- authorityInfoAccess }
-
-EXTENSION ::= CLASS {
- &id OBJECT IDENTIFIER UNIQUE,
- &ExtnType }
-WITH SYNTAX {
- SYNTAX &ExtnType
- IDENTIFIED BY &id }
-
- -- Certificate Revocation List --
-
-CertificateList ::= SIGNED { SEQUENCE {
- version Version OPTIONAL, -- if present, shall be v2
- signature AlgorithmIdentifier,
- issuer Name,
- thisUpdate Time,
- nextUpdate Time OPTIONAL,
- revokedCertificates SEQUENCE OF SEQUENCE {
- userCertificate CertificateSerialNumber,
- revocationDate Time,
- crlEntryExtensions EntryExtensions OPTIONAL } OPTIONAL,
- crlExtensions [0] CRLExtensions OPTIONAL }}
-
-CRLExtensions ::= SEQUENCE SIZE (1..MAX) OF CRLExtension
-
-CRLExtension ::= SEQUENCE {
- extnId EXTENSION.&id ({CRLExtensionSet}),
- critical BOOLEAN DEFAULT FALSE,
-
-
-
-Housley, et. al. Standards Track [Page 93]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- extnValue OCTET STRING }
- -- contains a DER encoding of a value of type
- -- &ExtnType for the
- -- extension object identified by extnId --
-
--- The following information object set is defined to constrain the
--- set of legal CRL extensions.
-
-CRLExtensionSet EXTENSION ::= { authorityKeyIdentifier |
- issuerAltName |
- cRLNumber |
- deltaCRLIndicator |
- issuingDistributionPoint }
-
--- EXTENSION defined above for certificates
-
-EntryExtensions ::= SEQUENCE SIZE (1..MAX) OF EntryExtension
-
-EntryExtension ::= SEQUENCE {
- extnId EXTENSION.&id ({EntryExtensionSet}),
- critical BOOLEAN DEFAULT FALSE,
- extnValue OCTET STRING }
- -- contains a DER encoding of a value of type
- -- &ExtnType for the
- -- extension object identified by extnId --
-
--- The following information object set is defined to constrain the
--- set of legal CRL entry extensions.
-
-EntryExtensionSet EXTENSION ::= { reasonCode |
- instructionCode |
- invalidityDate |
- certificateIssuer }
-
- -- information object classes used in the defintion --
- -- of certificates and CRLs --
-
--- Parameterized Type SIGNED --
-
- SIGNED { ToBeSigned } ::= SEQUENCE {
- toBeSigned ToBeSigned,
- algorithm AlgorithmIdentifier,
- signature BIT STRING
- }
-
--- Definition of AlgorithmIdentifier
--- ISO definition was:
---
-
-
-
-Housley, et. al. Standards Track [Page 94]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
--- AlgorithmIdentifier ::= SEQUENCE {
--- algorithm ALGORITHM.&id({SupportedAlgorithms}),
--- parameters ALGORITHM.&Type({SupportedAlgorithms}
--- { @algorithm}) OPTIONAL }
--- Definition of ALGORITHM
--- ALGORITHM ::= TYPE-IDENTIFIER
-
--- The following PKIX definition replaces the X.509 definition
---
-
-AlgorithmIdentifier ::= SEQUENCE {
- algorithm ALGORITHM-ID.&id({SupportedAlgorithms}),
- parameters ALGORITHM-ID.&Type({SupportedAlgorithms}
- { @algorithm}) OPTIONAL }
-
--- Definition of ALGORITHM-ID
-
- ALGORITHM-ID ::= CLASS {
- &id OBJECT IDENTIFIER UNIQUE,
- &Type OPTIONAL
- }
- WITH SYNTAX { OID &id [PARMS &Type] }
-
--- The definition of SupportedAlgorithms may be modified as this
--- document does not specify a mandatory algorithm set. In addition,
--- the set is specified as extensible, since additional algorithms
--- may be supported
-
-SupportedAlgorithms ALGORITHM-ID ::= { ..., -- extensible
- rsaPublicKey |
- rsaSHA-1 |
- rsaMD5 |
- rsaMD2 |
- dssPublicKey |
- dsaSHA-1 |
- dhPublicKey }
-
--- OIDs and parameter structures for ALGORITHM-IDs used
--- in this specification
-
-rsaPublicKey ALGORITHM-ID ::= { OID rsaEncryption PARMS NULL }
-
-rsaSHA-1 ALGORITHM-ID ::= { OID sha1WithRSAEncryption PARMS NULL }
-
-rsaMD5 ALGORITHM-ID ::= { OID md5WithRSAEncryption PARMS NULL }
-
-rsaMD2 ALGORITHM-ID ::= { OID md2WithRSAEncryption PARMS NULL }
-
-
-
-
-Housley, et. al. Standards Track [Page 95]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-dssPublicKey ALGORITHM-ID ::= { OID id-dsa PARMS Dss-Parms }
-
-dsaSHA-1 ALGORITHM-ID ::= { OID id-dsa-with-sha1 }
-
-dhPublicKey ALGORITHM-ID ::= {OID dhpublicnumber PARMS DomainParameters}
-
--- algorithm identifiers and parameter structures
-
-pkcs-1 OBJECT IDENTIFIER ::= {
- iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 }
-
-rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 }
-
-md2WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 2 }
-
-md5WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 4 }
-
-sha1WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 5 }
-
-id-dsa-with-sha1 OBJECT IDENTIFIER ::= {
- iso(1) member-body(2) us(840) x9-57 (10040) x9algorithm(4) 3 }
-
-Dss-Sig-Value ::= SEQUENCE {
- r INTEGER,
- s INTEGER }
-
-dhpublicnumber OBJECT IDENTIFIER ::= {
- iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 }
-
-DomainParameters ::= SEQUENCE {
- p INTEGER, -- odd prime, p=jq +1
- g INTEGER, -- generator, g
- q INTEGER, -- factor of p-1
- j INTEGER OPTIONAL, -- subgroup factor, j>= 2
- validationParms ValidationParms OPTIONAL }
-
-ValidationParms ::= SEQUENCE {
- seed BIT STRING,
- pgenCounter INTEGER }
-
-id-dsa OBJECT IDENTIFIER ::= {
- iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 }
-
-Dss-Parms ::= SEQUENCE {
- p INTEGER,
- q INTEGER,
- g INTEGER }
-
-
-
-
-Housley, et. al. Standards Track [Page 96]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- -- The ASN.1 in this section supports the Name type
- -- and the directoryAttribute extension
-
--- attribute data types --
-
-Attribute ::= SEQUENCE {
- type ATTRIBUTE.&id ({SupportedAttributes}),
- values SET SIZE (1 .. MAX) OF ATTRIBUTE.&Type
- ({SupportedAttributes}{@type})}
-
-AttributeTypeAndValue ::= SEQUENCE {
- type ATTRIBUTE.&id ({SupportedAttributes}),
- value ATTRIBUTE.&Type ({SupportedAttributes}{@type})}
-
--- naming data types --
-
-Name ::= CHOICE { -- only one possibility for now --
- rdnSequence RDNSequence }
-
-RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
-
-RelativeDistinguishedName ::=
- SET SIZE (1 .. MAX) OF AttributeTypeAndValue
-
-ID ::= OBJECT IDENTIFIER
-
--- ATTRIBUTE information object class specification
--- Note: This has been greatly simplified for PKIX !!
-
-ATTRIBUTE ::= CLASS {
- &Type,
- &id OBJECT IDENTIFIER UNIQUE }
-WITH SYNTAX {
- WITH SYNTAX &Type ID &id }
-
--- suggested naming attributes
--- Definition of the following information object set may be
--- augmented to meet local requirements. Note that deleting
--- members of the set may prevent interoperability with
--- conforming implementations.
-
-SupportedAttributes ATTRIBUTE ::= {
- name | commonName | surname | givenName | initials |
- generationQualifier | dnQualifier | countryName |
- localityName | stateOrProvinceName | organizationName |
- organizationalUnitName | title | pkcs9email }
-
-name ATTRIBUTE ::= {
-
-
-
-Housley, et. al. Standards Track [Page 97]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- WITH SYNTAX DirectoryString { ub-name }
- ID id-at-name }
-
-commonName ATTRIBUTE ::= {
- WITH SYNTAX DirectoryString {ub-common-name}
- ID id-at-commonName }
-
-surname ATTRIBUTE ::= {
- WITH SYNTAX DirectoryString {ub-name}
- ID id-at-surname }
-
-givenName ATTRIBUTE ::= {
- WITH SYNTAX DirectoryString {ub-name}
- ID id-at-givenName }
-
-initials ATTRIBUTE ::= {
- WITH SYNTAX DirectoryString {ub-name}
- ID id-at-initials }
-
-generationQualifier ATTRIBUTE ::= {
- WITH SYNTAX DirectoryString {ub-name}
- ID id-at-generationQualifier}
-
-dnQualifier ATTRIBUTE ::= {
- WITH SYNTAX PrintableString
- ID id-at-dnQualifier }
-
-
-countryName ATTRIBUTE ::= {
- WITH SYNTAX PrintableString (SIZE (2))
- -- IS 3166 codes only
- ID id-at-countryName }
-
-localityName ATTRIBUTE ::= {
- WITH SYNTAX DirectoryString {ub-locality-name}
- ID id-at-localityName }
-
-stateOrProvinceName ATTRIBUTE ::= {
- WITH SYNTAX DirectoryString {ub-state-name}
- ID id-at-stateOrProvinceName }
-
-organizationName ATTRIBUTE ::= {
- WITH SYNTAX DirectoryString {ub-organization-name}
- ID id-at-organizationName }
-
-organizationalUnitName ATTRIBUTE ::= {
- WITH SYNTAX DirectoryString {ub-organizational-unit-name}
- ID id-at-organizationalUnitName }
-
-
-
-Housley, et. al. Standards Track [Page 98]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-title ATTRIBUTE ::= {
- WITH SYNTAX DirectoryString {ub-title}
- ID id-at-title }
-
- -- Legacy attributes
-
-pkcs9email ATTRIBUTE ::= {
- WITH SYNTAX PHGString,
- ID emailAddress }
-
-PHGString ::= IA5String (SIZE(1..ub-emailaddress-length))
-
-pkcs-9 OBJECT IDENTIFIER ::=
- { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 }
-
-emailAddress OBJECT IDENTIFIER ::= { pkcs-9 1 }
-
- -- object identifiers for Name type and directory attribute support
-
--- Object identifier assignments --
-
-id-at OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 4}
-
--- Attributes --
-
-id-at-commonName OBJECT IDENTIFIER ::= {id-at 3}
-id-at-surname OBJECT IDENTIFIER ::= {id-at 4}
-id-at-countryName OBJECT IDENTIFIER ::= {id-at 6}
-id-at-localityName OBJECT IDENTIFIER ::= {id-at 7}
-id-at-stateOrProvinceName OBJECT IDENTIFIER ::= {id-at 8}
-id-at-organizationName OBJECT IDENTIFIER ::= {id-at 10}
-id-at-organizationalUnitName OBJECT IDENTIFIER ::= {id-at 11}
-id-at-title OBJECT IDENTIFIER ::= {id-at 12}
-id-at-name OBJECT IDENTIFIER ::= {id-at 41}
-id-at-givenName OBJECT IDENTIFIER ::= {id-at 42}
-id-at-initials OBJECT IDENTIFIER ::= {id-at 43}
-id-at-generationQualifier OBJECT IDENTIFIER ::= {id-at 44}
-id-at-dnQualifier OBJECT IDENTIFIER ::= {id-at 46}
-
--- Directory string type, used extensively in Name types --
-
-DirectoryString { INTEGER:maxSize } ::= CHOICE {
- teletexString TeletexString (SIZE (1..maxSize)),
- printableString PrintableString (SIZE (1..maxSize)),
- universalString UniversalString (SIZE (1..maxSize)),
- bmpString BMPString (SIZE(1..maxSize)),
- utf8String UTF8String (SIZE(1..maxSize))
- }
-
-
-
-Housley, et. al. Standards Track [Page 99]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- -- End of ASN.1 for Name type and directory attribute support --
-
- -- The ASN.1 in this section supports X.400 style names --
- -- for implementations that use the x400Address component --
- -- of GeneralName. --
-
-ORAddress ::= SEQUENCE {
- built-in-standard-attributes BuiltInStandardAttributes,
- built-in-domain-defined-attributes
- BuiltInDomainDefinedAttributes OPTIONAL,
- -- see also teletex-domain-defined-attributes
- 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 {
- country-name CountryName OPTIONAL,
- administration-domain-name AdministrationDomainName OPTIONAL,
- network-address [0] NetworkAddress OPTIONAL,
- -- see also extended-network-address
- terminal-identifier [1] TerminalIdentifier OPTIONAL,
- private-domain-name [2] PrivateDomainName OPTIONAL,
- organization-name [3] OrganizationName OPTIONAL,
- -- see also teletex-organization-name
- numeric-user-identifier [4] NumericUserIdentifier OPTIONAL,
- personal-name [5] PersonalName OPTIONAL,
- -- see also teletex-personal-name
- organizational-unit-names [6] OrganizationalUnitNames OPTIONAL
- -- see also teletex-organizational-unit-names -- }
-
-CountryName ::= [APPLICATION 1] CHOICE {
- x121-dcc-code NumericString
- (SIZE (ub-country-name-numeric-length)),
- iso-3166-alpha2-code PrintableString
- (SIZE (ub-country-name-alpha-length)) }
-
-AdministrationDomainName ::= [APPLICATION 2] CHOICE {
- numeric NumericString (SIZE (0..ub-domain-name-length)),
- printable PrintableString (SIZE (0..ub-domain-name-length)) }
-
-NetworkAddress ::= X121Address
--- see also extended-network-address
-
-
-
-
-Housley, et. al. Standards Track [Page 100]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-X121Address ::= NumericString (SIZE (1..ub-x121-address-length))
-
-TerminalIdentifier ::= PrintableString (SIZE (1..ub-terminal-id-length))
-
-PrivateDomainName ::= CHOICE {
- numeric NumericString (SIZE (1..ub-domain-name-length)),
- printable PrintableString (SIZE (1..ub-domain-name-length)) }
-
-OrganizationName ::= PrintableString
- (SIZE (1..ub-organization-name-length))
--- see also teletex-organization-name
-
-NumericUserIdentifier ::= NumericString
- (SIZE (1..ub-numeric-user-id-length))
-
-PersonalName ::= SET {
- surname [0] PrintableString (SIZE (1..ub-surname-length)),
- given-name [1] PrintableString
- (SIZE (1..ub-given-name-length)) OPTIONAL,
- initials [2] PrintableString
- (SIZE (1..ub-initials-length)) OPTIONAL,
- generation-qualifier [3] PrintableString
- (SIZE (1..ub-generation-qualifier-length)) OPTIONAL}
--- see also teletex-personal-name
-
-OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units)
- OF OrganizationalUnitName
--- see also teletex-organizational-unit-names
-
-OrganizationalUnitName ::= PrintableString (SIZE
- (1..ub-organizational-unit-name-length))
-
--- Built-in Domain-defined Attributes
-BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE
- (1..ub-domain-defined-attributes) OF
- BuiltInDomainDefinedAttribute
-
-BuiltInDomainDefinedAttribute ::= SEQUENCE {
- type PrintableString (SIZE
- (1..ub-domain-defined-attribute-type-length)),
- value PrintableString (SIZE
- (1..ub-domain-defined-attribute-value-length)) }
-
--- Extension Attributes
-
-ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes)
- OF ExtensionAttribute
-ExtensionAttribute ::= SEQUENCE {
-
-
-
-Housley, et. al. Standards Track [Page 101]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- extension-attribute-type [0] EXTENSION-ATTRIBUTE.&id
- ({ExtensionAttributeTable}),
- extension-attribute-value [1] EXTENSION-ATTRIBUTE.&Type
- ({ExtensionAttributeTable} {@extension-attribute-type}) }
-
-EXTENSION-ATTRIBUTE ::= CLASS {
- &id INTEGER (0..ub-extension-attributes) UNIQUE,
- &Type }
-WITH SYNTAX {&Type IDENTIFIED BY &id}
-
-ExtensionAttributeTable EXTENSION-ATTRIBUTE ::= {
- common-name |
- teletex-common-name |
- teletex-organization-name |
- teletex-personal-name |
- teletex-organizational-unit-names |
- teletex-domain-defined-attributes |
- pds-name |
- physical-delivery-country-name |
- postal-code |
- physical-delivery-office-name |
- physical-delivery-office-number |
- extension-OR-address-components |
- physical-delivery-personal-name |
- physical-delivery-organization-name |
- extension-physical-delivery-address-components |
- unformatted-postal-address |
- street-address |
- post-office-box-address |
- poste-restante-address |
- unique-postal-name |
- local-postal-attributes |
- extended-network-address |
- terminal-type }
-
--- Extension Standard Attributes
-
-common-name EXTENSION-ATTRIBUTE ::= {CommonName IDENTIFIED BY 1}
-
-CommonName ::= PrintableString (SIZE (1..ub-common-name-length))
-
-teletex-common-name EXTENSION-ATTRIBUTE ::=
- {TeletexCommonName IDENTIFIED BY 2}
-
-TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length))
-
-teletex-organization-name EXTENSION-ATTRIBUTE ::=
- {TeletexOrganizationName IDENTIFIED BY 3}
-
-
-
-Housley, et. al. Standards Track [Page 102]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-TeletexOrganizationName ::=
- TeletexString (SIZE (1..ub-organization-name-length))
-
-teletex-personal-name EXTENSION-ATTRIBUTE ::=
- {TeletexPersonalName IDENTIFIED BY 4}
-
-TeletexPersonalName ::= SET {
- surname [0] TeletexString (SIZE (1..ub-surname-length)),
- given-name [1] TeletexString
- (SIZE (1..ub-given-name-length)) OPTIONAL,
- initials [2] TeletexString (SIZE (1..ub-initials-length)) OPTIONAL,
- generation-qualifier [3] TeletexString (SIZE
- (1..ub-generation-qualifier-length)) OPTIONAL }
-
-teletex-organizational-unit-names EXTENSION-ATTRIBUTE ::=
- {TeletexOrganizationalUnitNames IDENTIFIED BY 5}
-
-TeletexOrganizationalUnitNames ::= SEQUENCE SIZE
- (1..ub-organizational-units) OF TeletexOrganizationalUnitName
-
-TeletexOrganizationalUnitName ::= TeletexString
- (SIZE (1..ub-organizational-unit-name-length))
-
-pds-name EXTENSION-ATTRIBUTE ::= {PDSName IDENTIFIED BY 7}
-
-PDSName ::= PrintableString (SIZE (1..ub-pds-name-length))
-
-physical-delivery-country-name EXTENSION-ATTRIBUTE ::=
- {PhysicalDeliveryCountryName IDENTIFIED BY 8}
-
-PhysicalDeliveryCountryName ::= CHOICE {
- x121-dcc-code NumericString (SIZE (ub-country-name-numeric-length)),
- iso-3166-alpha2-code PrintableString
- (SIZE (ub-country-name-alpha-length)) }
-
-postal-code EXTENSION-ATTRIBUTE ::= {PostalCode IDENTIFIED BY 9}
-
-PostalCode ::= CHOICE {
- numeric-code NumericString (SIZE (1..ub-postal-code-length)),
- printable-code PrintableString (SIZE (1..ub-postal-code-length)) }
-
-physical-delivery-office-name EXTENSION-ATTRIBUTE ::=
- {PhysicalDeliveryOfficeName IDENTIFIED BY 10}
-
-PhysicalDeliveryOfficeName ::= PDSParameter
-
-physical-delivery-office-number EXTENSION-ATTRIBUTE ::=
- {PhysicalDeliveryOfficeNumber IDENTIFIED BY 11}
-
-
-
-Housley, et. al. Standards Track [Page 103]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-PhysicalDeliveryOfficeNumber ::= PDSParameter
-
-extension-OR-address-components EXTENSION-ATTRIBUTE ::=
- {ExtensionORAddressComponents IDENTIFIED BY 12}
-
-ExtensionORAddressComponents ::= PDSParameter
-
-physical-delivery-personal-name EXTENSION-ATTRIBUTE ::=
- {PhysicalDeliveryPersonalName IDENTIFIED BY 13}
-
-PhysicalDeliveryPersonalName ::= PDSParameter
-
-physical-delivery-organization-name EXTENSION-ATTRIBUTE ::=
- {PhysicalDeliveryOrganizationName IDENTIFIED BY 14}
-
-PhysicalDeliveryOrganizationName ::= PDSParameter
-
-extension-physical-delivery-address-components EXTENSION-ATTRIBUTE ::=
- {ExtensionPhysicalDeliveryAddressComponents IDENTIFIED BY 15}
-
-ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter
-
-unformatted-postal-address EXTENSION-ATTRIBUTE ::=
- {UnformattedPostalAddress IDENTIFIED BY 16}
-
-UnformattedPostalAddress ::= SET {
- printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines) OF
- PrintableString (SIZE (1..ub-pds-parameter-length)) OPTIONAL,
- teletex-string TeletexString (SIZE
- (1..ub-unformatted-address-length)) OPTIONAL }
-
-street-address EXTENSION-ATTRIBUTE ::=
- {StreetAddress IDENTIFIED BY 17}
-
-StreetAddress ::= PDSParameter
-
-post-office-box-address EXTENSION-ATTRIBUTE ::=
- {PostOfficeBoxAddress IDENTIFIED BY 18}
-
-PostOfficeBoxAddress ::= PDSParameter
-
-poste-restante-address EXTENSION-ATTRIBUTE ::=
- {PosteRestanteAddress IDENTIFIED BY 19}
-
-PosteRestanteAddress ::= PDSParameter
-
-unique-postal-name EXTENSION-ATTRIBUTE ::=
- {UniquePostalName IDENTIFIED BY 20}
-
-
-
-Housley, et. al. Standards Track [Page 104]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-UniquePostalName ::= PDSParameter
-
-local-postal-attributes EXTENSION-ATTRIBUTE ::=
- {LocalPostalAttributes IDENTIFIED BY 21}
-
-LocalPostalAttributes ::= PDSParameter
-
-PDSParameter ::= SET {
- printable-string PrintableString
- (SIZE(1..ub-pds-parameter-length)) OPTIONAL,
- teletex-string TeletexString
- (SIZE(1..ub-pds-parameter-length)) OPTIONAL }
-
-extended-network-address EXTENSION-ATTRIBUTE ::=
- {ExtendedNetworkAddress IDENTIFIED BY 22}
-
-ExtendedNetworkAddress ::= CHOICE {
- e163-4-address SEQUENCE {
- number [0] NumericString
- (SIZE (1..ub-e163-4-number-length)),
- sub-address [1] NumericString
- (SIZE (1..ub-e163-4-sub-address-length)) OPTIONAL},
- psap-address [0] PresentationAddress }
-
-PresentationAddress ::= SEQUENCE {
- pSelector [0] EXPLICIT OCTET STRING OPTIONAL,
- sSelector [1] EXPLICIT OCTET STRING OPTIONAL,
- tSelector [2] EXPLICIT OCTET STRING OPTIONAL,
- nAddresses [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING}
-
-
-terminal-type EXTENSION-ATTRIBUTE ::= {TerminalType IDENTIFIED BY 23}
-
-TerminalType ::= INTEGER {
- telex (3),
- teletex (4),
- g3-facsimile (5),
- g4-facsimile (6),
- ia5-terminal (7),
- videotex (8) } (0..ub-integer-options)
-
--- Extension Domain-defined Attributes
-
-teletex-domain-defined-attributes EXTENSION-ATTRIBUTE ::=
- {TeletexDomainDefinedAttributes IDENTIFIED BY 6}
-
-TeletexDomainDefinedAttributes ::= SEQUENCE SIZE
- (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute
-
-
-
-Housley, et. al. Standards Track [Page 105]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-TeletexDomainDefinedAttribute ::= SEQUENCE {
- type TeletexString
- (SIZE (1..ub-domain-defined-attribute-type-length)),
- value TeletexString
- (SIZE (1..ub-domain-defined-attribute-value-length)) }
-
--- specifications of Upper Bounds
--- shall be regarded as mandatory
--- from Annex B of ITU-T X.411
--- Reference Definition of MTS Parameter Upper Bounds
-
--- Upper Bounds
-ub-name INTEGER ::= 32768
-ub-common-name INTEGER ::= 64
-ub-locality-name INTEGER ::= 128
-ub-state-name INTEGER ::= 128
-ub-organization-name INTEGER ::= 64
-ub-organizational-unit-name INTEGER ::= 64
-ub-title INTEGER ::= 64
-ub-match INTEGER ::= 128
-
-ub-emailaddress-length INTEGER ::= 128
-
-ub-common-name-length INTEGER ::= 64
-ub-country-name-alpha-length INTEGER ::= 2
-ub-country-name-numeric-length INTEGER ::= 3
-ub-domain-defined-attributes INTEGER ::= 4
-ub-domain-defined-attribute-type-length INTEGER ::= 8
-ub-domain-defined-attribute-value-length INTEGER ::= 128
-ub-domain-name-length INTEGER ::= 16
-ub-extension-attributes INTEGER ::= 256
-ub-e163-4-number-length INTEGER ::= 15
-ub-e163-4-sub-address-length INTEGER ::= 40
-ub-generation-qualifier-length INTEGER ::= 3
-ub-given-name-length INTEGER ::= 16
-ub-initials-length INTEGER ::= 5
-ub-integer-options INTEGER ::= 256
-ub-numeric-user-id-length INTEGER ::= 32
-ub-organization-name-length INTEGER ::= 64
-ub-organizational-unit-name-length INTEGER ::= 32
-ub-organizational-units INTEGER ::= 4
-ub-pds-name-length INTEGER ::= 16
-ub-pds-parameter-length INTEGER ::= 30
-ub-pds-physical-address-lines INTEGER ::= 6
-ub-postal-code-length INTEGER ::= 16
-ub-surname-length INTEGER ::= 40
-ub-terminal-id-length INTEGER ::= 24
-ub-unformatted-address-length INTEGER ::= 180
-
-
-
-Housley, et. al. Standards Track [Page 106]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-ub-x121-address-length INTEGER ::= 16
-
--- Note - upper bounds on TeletexString are measured in characters.
--- A significantly greater number of octets will be required to hold
--- such a value. As a minimum, 16 octets, or twice the specified upper
--- bound, whichever is the larger, should be allowed.
-
-END
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Housley, et. al. Standards Track [Page 107]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-B.2 Implicitly Tagged Module, 1993 Syntax
-
-
-PKIX1Implicit93 {iso(1) identified-organization(3) dod(6) internet(1)
- security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-93(4)}
-
-DEFINITIONS IMPLICIT TAGS::=
-
-BEGIN
-
---EXPORTS ALL --
-
-IMPORTS
- id-pe, id-qt, id-kp, id-ad, id-qt-unotice,
- ORAddress, Name, RelativeDistinguishedName,
- CertificateSerialNumber, CertificateList,
- AlgorithmIdentifier, ub-name, DirectoryString,
- Attribute, EXTENSION
- FROM PKIX1Explicit93 {iso(1) identified-organization(3)
- dod(6) internet(1) security(5) mechanisms(5) pkix(7)
- id-mod(0) id-pkix1-explicit-93(3)};
-
--- Key and policy information extensions --
-
-authorityKeyIdentifier EXTENSION ::= {
- SYNTAX AuthorityKeyIdentifier
- IDENTIFIED BY id-ce-authorityKeyIdentifier }
-
-AuthorityKeyIdentifier ::= SEQUENCE {
- keyIdentifier [0] KeyIdentifier OPTIONAL,
- authorityCertIssuer [1] GeneralNames OPTIONAL,
- authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }
- ( WITH COMPONENTS {..., authorityCertIssuer PRESENT,
- authorityCertSerialNumber PRESENT} |
- WITH COMPONENTS {..., authorityCertIssuer ABSENT,
- authorityCertSerialNumber ABSENT} )
-
-KeyIdentifier ::= OCTET STRING
-
-subjectKeyIdentifier EXTENSION ::= {
- SYNTAX SubjectKeyIdentifier
- IDENTIFIED BY id-ce-subjectKeyIdentifier }
-
-SubjectKeyIdentifier ::= KeyIdentifier
-
-keyUsage EXTENSION ::= {
- SYNTAX KeyUsage
- IDENTIFIED BY id-ce-keyUsage }
-
-
-
-Housley, et. al. Standards Track [Page 108]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-KeyUsage ::= BIT STRING {
- digitalSignature (0),
- nonRepudiation (1),
- keyEncipherment (2),
- dataEncipherment (3),
- keyAgreement (4),
- keyCertSign (5),
- cRLSign (6),
- encipherOnly (7),
- decipherOnly (8) }
-
-extendedKeyUsage EXTENSION ::= {
- SYNTAX SEQUENCE SIZE (1..MAX) OF KeyPurposeId
- IDENTIFIED BY id-ce-extKeyUsage }
-
-KeyPurposeId ::= OBJECT IDENTIFIER
-
--- PKIX-defined extended key purpose OIDs
-id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
-id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 }
-id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 }
-id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 }
-id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 }
-id-kp-ipsecTunnel OBJECT IDENTIFIER ::= { id-kp 6 }
-id-kp-ipsecUser OBJECT IDENTIFIER ::= { id-kp 7 }
-id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }
-
-privateKeyUsagePeriod EXTENSION ::= {
- SYNTAX PrivateKeyUsagePeriod
- IDENTIFIED BY { id-ce-privateKeyUsagePeriod } }
-
-PrivateKeyUsagePeriod ::= SEQUENCE {
- notBefore [0] GeneralizedTime OPTIONAL,
- notAfter [1] GeneralizedTime OPTIONAL }
- ( WITH COMPONENTS {..., notBefore PRESENT} |
- WITH COMPONENTS {..., notAfter PRESENT} )
-
-certificatePolicies EXTENSION ::= {
- SYNTAX CertificatePoliciesSyntax
- IDENTIFIED BY id-ce-certificatePolicies }
-
-CertificatePoliciesSyntax ::=
- SEQUENCE SIZE (1..MAX) OF PolicyInformation
-
-PolicyInformation ::= SEQUENCE {
- policyIdentifier CertPolicyId,
- policyQualifiers SEQUENCE SIZE (1..MAX) OF
- PolicyQualifierInfo OPTIONAL }
-
-
-
-Housley, et. al. Standards Track [Page 109]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-CertPolicyId ::= OBJECT IDENTIFIER
-
-PolicyQualifierInfo ::= SEQUENCE {
- policyQualifierId CERT-POLICY-QUALIFIER.&id
- ({SupportedPolicyQualifiers}),
- qualifier CERT-POLICY-QUALIFIER.&Qualifier
- ({SupportedPolicyQualifiers}
- {@policyQualifierId})OPTIONAL }
-
-SupportedPolicyQualifiers CERT-POLICY-QUALIFIER ::= { noticeToUser |
- pointerToCPS }
-
-CERT-POLICY-QUALIFIER ::= CLASS {
- &id OBJECT IDENTIFIER UNIQUE,
- &Qualifier OPTIONAL }
-WITH SYNTAX {
- POLICY-QUALIFIER-ID &id
- [QUALIFIER-TYPE &Qualifier] }
-
-policyMappings EXTENSION ::= {
- SYNTAX PolicyMappingsSyntax
- IDENTIFIED BY id-ce-policyMappings }
-
-PolicyMappingsSyntax ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
- issuerDomainPolicy CertPolicyId,
- subjectDomainPolicy CertPolicyId }
-
--- Certificate subject and certificate issuer attributes extensions --
-
-subjectAltName EXTENSION ::= {
- SYNTAX GeneralNames
- IDENTIFIED BY id-ce-subjectAltName }
-
-GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
-
-GeneralName ::= CHOICE {
- otherName [0] INSTANCE OF OTHER-NAME,
- rfc822Name [1] IA5String,
- dNSName [2] IA5String,
- x400Address [3] ORAddress,
- directoryName [4] Name,
- ediPartyName [5] EDIPartyName,
- uniformResourceIdentifier [6] IA5String,
- iPAddress [7] OCTET STRING,
- registeredID [8] OBJECT IDENTIFIER }
-
-OTHER-NAME ::= TYPE-IDENTIFIER
-
-
-
-
-Housley, et. al. Standards Track [Page 110]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-EDIPartyName ::= SEQUENCE {
- nameAssigner [0] DirectoryString {ub-name} OPTIONAL,
- partyName [1] DirectoryString {ub-name} }
-
-issuerAltName EXTENSION ::= {
- SYNTAX GeneralNames
- IDENTIFIED BY id-ce-issuerAltName }
-
-subjectDirectoryAttributes EXTENSION ::= {
- SYNTAX AttributesSyntax
- IDENTIFIED BY id-ce-subjectDirectoryAttributes }
-
-AttributesSyntax ::= SEQUENCE SIZE (1..MAX) OF Attribute
-
--- Certification path constraints extensions --
-
-basicConstraints EXTENSION ::= {
- SYNTAX BasicConstraintsSyntax
- IDENTIFIED BY id-ce-basicConstraints }
-
-BasicConstraintsSyntax ::= SEQUENCE {
- cA BOOLEAN DEFAULT FALSE,
- pathLenConstraint INTEGER (0..MAX) OPTIONAL }
-
-nameConstraints EXTENSION ::= {
- SYNTAX NameConstraintsSyntax
- IDENTIFIED BY id-ce-nameConstraints }
-
-NameConstraintsSyntax ::= SEQUENCE {
- permittedSubtrees [0] GeneralSubtrees OPTIONAL,
- excludedSubtrees [1] GeneralSubtrees OPTIONAL }
-
-GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
-
-GeneralSubtree ::= SEQUENCE {
- base GeneralName,
- minimum [0] BaseDistance DEFAULT 0,
- maximum [1] BaseDistance OPTIONAL }
-
-BaseDistance ::= INTEGER (0..MAX)
-
-policyConstraints EXTENSION ::= {
- SYNTAX PolicyConstraintsSyntax
- IDENTIFIED BY id-ce-policyConstraints }
-
-PolicyConstraintsSyntax ::= SEQUENCE {
- requireExplicitPolicy [0] SkipCerts OPTIONAL,
- inhibitPolicyMapping [1] SkipCerts OPTIONAL }
-
-
-
-Housley, et. al. Standards Track [Page 111]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-SkipCerts ::= INTEGER (0..MAX)
-
--- Basic CRL extensions --
-
-cRLNumber EXTENSION ::= {
- SYNTAX CRLNumber
- IDENTIFIED BY id-ce-cRLNumber }
-
-CRLNumber ::= INTEGER (0..MAX)
-
-reasonCode EXTENSION ::= {
- SYNTAX CRLReason
- IDENTIFIED BY id-ce-reasonCode }
-
-CRLReason ::= ENUMERATED {
- unspecified (0),
- keyCompromise (1),
- cACompromise (2),
- affiliationChanged (3),
- superseded (4),
- cessationOfOperation (5),
- certificateHold (6),
- removeFromCRL (8) }
-
-instructionCode EXTENSION ::= {
- SYNTAX HoldInstruction
- IDENTIFIED BY id-ce-instructionCode }
-
-HoldInstruction ::= OBJECT IDENTIFIER
-
--- holdinstructions described in this specification, from ANSI x9
-
--- ANSI x9 arc holdinstruction arc
-holdInstruction OBJECT IDENTIFIER ::= {
- joint-iso-ccitt(2) member-body(2) us(840) x9cm(10040) 2}
-
--- ANSI X9 holdinstructions referenced by this standard
-id-holdinstruction-none OBJECT IDENTIFIER ::= {holdInstruction 1}
-id-holdinstruction-callissuer OBJECT IDENTIFIER ::= {holdInstruction 2}
-id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3}
-
-invalidityDate EXTENSION ::= {
- SYNTAX GeneralizedTime
- IDENTIFIED BY id-ce-invalidityDate }
-
--- CRL distribution points and delta-CRL extensions --
-
-cRLDistributionPoints EXTENSION ::= {
-
-
-
-Housley, et. al. Standards Track [Page 112]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- SYNTAX CRLDistPointsSyntax
- IDENTIFIED BY id-ce-cRLDistributionPoints }
-
-CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
-
-DistributionPoint ::= SEQUENCE {
- distributionPoint [0] DistributionPointName OPTIONAL,
- reasons [1] ReasonFlags OPTIONAL,
- cRLIssuer [2] GeneralNames OPTIONAL }
-
-DistributionPointName ::= CHOICE {
- fullName [0] GeneralNames,
- nameRelativeToCRLIssuer [1] RelativeDistinguishedName }
-
-ReasonFlags ::= BIT STRING {
- unused (0),
- keyCompromise (1),
- caCompromise (2),
- affiliationChanged (3),
- superseded (4),
- cessationOfOperation (5),
- certificateHold (6) }
-
-issuingDistributionPoint EXTENSION ::= {
- SYNTAX IssuingDistPointSyntax
- IDENTIFIED BY id-ce-issuingDistributionPoint }
-
-IssuingDistPointSyntax ::= SEQUENCE {
- distributionPoint [0] DistributionPointName OPTIONAL,
- onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE,
- onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE,
- onlySomeReasons [3] ReasonFlags OPTIONAL,
- indirectCRL [4] BOOLEAN DEFAULT FALSE }
-
-certificateIssuer EXTENSION ::= {
- SYNTAX GeneralNames
- IDENTIFIED BY id-ce-certificateIssuer }
-
-deltaCRLIndicator EXTENSION ::= {
- SYNTAX BaseCRLNumber
- IDENTIFIED BY id-ce-deltaCRLIndicator }
-
-BaseCRLNumber ::= CRLNumber
-
--- Object identifier assignments for ISO certificate extensions --
-id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29}
-
-id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= {id-ce 9}
-
-
-
-Housley, et. al. Standards Track [Page 113]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= {id-ce 14}
-id-ce-keyUsage OBJECT IDENTIFIER ::= {id-ce 15}
-id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= {id-ce 16}
-id-ce-subjectAltName OBJECT IDENTIFIER ::= {id-ce 17}
-id-ce-issuerAltName OBJECT IDENTIFIER ::= {id-ce 18}
-id-ce-basicConstraints OBJECT IDENTIFIER ::= {id-ce 19}
-id-ce-cRLNumber OBJECT IDENTIFIER ::= {id-ce 20}
-id-ce-reasonCode OBJECT IDENTIFIER ::= {id-ce 21}
-id-ce-instructionCode OBJECT IDENTIFIER ::= {id-ce 23}
-id-ce-invalidityDate OBJECT IDENTIFIER ::= {id-ce 24}
-id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= {id-ce 27}
-id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= {id-ce 28}
-id-ce-certificateIssuer OBJECT IDENTIFIER ::= {id-ce 29}
-id-ce-nameConstraints OBJECT IDENTIFIER ::= {id-ce 30}
-id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31}
-id-ce-certificatePolicies OBJECT IDENTIFIER ::= {id-ce 32}
-id-ce-policyMappings OBJECT IDENTIFIER ::= {id-ce 33}
-id-ce-policyConstraints OBJECT IDENTIFIER ::= {id-ce 36}
-id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= {id-ce 35}
-id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37}
-
--- PKIX 1 extensions
-
-authorityInfoAccess EXTENSION ::= {
- SYNTAX AuthorityInfoAccessSyntax
- IDENTIFIED BY id-pe-authorityInfoAccess }
-
-AuthorityInfoAccessSyntax ::=
- SEQUENCE SIZE (1..MAX) OF AccessDescription
-
-AccessDescription ::= SEQUENCE {
- accessMethod OBJECT IDENTIFIER,
- accessLocation GeneralName }
-
-id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }
-
-id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }
-id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }
-
--- PKIX policy qualifier definitions
-
-noticeToUser CERT-POLICY-QUALIFIER ::= {
- POLICY-QUALIFIER-ID id-qt-cps QUALIFIER-TYPE CPSuri}
-
-pointerToCPS CERT-POLICY-QUALIFIER ::= {
- POLICY-QUALIFIER-ID id-qt-unotice QUALIFIER-TYPE UserNotice}
-
-id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 }
-
-
-
-Housley, et. al. Standards Track [Page 114]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 }
-
-CPSuri ::= IA5String
-
-UserNotice ::= SEQUENCE {
- noticeRef NoticeReference OPTIONAL,
- explicitText DisplayText OPTIONAL}
-
-NoticeReference ::= SEQUENCE {
- organization DisplayText,
- noticeNumbers SEQUENCE OF INTEGER }
-
-DisplayText ::= CHOICE {
- visibleString VisibleString (SIZE (1..200)),
- bmpString BMPString (SIZE (1..200)),
- utf8String UTF8String (SIZE (1..200)) }
-
-
-END
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Housley, et. al. Standards Track [Page 115]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-Appendix C. ASN.1 Notes
-
- The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1
- constructs. A valid ASN.1 sequence will have zero or more entries.
- The SIZE (1..MAX) construct constrains the sequence to have at least
- one entry. MAX indicates the upper bound is unspecified.
- Implementations are free to choose an upper bound that suits their
- environment.
-
- The construct "positiveInt ::= INTEGER (0..MAX)" defines positiveInt
- as a subtype of INTEGER containing integers greater than or equal to
- zero. The upper bound is unspecified. Implementations are free to
- select an upper bound that suits their environment.
-
- The character string type PrintableString supports a very basic Latin
- character set: the lower case letters 'a' through 'z', upper case
- letters 'A' through 'Z', the digits '0' through '9', eleven special
- characters ' " ( ) + , - . / : ? and space.
-
- The character string type TeletexString is a superset of
- PrintableString. TeletexString supports a fairly standard (ascii-
- like) Latin character set, Latin characters with non-spacing accents
- and Japanese characters.
-
- The character string type UniversalString supports any of the
- characters allowed by ISO 10646-1. ISO 10646 is the Universal
- multiple-octet coded Character Set (UCS). ISO 10646-1 specifes the
- architecture and the "basic multilingual plane" - a large standard
- character set which includes all major world character standards.
-
- The character string type UTF8String will be introduced in the 1998
- version of ASN.1. UTF8String is a universal type and has been
- assigned tag number 12. The content of UTF8String was defined by RFC
- 2044 and updated in RFC 2279, "UTF-8, a transformation Format of ISP
- 10646." ISO is expected to formally add UTF8String to the list of
- choices for DirectoryString in 1998 as well.
-
- In anticipation of these changes, and in conformance with IETF Best
- Practices codified in RFC 2277, IETF Policy on Character Sets and
- Languages, this document includes UTF8String as a choice in
- DirectoryString and the CPS qualifier extensions.
-
-
-
-
-
-
-
-
-
-
-Housley, et. al. Standards Track [Page 116]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-Appendix D. Examples
-
- This section contains four examples: three certificates and a CRL.
- The first two certificates and the CRL comprise a minimal
- certification path.
-
- Section D.1 contains an annotated hex dump of a "self-signed"
- certificate issued by a CA whose distinguished name is
- cn=us,o=gov,ou=nist. The certificate contains a DSA public key with
- parameters, and is signed by the corresponding DSA private key.
-
- Section D.2 contains an annotated hex dump of an end-entity
- certificate. The end entity certificate contains a DSA public key,
- and is signed by the private key corresponding to the "self-signed"
- certificate in section D.1.
-
- Section D.3 contains a dump of an end entity certificate which
- contains an RSA public key and is signed with RSA and MD5. This
- certificate is not part of the minimal certification path.
-
- Section D.4 contains an annotated hex dump of a CRL. The CRL is
- issued by the CA whose distinguished name is cn=us,o=gov,ou=nist and
- the list of revoked certificates includes the end entity certificate
- presented in D.2.
-
-D.1 Certificate
-
- This section contains an annotated hex dump of a 699 byte version 3
- certificate. The certificate contains the following information:
- (a) the serial number is 17 (11 hex);
- (b) the certificate is signed with DSA and the SHA-1 hash algorithm;
- (c) the issuer's distinguished name is OU=nist; O=gov; C=US
- (d) and the subject's distinguished name is OU=nist; O=gov; C=US
- (e) the certificate was issued on June 30, 1997 and will expire on
- December 31, 1997;
- (f) the certificate contains a 1024 bit DSA public key with
- parameters;
- (g) the certificate contains a subject key identifier extension; and
- (h) the certificate is a CA certificate (as indicated through the
- basic constraints extension.)
-
-0000 30 82 02 b7 695: SEQUENCE
-0004 30 82 02 77 631: . SEQUENCE tbscertificate
-0008 a0 03 3: . . [0]
-0010 02 01 1: . . . INTEGER 2
- : 02
-0013 02 01 1: . . INTEGER 17
- : 11
-
-
-
-Housley, et. al. Standards Track [Page 117]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-0016 30 09 9: . . SEQUENCE
-0018 06 07 7: . . . OID 1.2.840.10040.4.3: dsa-with-sha
- : 2a 86 48 ce 38 04 03
-0027 30 2a 42: . . SEQUENCE
-0029 31 0b 11: . . . SET
-0031 30 09 9: . . . . SEQUENCE
-0033 06 03 3: . . . . . OID 2.5.4.6: C
- : 55 04 06
-0038 13 02 2: . . . . . PrintableString 'US'
- : 55 53
-0042 31 0c 12: . . . SET
-0044 30 0a 10: . . . . SEQUENCE
-0046 06 03 3: . . . . . OID 2.5.4.10: O
- : 55 04 0a
-0051 13 03 3: . . . . . PrintableString 'gov'
- : 67 6f 76
-0056 31 0d 13: . . . SET
-0058 30 0b 11: . . . . SEQUENCE
-0060 06 03 3: . . . . . OID 2.5.4.11: OU
- : 55 04 0b
-0065 13 04 4: . . . . . PrintableString 'nist'
- : 6e 69 73 74
-0071 30 1e 30: . . SEQUENCE
-0073 17 0d 13: . . . UTCTime '970630000000Z'
- : 39 37 30 36 33 30 30 30 30 30 30 30 5a
-0088 17 0d 13: . . . UTCTime '971231000000Z'
- : 39 37 31 32 33 31 30 30 30 30 30 30 5a
-0103 30 2a 42: . . SEQUENCE
-0105 31 0b 11: . . . SET
-0107 30 09 9: . . . . SEQUENCE
-0109 06 03 3: . . . . . OID 2.5.4.6: C
- : 55 04 06
-0114 13 02 2: . . . . . PrintableString 'US'
- : 55 53
-0118 31 0c 12: . . . SET
-0120 30 0a 10: . . . . SEQUENCE
-0122 06 03 3: . . . . . OID 2.5.4.10: O
- : 55 04 0a
-0127 13 03 3: . . . . . PrintableString 'gov'
- : 67 6f 76
-0132 31 0d 13: . . . SET
-0134 30 0b 11: . . . . SEQUENCE
-0136 06 03 3: . . . . . OID 2.5.4.11: OU
- : 55 04 0b
-0141 13 04 4: . . . . . PrintableString 'nist'
- : 6e 69 73 74
-0147 30 82 01 b4 436: . . SEQUENCE
-0151 30 82 01 29 297: . . . SEQUENCE
-
-
-
-Housley, et. al. Standards Track [Page 118]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-0155 06 07 7: . . . . OID 1.2.840.10040.4.1: dsa
- : 2a 86 48 ce 38 04 01
-0164 30 82 01 1c 284: . . . . SEQUENCE
-0168 02 81 80 128: . . . . . INTEGER
- : d4 38 02 c5 35 7b d5 0b a1 7e 5d 72 59 63 55 d3
- : 45 56 ea e2 25 1a 6b c5 a4 ab aa 0b d4 62 b4 d2
- : 21 b1 95 a2 c6 01 c9 c3 fa 01 6f 79 86 83 3d 03
- : 61 e1 f1 92 ac bc 03 4e 89 a3 c9 53 4a f7 e2 a6
- : 48 cf 42 1e 21 b1 5c 2b 3a 7f ba be 6b 5a f7 0a
- : 26 d8 8e 1b eb ec bf 1e 5a 3f 45 c0 bd 31 23 be
- : 69 71 a7 c2 90 fe a5 d6 80 b5 24 dc 44 9c eb 4d
- : f9 da f0 c8 e8 a2 4c 99 07 5c 8e 35 2b 7d 57 8d
-0299 02 14 20: . . . . . INTEGER
- : a7 83 9b f3 bd 2c 20 07 fc 4c e7 e8 9f f3 39 83
- : 51 0d dc dd
-0321 02 81 80 128: . . . . . INTEGER
- : 0e 3b 46 31 8a 0a 58 86 40 84 e3 a1 22 0d 88 ca
- : 90 88 57 64 9f 01 21 e0 15 05 94 24 82 e2 10 90
- : d9 e1 4e 10 5c e7 54 6b d4 0c 2b 1b 59 0a a0 b5
- : a1 7d b5 07 e3 65 7c ea 90 d8 8e 30 42 e4 85 bb
- : ac fa 4e 76 4b 78 0e df 6c e5 a6 e1 bd 59 77 7d
- : a6 97 59 c5 29 a7 b3 3f 95 3e 9d f1 59 2d f7 42
- : 87 62 3f f1 b8 6f c7 3d 4b b8 8d 74 c4 ca 44 90
- : cf 67 db de 14 60 97 4a d1 f7 6d 9e 09 94 c4 0d
-0452 03 81 84 132: . . . BIT STRING (0 unused bits)
- : 02 81 80 aa 98 ea 13 94 a2 db f1 5b 7f 98 2f 78
- : e7 d8 e3 b9 71 86 f6 80 2f 40 39 c3 da 3b 4b 13
- : 46 26 ee 0d 56 c5 a3 3a 39 b7 7d 33 c2 6b 5c 77
- : 92 f2 55 65 90 39 cd 1a 3c 86 e1 32 eb 25 bc 91
- : c4 ff 80 4f 36 61 bd cc e2 61 04 e0 7e 60 13 ca
- : c0 9c dd e0 ea 41 de 33 c1 f1 44 a9 bc 71 de cf
- : 59 d4 6e da 44 99 3c 21 64 e4 78 54 9d d0 7b ba
- : 4e f5 18 4d 5e 39 30 bf e0 d1 f6 f4 83 25 4f 14
- : aa 71 e1
-0587 a3 32 50: . . [3]
-0589 30 30 48: . . . SEQUENCE
-0591 30 0f 9: . . . . SEQUENCE
-0593 06 03 3: . . . . . OID 2.5.29.19: basicConstraints
- : 55 1d 13
-0598 01 01 1: . . . . . TRUE
- : ff
-0601 04 05 5: . . . . . OCTET STRING
- : 30 03 01 01 ff
-0608 30 1d 29: . SEQUENCE
-0610 06 03 3: . . . . . OID 2.5.29.14: subjectKeyIdentifier
- : 55 1d 0e
-0615 04 16 22: . . . . . OCTET STRING
- : 04 14 e7 26 c5 54 cd 5b a3 6f 35 68 95 aa d5 ff
-
-
-
-Housley, et. al. Standards Track [Page 119]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- : 1c 21 e4 22 75 d6
-0639 30 09 9: . SEQUENCE
-0641 06 07 7: . . OID 1.2.840.10040.4.3: dsa-with-sha
- : 2a 86 48 ce 38 04 03
-0650 03 2f 47: . BIT STRING (0 unused bits)
- : 30 2c 02 14 a0 66 c1 76 33 99 13 51 8d 93 64 2f
- : ca 13 73 de 79 1a 7d 33 02 14 5d 90 f6 ce 92 4a
- : bf 29 11 24 80 28 a6 5a 8e 73 b6 76 02 68
-
-D.2 Certificate
-
- This section contains an annotated hex dump of a 730 byte version 3
- certificate. The certificate contains the following information:
- (a) the serial number is 18 (12 hex);
- (b) the certificate is signed with DSA and the SHA-1 hash algorithm;
- (c) the issuer's distinguished name is OU=nist; O=gov; C=US
- (d) and the subject's distinguished name is CN=Tim Polk; OU=nist;
- O=gov; C=US
- (e) the certificate was valid from July 30, 1997 through December 1,
- 1997;
- (f) the certificate contains a 1024 bit DSA public key;
- (g) the certificate is an end entity certificate, as the basic
- constraints extension is not present;
- (h) the certificate contains an authority key identifier extension;
- and
- (i) the certificate includes one alternative name - an RFC 822
- address.
-
-0000 30 82 02 d6 726: SEQUENCE
-0004 30 82 02 96 662: . SEQUENCE
-0008 a0 03 3: . . [0]
-0010 02 01 1: . . . INTEGER 2
- : 02
-0013 02 01 1: . . INTEGER 18
- : 12
-0016 30 09 9: . . SEQUENCE
-0018 06 07 7: . . . OID 1.2.840.10040.4.3: dsa-with-sha
- : 2a 86 48 ce 38 04 03
-0027 30 2a 42: . . SEQUENCE
-0029 31 0b 11: . . . SET
-0031 30 09 9: . . . . SEQUENCE
-0033 06 03 3: . . . . . OID 2.5.4.6: C
- : 55 04 06
-0038 13 02 2: . . . . . PrintableString 'US'
- : 55 53
-0042 31 0c 12: . . . SET
-0044 30 0a 10: . . . . SEQUENCE
-0046 06 03 3: . . . . . OID 2.5.4.10: O
-
-
-
-Housley, et. al. Standards Track [Page 120]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- : 55 04 0a
-0051 13 03 3: . . . . . PrintableString 'gov'
- : 67 6f 76
-0056 31 0d 13: . . . SET
-0058 30 0b 11: . . . . SEQUENCE
-0060 06 03 3: . . . . . OID 2.5.4.11: OU
- : 55 04 0b
-0065 13 04 4: . . . . . PrintableString 'nist'
- : 6e 69 73 74
-0071 30 1e 30: . . SEQUENCE
-0073 17 0d 13: . . . UTCTime '970730000000Z'
- : 39 37 30 37 33 30 30 30 30 30 30 30 5a
-0088 17 0d 13: . . . UTCTime '971201000000Z'
- : 39 37 31 32 30 31 30 30 30 30 30 30 5a
-0103 30 3d 61: . . SEQUENCE
-0105 31 0b 11: . . . SET
-0107 30 09 9: . . . . SEQUENCE
-0109 06 03 3: . . . . . OID 2.5.4.6: C
- : 55 04 06
-0114 13 02 2: . . . . . PrintableString 'US'
- : 55 53
-0118 31 0c 12: . . . SET
-0120 30 0a 10: . . . . SEQUENCE
-0122 06 03 3: . . . . . OID 2.5.4.10: O
- : 55 04 0a
-0127 13 03 3: . . . . . PrintableString 'gov'
- : 67 6f 76
-0132 31 0d 13: . . . SET
-0134 30 0b 11: . . . . SEQUENCE
-0136 06 03 3: . . . . . OID 2.5.4.11: OU
- : 55 04 0b
-0141 13 04 4: . . . . . PrintableString 'nist'
- : 6e 69 73 74
-0147 31 11 17: . . . SET
-0149 30 0f 15: . . . . SEQUENCE
-0151 06 03 3: . . . . . OID 2.5.4.3: CN
- : 55 04 03
-0156 13 08 8: . . . . . PrintableString 'Tim Polk'
- : 54 69 6d 20 50 6f 6c 6b
-0166 30 82 01 b4 436: . . SEQUENCE
-0170 30 82 01 29 297: . . . SEQUENCE
-0174 06 07 7: . . . . OID 1.2.840.10040.4.1: dsa
- : 2a 86 48 ce 38 04 01
-0183 30 82 01 1c 284: . . . . SEQUENCE
-0187 02 81 80 128: . . . . . INTEGER
- : d4 38 02 c5 35 7b d5 0b a1 7e 5d 72 59 63 55 d3
- : 45 56 ea e2 25 1a 6b c5 a4 ab aa 0b d4 62 b4 d2
- : 21 b1 95 a2 c6 01 c9 c3 fa 01 6f 79 86 83 3d 03
-
-
-
-Housley, et. al. Standards Track [Page 121]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- : 61 e1 f1 92 ac bc 03 4e 89 a3 c9 53 4a f7 e2 a6
- : 48 cf 42 1e 21 b1 5c 2b 3a 7f ba be 6b 5a f7 0a
- : 26 d8 8e 1b eb ec bf 1e 5a 3f 45 c0 bd 31 23 be
- : 69 71 a7 c2 90 fe a5 d6 80 b5 24 dc 44 9c eb 4d
- : f9 da f0 c8 e8 a2 4c 99 07 5c 8e 35 2b 7d 57 8d
-0318 02 14 20: . . . . . INTEGER
- : a7 83 9b f3 bd 2c 20 07 fc 4c e7 e8 9f f3 39 83
- : 51 0d dc dd
-0340 02 81 80 128: . . . . . INTEGER
- : 0e 3b 46 31 8a 0a 58 86 40 84 e3 a1 22 0d 88 ca
- : 90 88 57 64 9f 01 21 e0 15 05 94 24 82 e2 10 90
- : d9 e1 4e 10 5c e7 54 6b d4 0c 2b 1b 59 0a a0 b5
- : a1 7d b5 07 e3 65 7c ea 90 d8 8e 30 42 e4 85 bb
- : ac fa 4e 76 4b 78 0e df 6c e5 a6 e1 bd 59 77 7d
- : a6 97 59 c5 29 a7 b3 3f 95 3e 9d f1 59 2d f7 42
- : 87 62 3f f1 b8 6f c7 3d 4b b8 8d 74 c4 ca 44 90
- : cf 67 db de 14 60 97 4a d1 f7 6d 9e 09 94 c4 0d
-0471 03 81 84 132: . . . BIT STRING (0 unused bits)
- : 02 81 80 a8 63 b1 60 70 94 7e 0b 86 08 93 0c 0d
- : 08 12 4a 58 a9 af 9a 09 38 54 3b 46 82 fb 85 0d
- : 18 8b 2a 77 f7 58 e8 f0 1d d2 18 df fe e7 e9 35
- : c8 a6 1a db 8d 3d 3d f8 73 14 a9 0b 39 c7 95 f6
- : 52 7d 2d 13 8c ae 03 29 3c 4e 8c b0 26 18 b6 d8
- : 11 1f d4 12 0c 13 ce 3f f1 c7 05 4e df e1 fc 44
- : fd 25 34 19 4a 81 0d dd 98 42 ac d3 b6 91 0c 7f
- : 16 72 a3 a0 8a d7 01 7f fb 9c 93 e8 99 92 c8 42
- : 47 c6 43
-0606 a3 3e 62: . . [3]
-0608 30 3c 60: . . . SEQUENCE
-0610 30 19 25: . . . . SEQUENCE
-0612 06 03 3: . . . . . OID 2.5.29.17: subjectAltName
- : 55 1d 11
-0617 04 12 18: . . . . . OCTET STRING
- : 30 10 81 0e 77 70 6f 6c 6b 40 6e 69 73 74 2e 67
- : 6f 76
-0637 30 1f 31: . . . . SEQUENCE
-0639 06 03 3: . . . . . OID 2.5.29.35: subjectAltName
- : 55 1d 23
-0644 04 18 24: . . . . . OCTET STRING
- : 30 16 80 14 e7 26 c5 54 cd 5b a3 6f 35 68 95 aa
- : d5 ff 1c 21 e4 22 75 d6
-0670 30 09 9: . SEQUENCE
-0672 06 07 7: . . OID 1.2.840.10040.4.3: dsa-with-sha
- : 2a 86 48 ce 38 04 03
-0681 03 2f 47: . BIT STRING (0 unused bits)
- : 30 2c 02 14 3c 02 e0 ab d9 5d 05 77 75 15 71 58
- : 92 29 48 c4 1c 54 df fc 02 14 5b da 53 98 7f c5
- : 33 df c6 09 b2 7a e3 6f 97 70 1e 14 ed 94
-
-
-
-Housley, et. al. Standards Track [Page 122]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-D.3 End-Entity Certificate Using RSA
-
- This section contains an annotated hex dump of a 675 byte version 3
- certificate. The certificate contains the following information:
- (a) the serial number is 256;
- (b) the certificate is signed with RSA and the MD2 hash algorithm;
- (c) the issuer's distinguished name is OU=Dept. Arquitectura de
- Computadors; O=Universitat Politecnica de Catalunya; C=ES
- (d) and the subject's distinguished name is CN=Francisco Jordan;
- OU=Dept. Arquitectura de Computadors; O=Universitat Politecnica de
- Catalunya; C=ES
- (e) the certificate was issued on May 21, 1996 and expired on May 21,
- 1997;
- (f) the certificate contains a 768 bit RSA public key;
- (g) the certificate is an end entity certificate (not a CA
- certificate);
- (h) the certificate includes an alternative subject name and an
- alternative issuer name - bothe are URLs;
- (i) the certificate include an authority key identifier and
- certificate policies extensions; and
- (j) the certificate includes a critical key usage extension
- specifying the public is intended for generation of digital
- signatures.
-
-0000 30 80 : SEQUENCE (size undefined)
-0002 30 82 02 40 576: . SEQUENCE
-0006 a0 03 3: . . [0]
-0008 02 01 1: . . . INTEGER 2
- : 02
-0011 02 02 2: . . INTEGER 256
- : 01 00
-0015 30 0d 13: . . SEQUENCE
-0017 06 09 9: . . . OID 1.2.840.113549.1.1.2:
- MD2WithRSAEncryption
- : 2a 86 48 86 f7 0d 01 01 02
-0028 05 00 0: . . . NULL
-0030 30 68 88: . . SEQUENCE
-0032 31 0b 11: . . . SET
-0034 30 09 9: . . . . SEQUENCE
-0036 06 03 3: . . . . . OID 2.5.4.6: C
- : 55 04 06
-0041 13 02 2: . . . . . PrintableString 'ES'
- : 45 53
-0045 31 2d 45: . . . SET
-0047 30 2b 43: . . . . SEQUENCE
-0049 06 03 3: . . . . . OID 2.5.4.10: O
- : 55 04 0a
-0054 13 24 36: . . . . . PrintableString
-
-
-
-Housley, et. al. Standards Track [Page 123]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- 'Universitat Politecnica de Catalunya'
- : 55 6e 69 76 65 72 73 69 74 61 74 20 50 6f 6c 69
- : 74 65 63 6e 69 63 61 20 64 65 20 43 61 74 61 6c
- : 75 6e 79 61
-0092 31 2a 42: . . . SET
-0094 30 28 40: . . . . SEQUENCE
-0096 06 03 3: . . . . . OID 2.5.4.11: OU
- : 55 04 0b
-0101 13 21 33: . . . . . PrintableString
- 'OU=Dept. Arquitectura de Computadors'
- : 44 65 70 74 2e 20 41 72 71 75 69 74 65 63 74 75
- : 72 61 20 64 65 20 43 6f 6d 70 75 74 61 64 6f 72
- : 73
-0136 30 1e 30: . . SEQUENCE
-0138 17 0d 13: . . . UTCTime '960521095826Z'
- : 39 36 30 37 32 32 31 37 33 38 30 32 5a
-0153 17 0d 13: . . . UTCTime '979521095826Z'
- : 39 37 30 37 32 32 31 37 33 38 30 32 5a
-0168 30 81 83 112: . . SEQUENCE
-0171 31 0b 11: . . . SET
-0173 30 09 9: . . . . SEQUENCE
-0175 06 03 3: . . . . . OID 2.5.4.6: C
- : 55 04 06
-0180 13 02 2: . . . . . PrintableString 'ES'
- : 45 53
-0184 31 2d 12: . . . SET
-0186 30 2b 16: . . . . SEQUENCE
-0188 06 03 3: . . . . . OID 2.5.4.10: O
- : 55 04 0a
-0193 13 24 36: . . . . . PrintableString
- 'Universitat Politecnica de Catalunya'
- : 55 6e 69 76 65 72 73 69 74 61 74 20 50 6f 6c 69
- : 74 65 63 6e 69 63 61 20 64 65 20 43 61 74 61 6c
- : 75 6e 79 61
-0231 31 2a 42: . . . SET
-0233 30 28 40: . . . . SEQUENCE
-0235 06 03 3: . . . . . OID 2.5.4.11: OU
- : 55 04 0b
-0240 13 21 33: . . . . . PrintableString
- 'Dept. Arquitectura de Computadors'
- : 44 65 70 74 2e 20 41 72 71 75 69 74 65 63 74 75
- : 72 61 20 64 65 20 43 6f 6d 70 75 74 61 64 6f 72
- : 73
-0275 31 19 22: . . . SET
-0277 30 17 20: . . . . SEQUENCE
-0279 06 03 3: . . . . . OID 2.5.4.3: CN
- : 55 04 03
-0284 13 10 16: . . . . . PrintableString 'Francisco Jordan'
-
-
-
-Housley, et. al. Standards Track [Page 124]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
- : 46 72 61 6e 63 69 73 63 6f 20 4a 6f 72 64 61 6e
-0302 30 7c 2: . . SEQUENCE
-0304 30 0d 13: . . . SEQUENCE
-0306 06 09 9: . . . . OID 1.2.840.113549.1.1.1: RSAEncryption
- : 2a 86 48 86 f7 0d 01 01 01
-0317 05 00 0: . . . . NULL
-0319 03 6b 107: . . . BIT STRING
- : 00 (0 unused bits)
- : 30 68 02 61 00 be aa 8b 77 54 a3 af ca 77 9f 2f
- : b0 cf 43 88 ff a6 6d 79 55 5b 61 8c 68 ec 48 1e
- : 8a 86 38 a4 fe 19 b8 62 17 1d 9d 0f 47 2c ff 63
- : 8f 29 91 04 d1 52 bc 7f 67 b6 b2 8f 74 55 c1 33
- : 21 6c 8f ab 01 95 24 c8 b2 73 93 9d 22 61 50 a9
- : 35 fb 9d 57 50 32 ef 56 52 50 93 ab b1 88 94 78
- : 56 15 c6 1c 8b 02 03 01 00 01
-0428 a3 81 97 151: . . [3]
-0431 30 3c 60: . . . SEQUENCE
-0433 30 1f 31: . . . . SEQUENCE
-0435 06 03 3: . . . . . OID 2.5.29.35: authorityKeyIdentifier
- : 55 1d 23
-0440 04 14 22: . . . . . OCTET STRING
- : 30 12 80 10 0e 6b 3a bf 04 ea 04 c3 0e 6b 3a bf
- : 04 ea 04 c3
-0464 30 19 25: . . . . SEQUENCE
-0466 06 03 3: . . . . . OID 2.5.29.15: keyUsage
- : 55 1d 0f
-0471 01 01 1: . . . . . TRUE
-0474 04 04 4: . . . . . OCTET STRING
- : 03 02 07 80
-0480 30 19 25: . . . . SEQUENCE
-0482 06 03 3: . . . . . OID 2.5.29.32: certificatePolicies
- : 55 1d 20
-0487 04 21 33: . . . . . OCTET STRING
- : 30 1f 30 1d 06 04 2a 84 80 00 30 15 30 07 06 05
- : 2a 84 80 00 01 30 0a 06 05 2a 84 80 00 02 02 01
- : 0a
-0522 30 1c 28: . . . . SEQUENCE
-0524 06 03 3: . . . . . OID 2.5.29.17: subjectAltName
- : 55 1d 11
-0529 04 15 21: . . . . . OCTET STRING
- : 30 13 86 11 68 74 74 70 3a 2f 2f 61 63 2e 75 70
- : 63 2e 65 73 2f
-0552 30 19 25: . . . . SEQUENCE
-0554 06 03 3: . . . . . OID 2.5.29.18: issuerAltName
- : 55 1d 12
-0559 04 12 18: . . . . . OCTET STRING
- : 30 14 86 12 68 74 74 70 3a 2f 2f 77 77 77 2e 75
- : 70 63 2e 65
-
-
-
-Housley, et. al. Standards Track [Page 125]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-0579 30 80 : . SEQUENCE (indefinite length)
-0581 06 07 7: . . OID
-0583 05 00 0: . . NULL
-0585 00 00 0: . . end of contents marker
-0587 03 81 81 47: . BIT STRING
- : 00 (0 unused bits)
- : 5c 01 bd b5 41 88 87 7a 0e d3 0e 6b 3a bf 04 ea
- : 04 cb 5f 61 72 3c a3 bd 78 f5 66 17 fe 37 3a ab
- : eb 67 bf b7 da a8 38 f6 33 15 71 75 2f b9 8c 91
- : a0 e4 87 ba 4b 43 a0 22 8f d3 a9 86 43 89 e6 50
- : 5c 01 bd b5 41 88 87 7a 0e d3 0e 6b 3a bf 04 ea
- : 04 cb 5f 61 72 3c a3 bd 78 f5 66 17 fe 37 3a ab
- : eb 67 bf b7 da a8 38 f6 33 15 71 75 2f b9 8c 91
- : a0 e4 87 ba 4b 43 a0 22 8f d3 a9 86 43 89 e6 50
-0637 00 00 0: . . end of contents marker
-
-D.4 Certificate Revocation List
-
- This section contains an annotated hex dump of a version 2 CRL with
- one extension (cRLNumber). The CRL was issued by OU=nist;O=gov;C=us
- on July 7, 1996; the next scheduled issuance was August 7, 1996. The
- CRL includes one revoked certificates: serial number 18 (12 hex).
- The CRL itself is number 18, and it was signed with DSA and SHA-1.
-
-0000 30 81 ba 186: SEQUENCE
-0003 30 7c 124: . SEQUENCE
-0005 02 01 1: . . INTEGER 1
- : 01
-0008 30 09 9: . . SEQUENCE
-0010 06 07 7: . . . OID 1.2.840.10040.4.3: dsa-with-sha
- : 2a 86 48 ce 38 04 03
-0019 30 2a 42: . . SEQUENCE
-0021 31 0b 11: . . . SET
-0023 30 09 9: . . . . SEQUENCE
-0025 06 03 3: . . . . . OID 2.5.4.6: C
- : 55 04 06
-0030 13 02 2: . . . . . PrintableString 'US'
- : 55 53
-0034 31 0c 12: . . . SET
-0036 30 0a 10: . . . . SEQUENCE
-0038 06 03 3: . . . . . OID 2.5.4.10: O
- : 55 04 0a
-0043 13 03 3: . . . . . PrintableString 'gov'
- : 67 6f 76
-0048 31 0d 13: . . . SET
-0050 30 0b 11: . . . . SEQUENCE
-0052 06 03 3: . . . . . OID 2.5.4.11: OU
- : 55 04 0b
-
-
-
-Housley, et. al. Standards Track [Page 126]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-0057 13 04 4: . . . . . PrintableString 'nist'
- : 6e 69 73 74
-0063 17 0d 13: . . UTCTime '970801000000Z'
- : 39 37 30 38 30 31 30 30 30 30 30 30 5a
-0078 17 0d 13: . . UTCTime '970808000000Z'
- : 39 37 30 38 30 38 30 30 30 30 30 30 5a
-0093 30 22 34: . . SEQUENCE
-0095 30 20 32: . . . SEQUENCE
-0097 02 01 1: . . . . INTEGER 18
- : 12
-0100 17 0d 13: . . . . UTCTime '970731000000Z'
- : 39 37 30 37 33 31 30 30 30 30 30 30 5a
-0115 30 0c 12: . . . . SEQUENCE
-0117 30 0a 10: . . . . . SEQUENCE
-0119 06 03 3: . . . . . . OID 2.5.29.21: reasonCode
- : 55 1d 15
-0124 04 03 3: . . . . . . OCTET STRING
- : 0a 01 01
-0129 30 09 9: . SEQUENCE
-0131 06 07 7: . . OID 1.2.840.10040.4.3: dsa-with-sha
- : 2a 86 48 ce 38 04 03
-0140 03 2f 47: . BIT STRING (0 unused bits)
- : 30 2c 02 14 9e d8 6b c1 7d c2 c4 02 f5 17 84 f9
- : 9f 46 7a ca cf b7 05 8a 02 14 9e 43 39 85 dc ea
- : 14 13 72 93 54 5d 44 44 e5 05 fe 73 9a b2
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Housley, et. al. Standards Track [Page 127]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-Appendix E. Authors' Addresses
-
- Russell Housley
- SPYRUS
- 381 Elden Street
- Suite 1120
- Herndon, VA 20170
- USA
-
- EMail: housley@spyrus.com
-
-
- Warwick Ford
- VeriSign, Inc.
- One Alewife Center
- Cambridge, MA 02140
- USA
-
- EMail: wford@verisign.com
-
-
- Tim Polk
- NIST
- Building 820, Room 426
- Gaithersburg, MD 20899
- USA
-
- EMail: wpolk@nist.gov
-
-
- David Solo
- Citicorp
- 666 Fifth Ave, 3rd Floor
- New York, NY 10103
- USA
-
- EMail: david.solo@citicorp.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Housley, et. al. Standards Track [Page 128]
-\f
-RFC 2459 Internet X.509 Public Key Infrastructure January 1999
-
-
-Appendix F. Full Copyright Statement
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Housley, et. al. Standards Track [Page 129]
-\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group R. Housley
+Request for Comments: 3280 RSA Laboratories
+Obsoletes: 2459 W. Polk
+Category: Standards Track NIST
+ W. Ford
+ VeriSign
+ D. Solo
+ Citigroup
+ April 2002
+
+ Internet X.509 Public Key Infrastructure
+ Certificate and Certificate Revocation List (CRL) Profile
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This memo profiles the X.509 v3 certificate and X.509 v2 Certificate
+ Revocation List (CRL) for use in the Internet. An overview of this
+ approach and model are provided as an introduction. The X.509 v3
+ certificate format is described in detail, with additional
+ information regarding the format and semantics of Internet name
+ forms. Standard certificate extensions are described and two
+ Internet-specific extensions are defined. A set of required
+ certificate extensions is specified. The X.509 v2 CRL format is
+ described in detail, and required extensions are defined. An
+ algorithm for X.509 certification path validation is described. An
+ ASN.1 module and examples are provided in the appendices.
+
+Table of Contents
+
+ 1 Introduction . . . . . . . . . . . . . . . . . . . . . . 4
+ 2 Requirements and Assumptions . . . . . . . . . . . . . . 5
+ 2.1 Communication and Topology . . . . . . . . . . . . . . 6
+ 2.2 Acceptability Criteria . . . . . . . . . . . . . . . . 6
+ 2.3 User Expectations . . . . . . . . . . . . . . . . . . . 7
+ 2.4 Administrator Expectations . . . . . . . . . . . . . . 7
+ 3 Overview of Approach . . . . . . . . . . . . . . . . . . 7
+
+
+
+Housley, et. al. Standards Track [Page 1]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ 3.1 X.509 Version 3 Certificate . . . . . . . . . . . . . . 8
+ 3.2 Certification Paths and Trust . . . . . . . . . . . . . 9
+ 3.3 Revocation . . . . . . . . . . . . . . . . . . . . . . 11
+ 3.4 Operational Protocols . . . . . . . . . . . . . . . . . 13
+ 3.5 Management Protocols . . . . . . . . . . . . . . . . . 13
+ 4 Certificate and Certificate Extensions Profile . . . . . 14
+ 4.1 Basic Certificate Fields . . . . . . . . . . . . . . . 15
+ 4.1.1 Certificate Fields . . . . . . . . . . . . . . . . . 16
+ 4.1.1.1 tbsCertificate . . . . . . . . . . . . . . . . . . 16
+ 4.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . 16
+ 4.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . 16
+ 4.1.2 TBSCertificate . . . . . . . . . . . . . . . . . . . 17
+ 4.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . 17
+ 4.1.2.2 Serial number . . . . . . . . . . . . . . . . . . . 17
+ 4.1.2.3 Signature . . . . . . . . . . . . . . . . . . . . . 18
+ 4.1.2.4 Issuer . . . . . . . . . . . . . . . . . . . . . . 18
+ 4.1.2.5 Validity . . . . . . . . . . . . . . . . . . . . . 22
+ 4.1.2.5.1 UTCTime . . . . . . . . . . . . . . . . . . . . . 22
+ 4.1.2.5.2 GeneralizedTime . . . . . . . . . . . . . . . . . 22
+ 4.1.2.6 Subject . . . . . . . . . . . . . . . . . . . . . . 23
+ 4.1.2.7 Subject Public Key Info . . . . . . . . . . . . . . 24
+ 4.1.2.8 Unique Identifiers . . . . . . . . . . . . . . . . 24
+ 4.1.2.9 Extensions . . . . . . . . . . . . . . . . . . . . . 24
+ 4.2 Certificate Extensions . . . . . . . . . . . . . . . . 24
+ 4.2.1 Standard Extensions . . . . . . . . . . . . . . . . . 25
+ 4.2.1.1 Authority Key Identifier . . . . . . . . . . . . . 26
+ 4.2.1.2 Subject Key Identifier . . . . . . . . . . . . . . 27
+ 4.2.1.3 Key Usage . . . . . . . . . . . . . . . . . . . . . 28
+ 4.2.1.4 Private Key Usage Period . . . . . . . . . . . . . 29
+ 4.2.1.5 Certificate Policies . . . . . . . . . . . . . . . 30
+ 4.2.1.6 Policy Mappings . . . . . . . . . . . . . . . . . . 33
+ 4.2.1.7 Subject Alternative Name . . . . . . . . . . . . . 33
+ 4.2.1.8 Issuer Alternative Name . . . . . . . . . . . . . . 36
+ 4.2.1.9 Subject Directory Attributes . . . . . . . . . . . 36
+ 4.2.1.10 Basic Constraints . . . . . . . . . . . . . . . . 36
+ 4.2.1.11 Name Constraints . . . . . . . . . . . . . . . . . 37
+ 4.2.1.12 Policy Constraints . . . . . . . . . . . . . . . . 40
+ 4.2.1.13 Extended Key Usage . . . . . . . . . . . . . . . . 40
+ 4.2.1.14 CRL Distribution Points . . . . . . . . . . . . . 42
+ 4.2.1.15 Inhibit Any-Policy . . . . . . . . . . . . . . . . 44
+ 4.2.1.16 Freshest CRL . . . . . . . . . . . . . . . . . . . 44
+ 4.2.2 Internet Certificate Extensions . . . . . . . . . . . 45
+ 4.2.2.1 Authority Information Access . . . . . . . . . . . 45
+ 4.2.2.2 Subject Information Access . . . . . . . . . . . . 46
+ 5 CRL and CRL Extensions Profile . . . . . . . . . . . . . 48
+ 5.1 CRL Fields . . . . . . . . . . . . . . . . . . . . . . 49
+ 5.1.1 CertificateList Fields . . . . . . . . . . . . . . . 50
+ 5.1.1.1 tbsCertList . . . . . . . . . . . . . . . . . . . . 50
+
+
+
+Housley, et. al. Standards Track [Page 2]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ 5.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . 50
+ 5.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . 51
+ 5.1.2 Certificate List "To Be Signed" . . . . . . . . . . . 51
+ 5.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . 52
+ 5.1.2.2 Signature . . . . . . . . . . . . . . . . . . . . . 52
+ 5.1.2.3 Issuer Name . . . . . . . . . . . . . . . . . . . . 52
+ 5.1.2.4 This Update . . . . . . . . . . . . . . . . . . . . 52
+ 5.1.2.5 Next Update . . . . . . . . . . . . . . . . . . . . 53
+ 5.1.2.6 Revoked Certificates . . . . . . . . . . . . . . . 53
+ 5.1.2.7 Extensions . . . . . . . . . . . . . . . . . . . . 53
+ 5.2 CRL Extensions . . . . . . . . . . . . . . . . . . . . 53
+ 5.2.1 Authority Key Identifier . . . . . . . . . . . . . . 54
+ 5.2.2 Issuer Alternative Name . . . . . . . . . . . . . . . 54
+ 5.2.3 CRL Number . . . . . . . . . . . . . . . . . . . . . 55
+ 5.2.4 Delta CRL Indicator . . . . . . . . . . . . . . . . . 55
+ 5.2.5 Issuing Distribution Point . . . . . . . . . . . . . 58
+ 5.2.6 Freshest CRL . . . . . . . . . . . . . . . . . . . . 59
+ 5.3 CRL Entry Extensions . . . . . . . . . . . . . . . . . 60
+ 5.3.1 Reason Code . . . . . . . . . . . . . . . . . . . . . 60
+ 5.3.2 Hold Instruction Code . . . . . . . . . . . . . . . . 61
+ 5.3.3 Invalidity Date . . . . . . . . . . . . . . . . . . . 62
+ 5.3.4 Certificate Issuer . . . . . . . . . . . . . . . . . 62
+ 6 Certificate Path Validation . . . . . . . . . . . . . . . 62
+ 6.1 Basic Path Validation . . . . . . . . . . . . . . . . . 63
+ 6.1.1 Inputs . . . . . . . . . . . . . . . . . . . . . . . 66
+ 6.1.2 Initialization . . . . . . . . . . . . . . . . . . . 67
+ 6.1.3 Basic Certificate Processing . . . . . . . . . . . . 70
+ 6.1.4 Preparation for Certificate i+1 . . . . . . . . . . . 75
+ 6.1.5 Wrap-up procedure . . . . . . . . . . . . . . . . . . 78
+ 6.1.6 Outputs . . . . . . . . . . . . . . . . . . . . . . . 80
+ 6.2 Extending Path Validation . . . . . . . . . . . . . . . 80
+ 6.3 CRL Validation . . . . . . . . . . . . . . . . . . . . 81
+ 6.3.1 Revocation Inputs . . . . . . . . . . . . . . . . . . 82
+ 6.3.2 Initialization and Revocation State Variables . . . . 82
+ 6.3.3 CRL Processing . . . . . . . . . . . . . . . . . . . 83
+ 7 References . . . . . . . . . . . . . . . . . . . . . . . 86
+ 8 Intellectual Property Rights . . . . . . . . . . . . . . 88
+ 9 Security Considerations . . . . . . . . . . . . . . . . . 89
+ Appendix A. ASN.1 Structures and OIDs . . . . . . . . . . . 92
+ A.1 Explicitly Tagged Module, 1988 Syntax . . . . . . . . . 92
+ A.2 Implicitly Tagged Module, 1988 Syntax . . . . . . . . . 105
+ Appendix B. ASN.1 Notes . . . . . . . . . . . . . . . . . . 112
+ Appendix C. Examples . . . . . . . . . . . . . . . . . . . 115
+ C.1 DSA Self-Signed Certificate . . . . . . . . . . . . . . 115
+ C.2 End Entity Certificate Using DSA . . . . . . . . . . . 119
+ C.3 End Entity Certificate Using RSA . . . . . . . . . . . 122
+ C.4 Certificate Revocation List . . . . . . . . . . . . . . 126
+ Author Addresses . . . . . . . . . . . . . . . . . . . . . . 128
+
+
+
+Housley, et. al. Standards Track [Page 3]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . 129
+
+1 Introduction
+
+ This specification is one part of a family of standards for the X.509
+ Public Key Infrastructure (PKI) for the Internet.
+
+ This specification profiles the format and semantics of certificates
+ and certificate revocation lists (CRLs) for the Internet PKI.
+ Procedures are described for processing of certification paths in the
+ Internet environment. Finally, ASN.1 modules are provided in the
+ appendices for all data structures defined or referenced.
+
+ Section 2 describes Internet PKI requirements, and the assumptions
+ which affect the scope of this document. Section 3 presents an
+ architectural model and describes its relationship to previous IETF
+ and ISO/IEC/ITU-T standards. In particular, this document's
+ relationship with the IETF PEM specifications and the ISO/IEC/ITU-T
+ X.509 documents are described.
+
+ Section 4 profiles the X.509 version 3 certificate, and section 5
+ profiles the X.509 version 2 CRL. The profiles include the
+ identification of ISO/IEC/ITU-T and ANSI extensions which may be
+ useful in the Internet PKI. The profiles are presented in the 1988
+ Abstract Syntax Notation One (ASN.1) rather than the 1997 ASN.1
+ syntax used in the most recent ISO/IEC/ITU-T standards.
+
+ Section 6 includes certification path validation procedures. These
+ procedures are based upon the ISO/IEC/ITU-T definition.
+ Implementations are REQUIRED to derive the same results but are not
+ required to use the specified procedures.
+
+ Procedures for identification and encoding of public key materials
+ and digital signatures are defined in [PKIXALGS]. Implementations of
+ this specification are not required to use any particular
+ cryptographic algorithms. However, conforming implementations which
+ use the algorithms identified in [PKIXALGS] MUST identify and encode
+ the public key materials and digital signatures as described in that
+ specification.
+
+ Finally, three appendices are provided to aid implementers. Appendix
+ A contains all ASN.1 structures defined or referenced within this
+ specification. As above, the material is presented in the 1988
+ ASN.1. Appendix B contains notes on less familiar features of the
+ ASN.1 notation used within this specification. Appendix C contains
+ examples of a conforming certificate and a conforming CRL.
+
+
+
+
+
+Housley, et. al. Standards Track [Page 4]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ This specification obsoletes RFC 2459. This specification differs
+ from RFC 2459 in five basic areas:
+
+ * To promote interoperable implementations, a detailed algorithm
+ for certification path validation is included in section 6.1 of
+ this specification; RFC 2459 provided only a high-level
+ description of path validation.
+
+ * An algorithm for determining the status of a certificate using
+ CRLs is provided in section 6.3 of this specification. This
+ material was not present in RFC 2459.
+
+ * To accommodate new usage models, detailed information describing
+ the use of delta CRLs is provided in Section 5 of this
+ specification.
+
+ * Identification and encoding of public key materials and digital
+ signatures are not included in this specification, but are now
+ described in a companion specification [PKIXALGS].
+
+ * Four additional extensions are specified: three certificate
+ extensions and one CRL extension. The certificate extensions are
+ subject info access, inhibit any-policy, and freshest CRL. The
+ freshest CRL extension is also defined as a CRL extension.
+
+ * Throughout the specification, clarifications have been
+ introduced to enhance consistency with the ITU-T X.509
+ specification. X.509 defines the certificate and CRL format as
+ well as many of the extensions that appear in this specification.
+ These changes were introduced to improve the likelihood of
+ interoperability between implementations based on this
+ specification with implementations based on the ITU-T
+ specification.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119.
+
+2 Requirements and Assumptions
+
+ The goal of this specification is to develop a profile to facilitate
+ the use of X.509 certificates within Internet applications for those
+ communities wishing to make use of X.509 technology. Such
+ applications may include WWW, electronic mail, user authentication,
+ and IPsec. In order to relieve some of the obstacles to using X.509
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 5]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ certificates, this document defines a profile to promote the
+ development of certificate management systems; development of
+ application tools; and interoperability determined by policy.
+
+ Some communities will need to supplement, or possibly replace, this
+ profile in order to meet the requirements of specialized application
+ domains or environments with additional authorization, assurance, or
+ operational requirements. However, for basic applications, common
+ representations of frequently used attributes are defined so that
+ application developers can obtain necessary information without
+ regard to the issuer of a particular certificate or certificate
+ revocation list (CRL).
+
+ A certificate user should review the certificate policy generated by
+ the certification authority (CA) before relying on the authentication
+ or non-repudiation services associated with the public key in a
+ particular certificate. To this end, this standard does not
+ prescribe legally binding rules or duties.
+
+ As supplemental authorization and attribute management tools emerge,
+ such as attribute certificates, it may be appropriate to limit the
+ authenticated attributes that are included in a certificate. These
+ other management tools may provide more appropriate methods of
+ conveying many authenticated attributes.
+
+2.1 Communication and Topology
+
+ The users of certificates will operate in a wide range of
+ environments with respect to their communication topology, especially
+ users of secure electronic mail. This profile supports users without
+ high bandwidth, real-time IP connectivity, or high connection
+ availability. In addition, the profile allows for the presence of
+ firewall or other filtered communication.
+
+ This profile does not assume the deployment of an X.500 Directory
+ system or a LDAP directory system. The profile does not prohibit the
+ use of an X.500 Directory or a LDAP directory; however, any means of
+ distributing certificates and certificate revocation lists (CRLs) may
+ be used.
+
+2.2 Acceptability Criteria
+
+ The goal of the Internet Public Key Infrastructure (PKI) is to meet
+ the needs of deterministic, automated identification, authentication,
+ access control, and authorization functions. Support for these
+ services determines the attributes contained in the certificate as
+ well as the ancillary control information in the certificate such as
+ policy data and certification path constraints.
+
+
+
+Housley, et. al. Standards Track [Page 6]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+2.3 User Expectations
+
+ Users of the Internet PKI are people and processes who use client
+ software and are the subjects named in certificates. These uses
+ include readers and writers of electronic mail, the clients for WWW
+ browsers, WWW servers, and the key manager for IPsec within a router.
+ This profile recognizes the limitations of the platforms these users
+ employ and the limitations in sophistication and attentiveness of the
+ users themselves. This manifests itself in minimal user
+ configuration responsibility (e.g., trusted CA keys, rules), explicit
+ platform usage constraints within the certificate, certification path
+ constraints which shield the user from many malicious actions, and
+ applications which sensibly automate validation functions.
+
+2.4 Administrator Expectations
+
+ As with user expectations, the Internet PKI profile is structured to
+ support the individuals who generally operate CAs. Providing
+ administrators with unbounded choices increases the chances that a
+ subtle CA administrator mistake will result in broad compromise.
+ Also, unbounded choices greatly complicate the software that process
+ and validate the certificates created by the CA.
+
+3 Overview of Approach
+
+ Following is a simplified view of the architectural model assumed by
+ the PKIX specifications.
+
+ The components in this model are:
+
+ end entity: user of PKI certificates and/or end user system that is
+ the subject of a certificate;
+ CA: certification authority;
+ RA: registration authority, i.e., an optional system to which
+ a CA delegates certain management functions;
+ CRL issuer: an optional system to which a CA delegates the
+ publication of certificate revocation lists;
+ repository: a system or collection of distributed systems that stores
+ certificates and CRLs and serves as a means of
+ distributing these certificates and CRLs to end entities.
+
+ Note that an Attribute Authority (AA) might also choose to delegate
+ the publication of CRLs to a CRL issuer.
+
+
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 7]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ +---+
+ | C | +------------+
+ | e | <-------------------->| End entity |
+ | r | Operational +------------+
+ | t | transactions ^
+ | i | and management | Management
+ | f | transactions | transactions PKI
+ | i | | users
+ | c | v
+ | a | ======================= +--+------------+ ==============
+ | t | ^ ^
+ | e | | | PKI
+ | | v | management
+ | & | +------+ | entities
+ | | <---------------------| RA |<----+ |
+ | C | Publish certificate +------+ | |
+ | R | | |
+ | L | | |
+ | | v v
+ | R | +------------+
+ | e | <------------------------------| CA |
+ | p | Publish certificate +------------+
+ | o | Publish CRL ^ ^
+ | s | | | Management
+ | i | +------------+ | | transactions
+ | t | <--------------| CRL Issuer |<----+ |
+ | o | Publish CRL +------------+ v
+ | r | +------+
+ | y | | CA |
+ +---+ +------+
+
+ Figure 1 - PKI Entities
+
+3.1 X.509 Version 3 Certificate
+
+ Users of a public key require confidence that the associated private
+ key is owned by the correct remote subject (person or system) with
+ which an encryption or digital signature mechanism will be used.
+ This confidence is obtained through the use of public key
+ certificates, which are data structures that bind public key values
+ to subjects. The binding is asserted by having a trusted CA
+ digitally sign each certificate. The CA may base this assertion upon
+ technical means (a.k.a., proof of possession through a challenge-
+ response protocol), presentation of the private key, or on an
+ assertion by the subject. A certificate has a limited valid lifetime
+ which is indicated in its signed contents. Because a certificate's
+ signature and timeliness can be independently checked by a
+ certificate-using client, certificates can be distributed via
+
+
+
+Housley, et. al. Standards Track [Page 8]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ untrusted communications and server systems, and can be cached in
+ unsecured storage in certificate-using systems.
+
+ ITU-T X.509 (formerly CCITT X.509) or ISO/IEC 9594-8, which was first
+ published in 1988 as part of the X.500 Directory recommendations,
+ defines a standard certificate format [X.509]. The 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, resulting
+ in the version 2 (v2) format.
+
+ The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993,
+ include specifications for a public key infrastructure based on X.509
+ v1 certificates [RFC 1422]. The experience gained in attempts to
+ deploy RFC 1422 made it clear that the v1 and v2 certificate formats
+ are deficient in several respects. Most importantly, more fields
+ were needed to carry information which PEM design and implementation
+ experience had proven necessary. In response to these new
+ requirements, ISO/IEC, ITU-T and ANSI X9 developed the X.509 version
+ 3 (v3) certificate format. The v3 format extends the v2 format by
+ adding provision for additional extension fields. Particular
+ extension field types may be specified in standards or may be defined
+ and registered by any organization or community. In June 1996,
+ standardization of the basic v3 format was completed [X.509].
+
+ ISO/IEC, ITU-T, and ANSI X9 have also developed standard extensions
+ for use in the v3 extensions field [X.509][X9.55]. These extensions
+ can convey such data as additional subject identification
+ information, key attribute information, policy information, and
+ certification path constraints.
+
+ However, the ISO/IEC, ITU-T, and ANSI X9 standard extensions are very
+ broad in their applicability. In order to develop interoperable
+ implementations of X.509 v3 systems for Internet use, it is necessary
+ to specify a profile for use of the X.509 v3 extensions tailored for
+ the Internet. It is one goal of this document to specify a profile
+ for Internet WWW, electronic mail, and IPsec applications.
+ Environments with additional requirements may build on this profile
+ or may replace it.
+
+3.2 Certification Paths and Trust
+
+ A user of a security service requiring knowledge of a public key
+ generally needs to obtain and validate a certificate containing the
+ required public key. If the public key user does not already hold an
+ assured copy of the public key of the CA that signed the certificate,
+ the CA's name, and related information (such as the validity period
+ or name constraints), then it might need an additional certificate to
+ obtain that public key. In general, a chain of multiple certificates
+
+
+
+Housley, et. al. Standards Track [Page 9]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ may be needed, comprising a certificate of the public key owner (the
+ end entity) signed by one CA, and zero or more additional
+ certificates of CAs signed by other CAs. Such chains, called
+ certification paths, are required because a public key user is only
+ initialized with a limited number of assured CA public keys.
+
+ There are different ways in which CAs might be configured in order
+ for public key users to be able to find certification paths. For
+ PEM, RFC 1422 defined a rigid hierarchical structure of CAs. There
+ are three types of PEM certification authority:
+
+ (a) Internet Policy Registration Authority (IPRA): This
+ authority, operated under the auspices of the Internet Society,
+ acts as the root of the PEM certification hierarchy at level 1.
+ It issues certificates only for the next level of authorities,
+ PCAs. All certification paths start with the IPRA.
+
+ (b) Policy Certification Authorities (PCAs): PCAs are at level 2
+ of the hierarchy, each PCA being certified by the IPRA. A PCA
+ shall establish and publish a statement of its policy with respect
+ to certifying users or subordinate certification authorities.
+ Distinct PCAs aim to satisfy different user needs. For example,
+ one PCA (an organizational PCA) might support the general
+ electronic mail needs of commercial organizations, and another PCA
+ (a high-assurance PCA) might have a more stringent policy designed
+ for satisfying legally binding digital signature requirements.
+
+ (c) Certification Authorities (CAs): CAs are at level 3 of the
+ hierarchy and can also be at lower levels. Those at level 3 are
+ certified by PCAs. CAs represent, for example, particular
+ organizations, particular organizational units (e.g., departments,
+ groups, sections), or particular geographical areas.
+
+ RFC 1422 furthermore has a name subordination rule which requires
+ 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.
+ The trust associated with a PEM certification path is implied by the
+ PCA name. The name subordination rule ensures that CAs below the PCA
+ are sensibly constrained as to the set of subordinate entities they
+ can certify (e.g., a CA for an organization can only certify entities
+ in that organization's name tree). Certificate user systems are able
+ to mechanically check that the name subordination rule has been
+ followed.
+
+ The RFC 1422 uses the X.509 v1 certificate formats. The limitations
+ of X.509 v1 required imposition of several structural restrictions to
+ clearly associate policy information or restrict the utility of
+ certificates. These restrictions included:
+
+
+
+Housley, et. al. Standards Track [Page 10]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ (a) a pure top-down hierarchy, with all certification paths
+ starting from IPRA;
+
+ (b) a naming subordination rule restricting the names of a CA's
+ subjects; and
+
+ (c) use of the PCA concept, which requires knowledge of
+ individual PCAs to be built into certificate chain verification
+ logic. Knowledge of individual PCAs was required to determine if
+ a chain could be accepted.
+
+ With X.509 v3, most of the requirements addressed by RFC 1422 can be
+ addressed using certificate extensions, without a need to restrict
+ the CA structures used. In particular, the certificate extensions
+ relating to certificate policies obviate the need for PCAs and the
+ constraint extensions obviate the need for the name subordination
+ rule. As a result, this document supports a more flexible
+ architecture, including:
+
+ (a) Certification paths start with a public key of a CA in a
+ user's own domain, or with the public key of the top of a
+ hierarchy. Starting with the public key of a CA in a user's own
+ domain has certain advantages. In some environments, the local
+ domain is the most trusted.
+
+ (b) Name constraints may be imposed through explicit inclusion of
+ a name constraints extension in a certificate, but are not
+ required.
+
+ (c) Policy extensions and policy mappings replace the PCA
+ concept, which permits a greater degree of automation. The
+ application can determine if the certification path is acceptable
+ based on the contents of the certificates instead of a priori
+ knowledge of PCAs. This permits automation of certification path
+ processing.
+
+3.3 Revocation
+
+ When a certificate is issued, it is expected to be in use for its
+ entire validity period. However, various circumstances may cause a
+ certificate to become invalid prior to the expiration of the validity
+ period. Such circumstances include change of name, change of
+ association between subject and CA (e.g., an employee terminates
+ employment with an organization), and compromise or suspected
+ compromise of the corresponding private key. Under such
+ circumstances, the CA needs to revoke the certificate.
+
+
+
+
+
+Housley, et. al. Standards Track [Page 11]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ X.509 defines one method of certificate revocation. This method
+ involves each CA periodically issuing a signed data structure called
+ a certificate revocation list (CRL). A CRL is a time stamped list
+ identifying revoked certificates which is signed by a CA or CRL
+ issuer and made freely available in a public repository. Each
+ revoked certificate is identified in a CRL by its certificate serial
+ number. When a certificate-using system uses a certificate (e.g.,
+ for verifying a remote user's digital signature), that system not
+ only checks the certificate signature and validity but also acquires
+ a suitably-recent CRL and checks that the certificate serial number
+ is not on that CRL. The meaning of "suitably-recent" may vary with
+ local policy, but it usually means the most recently-issued CRL. A
+ new CRL is issued on a regular periodic basis (e.g., hourly, daily,
+ or weekly). An entry is added to the CRL as part of the next update
+ following notification of revocation. An entry MUST NOT be removed
+ from the CRL until it appears on one regularly scheduled CRL issued
+ beyond the revoked certificate's validity period.
+
+ An advantage of this revocation method is that CRLs may be
+ distributed by exactly the same means as certificates themselves,
+ namely, via untrusted servers and untrusted communications.
+
+ One limitation of the CRL revocation method, using untrusted
+ communications and servers, is that the time granularity of
+ revocation is limited to the CRL issue period. For example, if a
+ revocation is reported now, that revocation will not be reliably
+ notified to certificate-using systems until all currently issued CRLs
+ are updated -- this may be up to one hour, one day, or one week
+ depending on the frequency that CRLs are issued.
+
+ As with the X.509 v3 certificate format, in order to facilitate
+ interoperable implementations from multiple vendors, the X.509 v2 CRL
+ format needs to be profiled for Internet use. It is one goal of this
+ document to specify that profile. However, this profile does not
+ require the issuance of CRLs. Message formats and protocols
+ supporting on-line revocation notification are defined in other PKIX
+ specifications. On-line methods of revocation notification may be
+ applicable in some environments as an alternative to the X.509 CRL.
+ On-line revocation checking may significantly reduce the latency
+ between a revocation report and the distribution of the information
+ to relying parties. Once the CA accepts a revocation report as
+ authentic and valid, any query to the on-line service will correctly
+ reflect the certificate validation impacts of the revocation.
+ However, these methods impose new security requirements: the
+ certificate validator needs to trust the on-line validation service
+ while the repository does not need to be trusted.
+
+
+
+
+
+Housley, et. al. Standards Track [Page 12]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+3.4 Operational Protocols
+
+ Operational protocols are required to deliver certificates and CRLs
+ (or status information) to certificate using client systems.
+ Provisions are needed for a variety of different means of certificate
+ and CRL delivery, including distribution procedures based on LDAP,
+ HTTP, FTP, and X.500. Operational protocols supporting these
+ functions are defined in other PKIX specifications. These
+ specifications may include definitions of message formats and
+ procedures for supporting all of the above operational environments,
+ including definitions of or references to appropriate MIME content
+ types.
+
+3.5 Management Protocols
+
+ Management protocols are required to support on-line interactions
+ between PKI user and management entities. For example, a management
+ protocol might be used between a CA and a client system with which a
+ key pair is associated, or between two CAs which cross-certify each
+ other. The set of functions which potentially need to be supported
+ by management protocols include:
+
+ (a) registration: This is the process whereby a user first makes
+ itself known to a CA (directly, or through an RA), prior to that
+ CA issuing a certificate or certificates for that user.
+
+ (b) initialization: Before a client system can operate securely
+ it is necessary to install key materials which have the
+ appropriate relationship with keys stored elsewhere in the
+ infrastructure. For example, the client needs to be securely
+ initialized with the public key and other assured information of
+ the trusted CA(s), to be used in validating certificate paths.
+
+ Furthermore, a client typically needs to be initialized with its
+ own key pair(s).
+
+ (c) certification: This is the process in which a CA issues a
+ certificate for a user's public key, and returns that certificate
+ to the user's client system and/or posts that certificate in a
+ repository.
+
+ (d) key pair recovery: As an option, user client key materials
+ (e.g., a user's private key used for encryption purposes) may be
+ backed up by a CA or a key backup system. If a user needs to
+ recover these backed up key materials (e.g., as a result of a
+ forgotten password or a lost key chain file), an on-line protocol
+ exchange may be needed to support such recovery.
+
+
+
+
+Housley, et. al. Standards Track [Page 13]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ (e) key pair update: All key pairs need to be updated regularly,
+ i.e., replaced with a new key pair, and new certificates issued.
+
+ (f) revocation request: An authorized person advises a CA of an
+ abnormal situation requiring certificate revocation.
+
+ (g) cross-certification: Two CAs exchange information used in
+ establishing a cross-certificate. A cross-certificate is a
+ certificate issued by one CA to another CA which contains a CA
+ signature key used for issuing certificates.
+
+ Note that on-line protocols are not the only way of implementing the
+ above functions. For all functions there are off-line methods of
+ achieving the same result, and this specification does not mandate
+ use of on-line protocols. For example, when hardware tokens are
+ used, many of the functions may be achieved as part of the physical
+ token delivery. Furthermore, some of the above functions may be
+ combined into one protocol exchange. In particular, two or more of
+ the registration, initialization, and certification functions can be
+ combined into one protocol exchange.
+
+ The PKIX series of specifications defines a set of standard message
+ formats supporting the above functions. The protocols for conveying
+ these messages in different environments (e.g., e-mail, file
+ transfer, and WWW) are described in those specifications.
+
+4 Certificate and Certificate Extensions Profile
+
+ This section presents a profile for public key certificates that will
+ foster interoperability and a reusable PKI. This section is based
+ upon the X.509 v3 certificate format and the standard certificate
+ extensions defined in [X.509]. The ISO/IEC and ITU-T documents use
+ the 1997 version of ASN.1; while this document uses the 1988 ASN.1
+ syntax, the encoded certificate and standard extensions are
+ equivalent. This section also defines private extensions required to
+ support a PKI for the Internet community.
+
+ Certificates may be used in a wide range of applications and
+ environments covering a broad spectrum of interoperability goals and
+ a broader spectrum of operational and assurance requirements. The
+ goal of this document is to establish a common baseline for generic
+ applications requiring broad interoperability and limited special
+ purpose requirements. In particular, the emphasis will be on
+ supporting the use of X.509 v3 certificates for informal Internet
+ electronic mail, IPsec, and WWW applications.
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 14]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+4.1 Basic Certificate Fields
+
+ The X.509 v3 certificate basic syntax is as follows. For signature
+ calculation, the data that is to be signed is encoded using the ASN.1
+ distinguished encoding rules (DER) [X.690]. ASN.1 DER encoding is a
+ tag, length, value encoding system for each element.
+
+ Certificate ::= SEQUENCE {
+ tbsCertificate TBSCertificate,
+ signatureAlgorithm AlgorithmIdentifier,
+ signatureValue BIT STRING }
+
+ TBSCertificate ::= SEQUENCE {
+ version [0] EXPLICIT Version DEFAULT v1,
+ serialNumber CertificateSerialNumber,
+ signature AlgorithmIdentifier,
+ issuer Name,
+ validity Validity,
+ subject Name,
+ subjectPublicKeyInfo SubjectPublicKeyInfo,
+ issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
+ -- If present, version MUST be v2 or v3
+ subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
+ -- If present, version MUST be v2 or v3
+ extensions [3] EXPLICIT Extensions OPTIONAL
+ -- If present, version MUST be v3
+ }
+
+ Version ::= INTEGER { v1(0), v2(1), v3(2) }
+
+ CertificateSerialNumber ::= INTEGER
+
+ Validity ::= SEQUENCE {
+ notBefore Time,
+ notAfter Time }
+
+ Time ::= CHOICE {
+ utcTime UTCTime,
+ generalTime GeneralizedTime }
+
+ UniqueIdentifier ::= BIT STRING
+
+ SubjectPublicKeyInfo ::= SEQUENCE {
+ algorithm AlgorithmIdentifier,
+ subjectPublicKey BIT STRING }
+
+ Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
+
+
+
+
+Housley, et. al. Standards Track [Page 15]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ Extension ::= SEQUENCE {
+ extnID OBJECT IDENTIFIER,
+ critical BOOLEAN DEFAULT FALSE,
+ extnValue OCTET STRING }
+
+ The following items describe the X.509 v3 certificate for use in the
+ Internet.
+
+4.1.1 Certificate Fields
+
+ The Certificate is a SEQUENCE of three required fields. The fields
+ are described in detail in the following subsections.
+
+4.1.1.1 tbsCertificate
+
+ The field contains the names of the subject and issuer, a public key
+ associated with the subject, a validity period, and other associated
+ information. The fields are described in detail in section 4.1.2;
+ the tbsCertificate usually includes extensions which are described in
+ section 4.2.
+
+4.1.1.2 signatureAlgorithm
+
+ The signatureAlgorithm field contains the identifier for the
+ cryptographic algorithm used by the CA to sign this certificate.
+ [PKIXALGS] lists supported signature algorithms, but other signature
+ algorithms MAY also be supported.
+
+ An algorithm identifier is defined by the following ASN.1 structure:
+
+ AlgorithmIdentifier ::= SEQUENCE {
+ algorithm OBJECT IDENTIFIER,
+ parameters ANY DEFINED BY algorithm OPTIONAL }
+
+ The algorithm identifier is used to identify a cryptographic
+ algorithm. The OBJECT IDENTIFIER component identifies the algorithm
+ (such as DSA with SHA-1). The contents of the optional parameters
+ field will vary according to the algorithm identified.
+
+ This field MUST contain the same algorithm identifier as the
+ signature field in the sequence tbsCertificate (section 4.1.2.3).
+
+4.1.1.3 signatureValue
+
+ The signatureValue field contains a digital signature computed upon
+ the ASN.1 DER encoded tbsCertificate. The ASN.1 DER encoded
+ tbsCertificate is used as the input to the signature function. This
+
+
+
+
+Housley, et. al. Standards Track [Page 16]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ signature value is encoded as a BIT STRING and included in the
+ signature field. The details of this process are specified for each
+ of algorithms listed in [PKIXALGS].
+
+ By generating this signature, a CA certifies the validity of the
+ information in the tbsCertificate field. In particular, the CA
+ certifies the binding between the public key material and the subject
+ of the certificate.
+
+4.1.2 TBSCertificate
+
+ The sequence TBSCertificate contains information associated with the
+ subject of the certificate and the CA who issued it. Every
+ TBSCertificate contains the names of the subject and issuer, a public
+ key associated with the subject, a validity period, a version number,
+ and a serial number; some MAY contain optional unique identifier
+ fields. The remainder of this section describes the syntax and
+ semantics of these fields. A TBSCertificate usually includes
+ extensions. Extensions for the Internet PKI are described in Section
+ 4.2.
+
+4.1.2.1 Version
+
+ This field describes the version of the encoded certificate. When
+ extensions are used, as expected in this profile, version MUST be 3
+ (value is 2). If no extensions are present, but a UniqueIdentifier
+ is present, the version SHOULD be 2 (value is 1); however version MAY
+ be 3. If only basic fields are present, the version SHOULD be 1 (the
+ value is omitted from the certificate as the default value); however
+ the version MAY be 2 or 3.
+
+ Implementations SHOULD be prepared to accept any version certificate.
+ At a minimum, conforming implementations MUST recognize version 3
+ certificates.
+
+ Generation of version 2 certificates is not expected by
+ implementations based on this profile.
+
+4.1.2.2 Serial number
+
+ The serial number MUST be a positive integer assigned by the CA to
+ each certificate. It MUST be unique for each certificate issued by a
+ given CA (i.e., the issuer name and serial number identify a unique
+ certificate). CAs MUST force the serialNumber to be a non-negative
+ integer.
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 17]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ Given the uniqueness requirements above, serial numbers can be
+ expected to contain long integers. Certificate users MUST be able to
+ handle serialNumber values up to 20 octets. Conformant CAs MUST NOT
+ use serialNumber values longer than 20 octets.
+
+ Note: Non-conforming CAs may issue certificates with serial numbers
+ that are negative, or zero. Certificate users SHOULD be prepared to
+ gracefully handle such certificates.
+
+4.1.2.3 Signature
+
+ This field contains the algorithm identifier for the algorithm used
+ by the CA to sign the certificate.
+
+ This field MUST contain the same algorithm identifier as the
+ signatureAlgorithm field in the sequence Certificate (section
+ 4.1.1.2). The contents of the optional parameters field will vary
+ according to the algorithm identified. [PKIXALGS] lists the
+ supported signature algorithms, but other signature algorithms MAY
+ also be supported.
+
+4.1.2.4 Issuer
+
+ The issuer field identifies the entity who has signed and issued the
+ certificate. The issuer field MUST contain a non-empty distinguished
+ name (DN). The issuer field is defined as the X.501 type Name
+ [X.501]. Name is defined by the following ASN.1 structures:
+
+ Name ::= CHOICE {
+ RDNSequence }
+
+ RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
+
+ RelativeDistinguishedName ::=
+ SET OF AttributeTypeAndValue
+
+ AttributeTypeAndValue ::= SEQUENCE {
+ type AttributeType,
+ value AttributeValue }
+
+ AttributeType ::= OBJECT IDENTIFIER
+
+ AttributeValue ::= ANY DEFINED BY AttributeType
+
+
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 18]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ DirectoryString ::= CHOICE {
+ teletexString TeletexString (SIZE (1..MAX)),
+ printableString PrintableString (SIZE (1..MAX)),
+ universalString UniversalString (SIZE (1..MAX)),
+ utf8String UTF8String (SIZE (1..MAX)),
+ bmpString BMPString (SIZE (1..MAX)) }
+
+ The Name describes a hierarchical name composed of attributes, such
+ as country name, and corresponding values, such as US. The type of
+ the component AttributeValue is determined by the AttributeType; in
+ general it will be a DirectoryString.
+
+ The DirectoryString type is defined as a choice of PrintableString,
+ TeletexString, BMPString, UTF8String, and UniversalString. The
+ UTF8String encoding [RFC 2279] is the preferred encoding, and all
+ certificates issued after December 31, 2003 MUST use the UTF8String
+ encoding of DirectoryString (except as noted below). Until that
+ date, conforming CAs MUST choose from the following options when
+ creating a distinguished name, including their own:
+
+ (a) if the character set is sufficient, the string MAY be
+ represented as a PrintableString;
+
+ (b) failing (a), if the BMPString character set is sufficient the
+ string MAY be represented as a BMPString; and
+
+ (c) failing (a) and (b), the string MUST be represented as a
+ UTF8String. If (a) or (b) is satisfied, the CA MAY still choose
+ to represent the string as a UTF8String.
+
+ Exceptions to the December 31, 2003 UTF8 encoding requirements are as
+ follows:
+
+ (a) CAs MAY issue "name rollover" certificates to support an
+ orderly migration to UTF8String encoding. Such certificates would
+ include the CA's UTF8String encoded name as issuer and and the old
+ name encoding as subject, or vice-versa.
+
+ (b) As stated in section 4.1.2.6, the subject field MUST be
+ populated with a non-empty distinguished name matching the
+ contents of the issuer field in all certificates issued by the
+ subject CA regardless of encoding.
+
+ The TeletexString and UniversalString are included for backward
+ compatibility, and SHOULD NOT be used for certificates for new
+ subjects. However, these types MAY be used in certificates where the
+ name was previously established. Certificate users SHOULD be
+ prepared to receive certificates with these types.
+
+
+
+Housley, et. al. Standards Track [Page 19]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ In addition, many legacy implementations support names encoded in the
+ ISO 8859-1 character set (Latin1String) [ISO 8859-1] but tag them as
+ TeletexString. TeletexString encodes a larger character set than ISO
+ 8859-1, but it encodes some characters differently. Implementations
+ SHOULD be prepared to handle both encodings.
+
+ As noted above, distinguished names are composed of attributes. This
+ specification does not restrict the set of attribute types that may
+ appear in names. However, conforming implementations MUST be
+ prepared to receive certificates with issuer names containing the set
+ of attribute types defined below. This specification RECOMMENDS
+ support for additional attribute types.
+
+ Standard sets of attributes have been defined in the X.500 series of
+ specifications [X.520]. Implementations of this specification MUST
+ be prepared to receive the following standard attribute types in
+ issuer and subject (section 4.1.2.6) names:
+
+ * country,
+ * organization,
+ * organizational-unit,
+ * distinguished name qualifier,
+ * state or province name,
+ * common name (e.g., "Susan Housley"), and
+ * serial number.
+
+ In addition, implementations of this specification SHOULD be prepared
+ to receive the following standard attribute types in issuer and
+ subject names:
+
+ * locality,
+ * title,
+ * surname,
+ * given name,
+ * initials,
+ * pseudonym, and
+ * generation qualifier (e.g., "Jr.", "3rd", or "IV").
+
+ The syntax and associated object identifiers (OIDs) for these
+ attribute types are provided in the ASN.1 modules in Appendix A.
+
+ In addition, implementations of this specification MUST be prepared
+ to receive the domainComponent attribute, as defined in [RFC 2247].
+ The Domain Name System (DNS) provides a hierarchical resource
+ labeling system. This attribute provides a convenient mechanism for
+ organizations that wish to use DNs that parallel their DNS names.
+ This is not a replacement for the dNSName component of the
+
+
+
+
+Housley, et. al. Standards Track [Page 20]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ alternative name field. Implementations are not required to convert
+ such names into DNS names. The syntax and associated OID for this
+ attribute type is provided in the ASN.1 modules in Appendix A.
+
+ Certificate users MUST be prepared to process the issuer
+ distinguished name and subject distinguished name (section 4.1.2.6)
+ fields to perform name chaining for certification path validation
+ (section 6). Name chaining is performed by matching the issuer
+ distinguished name in one certificate with the subject name in a CA
+ certificate.
+
+ This specification requires only a subset of the name comparison
+ functionality specified in the X.500 series of specifications.
+ Conforming implementations are REQUIRED to implement the following
+ name comparison rules:
+
+ (a) attribute values encoded in different types (e.g.,
+ PrintableString and BMPString) MAY be assumed to represent
+ different strings;
+
+ (b) attribute values in types other than PrintableString are case
+ sensitive (this permits matching of attribute values as binary
+ objects);
+
+ (c) attribute values in PrintableString are not case sensitive
+ (e.g., "Marianne Swanson" is the same as "MARIANNE SWANSON"); and
+
+ (d) attribute values in PrintableString are compared after
+ removing leading and trailing white space and converting internal
+ substrings of one or more consecutive white space characters to a
+ single space.
+
+ These name comparison rules permit a certificate user to validate
+ certificates issued using languages or encodings unfamiliar to the
+ certificate user.
+
+ In addition, implementations of this specification MAY use these
+ comparison rules to process unfamiliar attribute types for name
+ chaining. This allows implementations to process certificates with
+ unfamiliar attributes in the issuer name.
+
+ Note that the comparison rules defined in the X.500 series of
+ specifications indicate that the character sets used to encode data
+ in distinguished names are irrelevant. The characters themselves are
+ compared without regard to encoding. Implementations of this profile
+ are permitted to use the comparison algorithm defined in the X.500
+ series. Such an implementation will recognize a superset of name
+ matches recognized by the algorithm specified above.
+
+
+
+Housley, et. al. Standards Track [Page 21]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+4.1.2.5 Validity
+
+ The certificate validity period is the time interval during which the
+ CA warrants that it will maintain information about the status of the
+ certificate. The field is represented as a SEQUENCE of two dates:
+ the date on which the certificate validity period begins (notBefore)
+ and the date on which the certificate validity period ends
+ (notAfter). Both notBefore and notAfter may be encoded as UTCTime or
+ GeneralizedTime.
+
+ CAs conforming to this profile MUST always encode certificate
+ validity dates through the year 2049 as UTCTime; certificate validity
+ dates in 2050 or later MUST be encoded as GeneralizedTime.
+
+ The validity period for a certificate is the period of time from
+ notBefore through notAfter, inclusive.
+
+4.1.2.5.1 UTCTime
+
+ The universal time type, UTCTime, is a standard ASN.1 type intended
+ for representation of dates and time. UTCTime specifies the year
+ through the two low order digits and time is specified to the
+ precision of one minute or one second. UTCTime includes either Z
+ (for Zulu, or Greenwich Mean Time) or a time differential.
+
+ For the purposes of this profile, UTCTime values MUST be expressed
+ Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are
+ YYMMDDHHMMSSZ), even where the number of seconds is zero. Conforming
+ systems MUST interpret the year field (YY) as follows:
+
+ Where YY is greater than or equal to 50, the year SHALL be
+ interpreted as 19YY; and
+
+ Where YY is less than 50, the year SHALL be interpreted as 20YY.
+
+4.1.2.5.2 GeneralizedTime
+
+ The generalized time type, GeneralizedTime, is a standard ASN.1 type
+ for variable precision representation of time. Optionally, the
+ GeneralizedTime field can include a representation of the time
+ differential between local and Greenwich Mean Time.
+
+ For the purposes of this profile, GeneralizedTime values MUST be
+ expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e.,
+ times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero.
+ GeneralizedTime values MUST NOT include fractional seconds.
+
+
+
+
+
+Housley, et. al. Standards Track [Page 22]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+4.1.2.6 Subject
+
+ The subject field identifies the entity associated with the public
+ key stored in the subject public key field. The subject name MAY be
+ carried in the subject field and/or the subjectAltName extension. If
+ the subject is a CA (e.g., the basic constraints extension, as
+ discussed in 4.2.1.10, is present and the value of cA is TRUE), then
+ the subject field MUST be populated with a non-empty distinguished
+ name matching the contents of the issuer field (section 4.1.2.4) in
+ all certificates issued by the subject CA. If the subject is a CRL
+ issuer (e.g., the key usage extension, as discussed in 4.2.1.3, is
+ present and the value of cRLSign is TRUE) then the subject field MUST
+ be populated with a non-empty distinguished name matching the
+ contents of the issuer field (section 4.1.2.4) in all CRLs issued by
+ the subject CRL issuer. If subject naming information is present
+ only in the subjectAltName extension (e.g., a key bound only to an
+ email address or URI), then the subject name MUST be an empty
+ sequence and the subjectAltName extension MUST be critical.
+
+ Where it is non-empty, the subject field MUST contain an X.500
+ distinguished name (DN). 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 certificate with the same DN to the same
+ subject entity.
+
+ The subject name field is defined as the X.501 type Name.
+ Implementation requirements for this field are those defined for the
+ issuer field (section 4.1.2.4). When encoding attribute values of
+ type DirectoryString, the encoding rules for the issuer field MUST be
+ implemented. Implementations of this specification MUST be prepared
+ to receive subject names containing the attribute types required for
+ the issuer field. Implementations of this specification SHOULD be
+ prepared to receive subject names containing the recommended
+ attribute types for the issuer field. The syntax and associated
+ object identifiers (OIDs) for these attribute types are provided in
+ the ASN.1 modules in Appendix A. Implementations of this
+ specification MAY use these comparison rules to process unfamiliar
+ attribute types (i.e., for name chaining). This allows
+ implementations to process certificates with unfamiliar attributes in
+ the subject name.
+
+ In addition, legacy implementations exist where an RFC 822 name is
+ embedded in the subject distinguished name as an EmailAddress
+ attribute. The attribute value for EmailAddress is of type IA5String
+ to permit inclusion of the character '@', which is not part of the
+ PrintableString character set. EmailAddress attribute values are not
+ case sensitive (e.g., "fanfeedback@redsox.com" is the same as
+ "FANFEEDBACK@REDSOX.COM").
+
+
+
+Housley, et. al. Standards Track [Page 23]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ Conforming implementations generating new certificates with
+ electronic mail addresses MUST use the rfc822Name in the subject
+ alternative name field (section 4.2.1.7) to describe such identities.
+ Simultaneous inclusion of the EmailAddress attribute in the subject
+ distinguished name to support legacy implementations is deprecated
+ but permitted.
+
+4.1.2.7 Subject Public Key Info
+
+ This field is used to carry the public key and identify the algorithm
+ with which the key is used (e.g., RSA, DSA, or Diffie-Hellman). The
+ algorithm is identified using the AlgorithmIdentifier structure
+ specified in section 4.1.1.2. The object identifiers for the
+ supported algorithms and the methods for encoding the public key
+ materials (public key and parameters) are specified in [PKIXALGS].
+
+4.1.2.8 Unique Identifiers
+
+ These fields MUST only appear if the version is 2 or 3 (section
+ 4.1.2.1). These fields MUST NOT appear if the version is 1. The
+ subject and issuer unique identifiers are present in the certificate
+ to handle the possibility of reuse of subject and/or issuer names
+ over time. This profile RECOMMENDS that names not be reused for
+ 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
+ conforming to this profile SHOULD be capable of parsing unique
+ identifiers.
+
+4.1.2.9 Extensions
+
+ This field MUST only appear if the version is 3 (section 4.1.2.1).
+ If present, this field is a SEQUENCE of one or more certificate
+ extensions. The format and content of certificate extensions in the
+ Internet PKI is defined in section 4.2.
+
+4.2 Certificate Extensions
+
+ The extensions defined for X.509 v3 certificates provide methods for
+ associating additional attributes with users or public keys and for
+ managing a certification hierarchy. The X.509 v3 certificate format
+ also allows communities to define private extensions to carry
+ information unique to those communities. Each extension in a
+ certificate is designated as either critical or non-critical. A
+ certificate using system MUST reject the certificate if it encounters
+ a critical extension it does not recognize; however, a non-critical
+ extension MAY be ignored if it is not recognized. The following
+ sections present recommended extensions used within Internet
+
+
+
+Housley, et. al. Standards Track [Page 24]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ certificates and standard locations for information. Communities may
+ elect to use additional extensions; however, caution ought to be
+ exercised in adopting any critical extensions in certificates which
+ might prevent use in a general context.
+
+ Each extension includes an OID and an ASN.1 structure. When an
+ extension appears in a certificate, the OID appears as the field
+ extnID and the corresponding ASN.1 encoded structure is the value of
+ the octet string extnValue. A certificate MUST NOT include more than
+ one instance of a particular extension. For example, a certificate
+ may contain only one authority key identifier extension (section
+ 4.2.1.1). An extension includes the boolean critical, with a default
+ value of FALSE. The text for each extension specifies the acceptable
+ values for the critical field.
+
+ Conforming CAs MUST support key identifiers (sections 4.2.1.1 and
+ 4.2.1.2), basic constraints (section 4.2.1.10), key usage (section
+ 4.2.1.3), and certificate policies (section 4.2.1.5) extensions. If
+ the CA issues certificates with an empty sequence for the subject
+ field, the CA MUST support the subject alternative name extension
+ (section 4.2.1.7). Support for the remaining extensions is OPTIONAL.
+ Conforming CAs MAY support extensions that are not identified within
+ this specification; certificate issuers are cautioned that marking
+ such extensions as critical may inhibit interoperability.
+
+ At a minimum, applications conforming to this profile MUST recognize
+ the following extensions: key usage (section 4.2.1.3), certificate
+ policies (section 4.2.1.5), the subject alternative name (section
+ 4.2.1.7), basic constraints (section 4.2.1.10), name constraints
+ (section 4.2.1.11), policy constraints (section 4.2.1.12), extended
+ key usage (section 4.2.1.13), and inhibit any-policy (section
+ 4.2.1.15).
+
+ In addition, applications conforming to this profile SHOULD recognize
+ the authority and subject key identifier (sections 4.2.1.1 and
+ 4.2.1.2), and policy mapping (section 4.2.1.6) extensions.
+
+4.2.1 Standard Extensions
+
+ This section identifies standard certificate extensions defined in
+ [X.509] for use in the Internet PKI. Each extension is associated
+ with an OID defined in [X.509]. These OIDs are members of the id-ce
+ arc, which is defined by the following:
+
+ id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 }
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 25]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+4.2.1.1 Authority Key Identifier
+
+ The authority key identifier extension provides a means of
+ identifying the public key corresponding to the private key used to
+ sign a certificate. This extension is used where an issuer has
+ multiple signing keys (either due to multiple concurrent key pairs or
+ due to changeover). The identification MAY be based on either the
+ key identifier (the subject key identifier in the issuer's
+ certificate) or on the issuer name and serial number.
+
+ The keyIdentifier field of the authorityKeyIdentifier extension MUST
+ be included in all certificates generated by conforming CAs to
+ facilitate certification path construction. There is one exception;
+ where a CA distributes its public key in the form of a "self-signed"
+ certificate, the authority key identifier MAY be omitted. The
+ signature on a self-signed certificate is generated with the private
+ key associated with the certificate's subject public key. (This
+ proves that the issuer possesses both the public and private keys.)
+ In this case, the subject and authority key identifiers would be
+ identical, but only the subject key identifier is needed for
+ certification path building.
+
+ The value of the keyIdentifier field SHOULD be derived from the
+ public key used to verify the certificate's signature or a method
+ that generates unique values. Two common methods for generating key
+ identifiers from the public key, and one common method for generating
+ unique values, are described in section 4.2.1.2. Where a key
+ identifier has not been previously established, this specification
+ RECOMMENDS use of one of these methods for generating keyIdentifiers.
+ Where a key identifier has been previously established, the CA SHOULD
+ use the previously established identifier.
+
+ This profile RECOMMENDS support for the key identifier method by all
+ certificate users.
+
+ This extension MUST NOT be marked critical.
+
+ id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 }
+
+ AuthorityKeyIdentifier ::= SEQUENCE {
+ keyIdentifier [0] KeyIdentifier OPTIONAL,
+ authorityCertIssuer [1] GeneralNames OPTIONAL,
+ authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }
+
+ KeyIdentifier ::= OCTET STRING
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 26]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+4.2.1.2 Subject Key Identifier
+
+ The subject key identifier extension provides a means of identifying
+ certificates that contain a particular public key.
+
+ To facilitate certification path construction, this extension MUST
+ appear in all conforming CA certificates, that is, all certificates
+ including the basic constraints extension (section 4.2.1.10) where
+ the value of cA is TRUE. The value of the subject key identifier
+ MUST be the value placed in the key identifier field of the Authority
+ Key Identifier extension (section 4.2.1.1) of certificates issued by
+ the subject of this certificate.
+
+ For CA certificates, subject key identifiers SHOULD be derived from
+ the public key or a method that generates unique values. Two common
+ methods for generating key identifiers from the public key are:
+
+ (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
+ value of the BIT STRING subjectPublicKey (excluding the tag,
+ length, and number of unused bits).
+
+ (2) The keyIdentifier is composed of a four bit type field with
+ the value 0100 followed by the least significant 60 bits of the
+ SHA-1 hash of the value of the BIT STRING subjectPublicKey
+ (excluding the tag, length, and number of unused bit string bits).
+
+ One common method for generating unique values is a monotonically
+ increasing sequence of integers.
+
+ For end entity certificates, the subject key identifier extension
+ provides a means for identifying certificates containing the
+ particular public key used in an application. Where an end entity
+ has obtained multiple certificates, especially from multiple CAs, the
+ subject key identifier provides a means to quickly identify the set
+ of certificates containing a particular public key. To assist
+ applications in identifying the appropriate end entity certificate,
+ this extension SHOULD be included in all end entity certificates.
+
+ For end entity certificates, subject key identifiers SHOULD be
+ derived from the public key. Two common methods for generating key
+ identifiers from the public key are identified above.
+
+ Where a key identifier has not been previously established, this
+ specification RECOMMENDS use of one of these methods for generating
+ keyIdentifiers. Where a key identifier has been previously
+ established, the CA SHOULD use the previously established identifier.
+
+ This extension MUST NOT be marked critical.
+
+
+
+Housley, et. al. Standards Track [Page 27]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 }
+
+ SubjectKeyIdentifier ::= KeyIdentifier
+
+4.2.1.3 Key Usage
+
+ The key usage extension defines the purpose (e.g., encipherment,
+ signature, certificate signing) of the key contained in the
+ certificate. The usage restriction might be employed when a key that
+ could be used for more than one operation is to be restricted. For
+ example, when an RSA key should be used only to verify signatures on
+ objects other than public key certificates and CRLs, the
+ digitalSignature and/or nonRepudiation bits would be asserted.
+ Likewise, when an RSA key should be used only for key management, the
+ keyEncipherment bit would be asserted.
+
+ This extension MUST appear in certificates that contain public keys
+ that are used to validate digital signatures on other public key
+ certificates or CRLs. When this extension appears, it SHOULD be
+ marked critical.
+
+ id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 }
+
+ KeyUsage ::= BIT STRING {
+ digitalSignature (0),
+ nonRepudiation (1),
+ keyEncipherment (2),
+ dataEncipherment (3),
+ keyAgreement (4),
+ keyCertSign (5),
+ cRLSign (6),
+ encipherOnly (7),
+ decipherOnly (8) }
+
+ Bits in the KeyUsage type are used as follows:
+
+ The digitalSignature bit is asserted when the subject public key
+ is used with a digital signature mechanism to support security
+ services other than certificate signing (bit 5), or CRL signing
+ (bit 6). Digital signature mechanisms are often used for entity
+ authentication and data origin authentication with integrity.
+
+ The nonRepudiation bit is asserted when the subject public key is
+ used to verify digital signatures used to provide a non-
+ repudiation service which protects against the signing entity
+ falsely denying some action, excluding certificate or CRL signing.
+ In the case of later conflict, a reliable third party may
+ determine the authenticity of the signed data.
+
+
+
+Housley, et. al. Standards Track [Page 28]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ Further distinctions between the digitalSignature and
+ nonRepudiation bits may be provided in specific certificate
+ policies.
+
+ 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 management, then this bit is set.
+
+ The dataEncipherment bit is asserted when the subject public key
+ is used for enciphering user data, other than cryptographic keys.
+
+ The keyAgreement bit is asserted when the subject public key is
+ used for key agreement. For example, when a Diffie-Hellman key is
+ to be used for key management, then this bit is set.
+
+ The keyCertSign bit is asserted when the subject public key is
+ used for verifying a signature on public key certificates. If the
+ keyCertSign bit is asserted, then the cA bit in the basic
+ constraints extension (section 4.2.1.10) MUST also be asserted.
+
+ The cRLSign bit is asserted when the subject public key is used
+ for verifying a signature on certificate revocation list (e.g., a
+ CRL, delta CRL, or an ARL). This bit MUST be asserted in
+ certificates that are used to verify signatures on CRLs.
+
+ 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 is also set, the subject public key may be
+ used only for enciphering data while performing key agreement.
+
+ 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 is also set, the subject public key may be
+ used only for deciphering data while performing key agreement.
+
+ This profile does not restrict the combinations of bits that may be
+ set in an instantiation of the keyUsage extension. However,
+ appropriate values for keyUsage extensions for particular algorithms
+ are specified in [PKIXALGS].
+
+4.2.1.4 Private Key Usage Period
+
+ This extension SHOULD NOT be used within the Internet PKI. CAs
+ conforming to this profile MUST NOT generate certificates that
+ include a critical private key usage period extension.
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 29]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ The private key usage period extension allows the certificate issuer
+ to specify a different validity period for the private key than the
+ certificate. This extension is intended for use with digital
+ signature keys. This extension consists of two optional components,
+ notBefore and notAfter. The private key associated with the
+ certificate SHOULD NOT be used to sign objects before or after the
+ times specified by the two components, respectively. CAs conforming
+ to this profile MUST NOT generate certificates with private key usage
+ period extensions unless at least one of the two components is
+ present and the extension is non-critical.
+
+ Where used, notBefore and notAfter are represented as GeneralizedTime
+ and MUST be specified and interpreted as defined in section
+ 4.1.2.5.2.
+
+ id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 }
+
+ PrivateKeyUsagePeriod ::= SEQUENCE {
+ notBefore [0] GeneralizedTime OPTIONAL,
+ notAfter [1] GeneralizedTime OPTIONAL }
+
+4.2.1.5 Certificate Policies
+
+ The certificate policies extension contains a sequence of one or more
+ policy information terms, each of which consists of an object
+ identifier (OID) and optional qualifiers. Optional qualifiers, which
+ MAY be present, are not expected to change the definition of the
+ policy.
+
+ In an end entity certificate, these policy information terms indicate
+ the policy under which the certificate has been issued and the
+ purposes for which the certificate may be used. In a CA certificate,
+ these policy information terms limit the set of policies for
+ certification paths which include this certificate. When a CA does
+ not wish to limit the set of policies for certification paths which
+ include this certificate, it MAY assert the special policy anyPolicy,
+ with a value of { 2 5 29 32 0 }.
+
+ Applications with specific policy requirements are expected to have a
+ list of those policies which they will accept and to compare the
+ policy OIDs in the certificate to that list. If this extension is
+ critical, the path validation software MUST be able to interpret this
+ extension (including the optional qualifier), or MUST reject the
+ certificate.
+
+ To promote interoperability, this profile RECOMMENDS that policy
+ information terms consist of only an OID. Where an OID alone is
+ insufficient, this profile strongly recommends that use of qualifiers
+
+
+
+Housley, et. al. Standards Track [Page 30]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ be limited to those identified in this section. When qualifiers are
+ used with the special policy anyPolicy, they MUST be limited to the
+ qualifiers identified in this section.
+
+ This specification defines two policy qualifier types for use by
+ certificate policy writers and certificate issuers. The qualifier
+ types are the CPS Pointer and User Notice qualifiers.
+
+ The CPS Pointer qualifier contains a pointer to a Certification
+ Practice Statement (CPS) published by the CA. The pointer is in the
+ form of a URI. Processing requirements for this qualifier are a
+ local matter. No action is mandated by this specification regardless
+ of the criticality value asserted for the extension.
+
+ User notice is intended for display to a relying party when a
+ certificate is used. The application software SHOULD display all
+ user notices in all certificates of the certification path used,
+ except that if a notice is duplicated only one copy need be
+ displayed. To prevent such duplication, this qualifier SHOULD only
+ be present in end entity certificates and CA certificates issued to
+ other organizations.
+
+ The user notice has two optional fields: the noticeRef field and the
+ explicitText field.
+
+ The noticeRef field, if used, names an organization and
+ identifies, by number, a particular textual statement prepared by
+ that organization. For example, it might identify the
+ organization "CertsRUs" and notice number 1. In a typical
+ implementation, the application software will have a notice file
+ containing the current set of notices for CertsRUs; the
+ application will extract the notice text from the file and display
+ it. Messages MAY be multilingual, allowing the software to select
+ the particular language message for its own environment.
+
+ An explicitText field includes the textual statement directly in
+ the certificate. The explicitText field is a string with a
+ maximum size of 200 characters.
+
+ If both the noticeRef and explicitText options are included in the
+ one qualifier and if the application software can locate the notice
+ text indicated by the noticeRef option, then that text SHOULD be
+ displayed; otherwise, the explicitText string SHOULD be displayed.
+
+ Note: While the explicitText has a maximum size of 200 characters,
+ some non-conforming CAs exceed this limit. Therefore, certificate
+ users SHOULD gracefully handle explicitText with more than 200
+ characters.
+
+
+
+Housley, et. al. Standards Track [Page 31]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 }
+
+ anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificate-policies 0 }
+
+ certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
+
+ PolicyInformation ::= SEQUENCE {
+ policyIdentifier CertPolicyId,
+ policyQualifiers SEQUENCE SIZE (1..MAX) OF
+ PolicyQualifierInfo OPTIONAL }
+
+ CertPolicyId ::= OBJECT IDENTIFIER
+
+ PolicyQualifierInfo ::= SEQUENCE {
+ policyQualifierId PolicyQualifierId,
+ qualifier ANY DEFINED BY policyQualifierId }
+
+ -- policyQualifierIds for Internet policy qualifiers
+
+ id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
+ id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 }
+ id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 }
+
+ PolicyQualifierId ::=
+ OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )
+
+ Qualifier ::= CHOICE {
+ cPSuri CPSuri,
+ userNotice UserNotice }
+
+ CPSuri ::= IA5String
+
+ UserNotice ::= SEQUENCE {
+ noticeRef NoticeReference OPTIONAL,
+ explicitText DisplayText OPTIONAL}
+
+ NoticeReference ::= SEQUENCE {
+ organization DisplayText,
+ noticeNumbers SEQUENCE OF INTEGER }
+
+ DisplayText ::= CHOICE {
+ ia5String IA5String (SIZE (1..200)),
+ visibleString VisibleString (SIZE (1..200)),
+ bmpString BMPString (SIZE (1..200)),
+ utf8String UTF8String (SIZE (1..200)) }
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 32]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+4.2.1.6 Policy Mappings
+
+ This extension is used in CA certificates. It lists one or more
+ pairs of OIDs; each pair includes an issuerDomainPolicy and a
+ subjectDomainPolicy. The pairing indicates the issuing CA considers
+ its issuerDomainPolicy equivalent to the subject CA's
+ subjectDomainPolicy.
+
+ The issuing CA's users might accept an issuerDomainPolicy for certain
+ applications. The policy mapping defines the list of policies
+ associated with the subject CA that may be accepted as comparable to
+ the issuerDomainPolicy.
+
+ Each issuerDomainPolicy named in the policy mapping extension SHOULD
+ also be asserted in a certificate policies extension in the same
+ certificate. Policies SHOULD NOT be mapped either to or from the
+ special value anyPolicy (section 4.2.1.5).
+
+ This extension MAY be supported by CAs and/or applications, and it
+ MUST be non-critical.
+
+ id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 }
+
+ PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
+ issuerDomainPolicy CertPolicyId,
+ subjectDomainPolicy CertPolicyId }
+
+4.2.1.7 Subject Alternative Name
+
+ The subject alternative names extension allows additional identities
+ to be bound to the subject of the certificate. Defined options
+ include an Internet electronic mail address, a DNS name, an IP
+ address, and a uniform resource identifier (URI). Other options
+ exist, including completely local definitions. Multiple name forms,
+ and multiple instances of each name form, MAY be included. Whenever
+ such identities are to be bound into a certificate, the subject
+ alternative name (or issuer alternative name) extension MUST be used;
+ however, a DNS name MAY be represented in the subject field using the
+ domainComponent attribute as described in section 4.1.2.4.
+
+ Because the subject alternative name is considered to be definitively
+ bound to the public key, all parts of the subject alternative name
+ MUST be verified by the CA.
+
+ Further, if the only subject identity included in the certificate is
+ an alternative name form (e.g., an electronic mail address), then the
+ subject distinguished name MUST be empty (an empty sequence), and the
+
+
+
+
+Housley, et. al. Standards Track [Page 33]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ subjectAltName extension MUST be present. If the subject field
+ contains an empty sequence, the subjectAltName extension MUST be
+ marked critical.
+
+ When the subjectAltName extension contains an Internet mail address,
+ 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
+ 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
+ surrounded in parentheses) after it, and is not surrounded by "<" and
+ ">". Note that while upper and lower case letters are allowed in an
+ RFC 822 addr-spec, no significance is attached to the case.
+
+ When the subjectAltName extension contains a iPAddress, the address
+ MUST be stored in the octet string in "network byte order," as
+ specified in RFC 791 [RFC 791]. The least significant bit (LSB) of
+ 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
+ MUST contain exactly four octets. For IP Version 6, as specified in
+ RFC 1883, the octet string MUST contain exactly sixteen octets [RFC
+ 1883].
+
+ When the subjectAltName extension contains a domain name system
+ label, the domain name MUST be stored in the dNSName (an IA5String).
+ The name MUST be in the "preferred name syntax," as specified by RFC
+ 1034 [RFC 1034]. Note that while upper and lower case letters are
+ allowed in domain names, no signifigance is attached to the case. In
+ addition, while the string " " is a legal domain name, subjectAltName
+ extensions with a dNSName of " " MUST NOT be used. Finally, the use
+ of the DNS representation for Internet mail addresses (wpolk.nist.gov
+ instead of wpolk@nist.gov) MUST NOT be used; such identities are to
+ be encoded as rfc822Name.
+
+ Note: work is currently underway to specify domain names in
+ international character sets. Such names will likely not be
+ accommodated by IA5String. Once this work is complete, this profile
+ will be revisited and the appropriate functionality will be added.
+
+ When the subjectAltName extension contains a URI, the name MUST be
+ stored in the uniformResourceIdentifier (an IA5String). The name
+ MUST NOT be a relative URL, and it MUST follow the URL syntax and
+ encoding rules specified in [RFC 1738]. The name MUST include both a
+ scheme (e.g., "http" or "ftp") and a scheme-specific-part. The
+ scheme-specific-part MUST include a fully qualified domain name or IP
+ address as the host.
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 34]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ 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
+ case-sensitive, but other components of the scheme-specific-part may
+ be case-sensitive. When comparing URIs, conforming implementations
+ MUST compare the scheme and host without regard to case, but assume
+ the remainder of the scheme-specific-part is case sensitive.
+
+ When the subjectAltName extension contains a DN in the directoryName,
+ 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
+ certificate with the same DN to the same subject entity.
+
+ The subjectAltName MAY carry additional name types through the use of
+ the otherName field. The format and semantics of the name are
+ indicated through the OBJECT IDENTIFIER in the type-id field. The
+ name itself is conveyed as value field in otherName. For example,
+ Kerberos [RFC 1510] format names can be encoded into the otherName,
+ using using a Kerberos 5 principal name OID and a SEQUENCE of the
+ Realm and the PrincipalName.
+
+ Subject alternative names MAY be constrained in the same manner as
+ subject distinguished names using the name constraints extension as
+ described in section 4.2.1.11.
+
+ If the subjectAltName extension is present, the sequence MUST contain
+ at least one entry. Unlike the subject field, conforming CAs MUST
+ NOT issue certificates with subjectAltNames containing empty
+ GeneralName fields. For example, an rfc822Name is represented as an
+ IA5String. While an empty string is a valid IA5String, such an
+ rfc822Name is not permitted by this profile. The behavior of clients
+ that encounter such a certificate when processing a certificication
+ path is not defined by this profile.
+
+ Finally, the semantics of subject alternative names that include
+ wildcard characters (e.g., as a placeholder for a set of names) are
+ not addressed by this specification. Applications with specific
+ requirements MAY use such names, but they must define the semantics.
+
+ id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 }
+
+ SubjectAltName ::= GeneralNames
+
+ GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
+
+
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 35]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ GeneralName ::= CHOICE {
+ otherName [0] OtherName,
+ rfc822Name [1] IA5String,
+ dNSName [2] IA5String,
+ x400Address [3] ORAddress,
+ directoryName [4] Name,
+ ediPartyName [5] EDIPartyName,
+ uniformResourceIdentifier [6] IA5String,
+ iPAddress [7] OCTET STRING,
+ registeredID [8] OBJECT IDENTIFIER }
+
+ OtherName ::= SEQUENCE {
+ type-id OBJECT IDENTIFIER,
+ value [0] EXPLICIT ANY DEFINED BY type-id }
+
+ EDIPartyName ::= SEQUENCE {
+ nameAssigner [0] DirectoryString OPTIONAL,
+ partyName [1] DirectoryString }
+
+4.2.1.8 Issuer Alternative Names
+
+ As with 4.2.1.7, this extension is used to associate Internet style
+ identities with the certificate issuer. Issuer alternative names
+ MUST be encoded as in 4.2.1.7.
+
+ Where present, this extension SHOULD NOT be marked critical.
+
+ id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 }
+
+ IssuerAltName ::= GeneralNames
+
+4.2.1.9 Subject Directory Attributes
+
+ The subject directory attributes extension is used to convey
+ identification attributes (e.g., nationality) of the subject. The
+ extension is defined as a sequence of one or more attributes. This
+ extension MUST be non-critical.
+
+ id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 }
+
+ SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute
+
+4.2.1.10 Basic Constraints
+
+ The basic constraints extension identifies whether the subject of the
+ certificate is a CA and the maximum depth of valid certification
+ paths that include this certificate.
+
+
+
+
+Housley, et. al. Standards Track [Page 36]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ The cA boolean indicates whether the certified public key belongs to
+ a CA. If the cA boolean is not asserted, then the keyCertSign bit in
+ the key usage extension MUST NOT be asserted.
+
+ The pathLenConstraint field is meaningful only if the cA boolean is
+ asserted and the key usage extension asserts the keyCertSign bit
+ (section 4.2.1.3). In this case, it gives the maximum number of non-
+ self-issued intermediate certificates that may follow this
+ certificate in a valid certification path. A certificate is self-
+ issued if the DNs that appear in the subject and issuer fields are
+ identical and are not empty. (Note: The last certificate in the
+ certification path is not an intermediate certificate, and is not
+ included in this limit. Usually, the last certificate is an end
+ entity certificate, but it can be a CA certificate.) A
+ pathLenConstraint of zero indicates that only one more certificate
+ may follow in a valid certification path. Where it appears, the
+ pathLenConstraint field MUST be greater than or equal to zero. Where
+ pathLenConstraint does not appear, no limit is imposed.
+
+ This extension MUST appear as a critical extension in all CA
+ certificates that contain public keys used to validate digital
+ signatures on certificates. This extension MAY appear as a critical
+ or non-critical extension in CA certificates that contain public keys
+ used exclusively for purposes other than validating digital
+ signatures on certificates. Such CA certificates include ones that
+ contain public keys used exclusively for validating digital
+ signatures on CRLs and ones that contain key management public keys
+ used with certificate enrollment protocols. This extension MAY
+ appear as a critical or non-critical extension in end entity
+ certificates.
+
+ CAs MUST NOT include the pathLenConstraint field unless the cA
+ boolean is asserted and the key usage extension asserts the
+ keyCertSign bit.
+
+ id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 }
+
+ BasicConstraints ::= SEQUENCE {
+ cA BOOLEAN DEFAULT FALSE,
+ pathLenConstraint INTEGER (0..MAX) OPTIONAL }
+
+4.2.1.11 Name Constraints
+
+ The name constraints extension, which MUST be used only in a CA
+ certificate, indicates a name space within which all subject names in
+ subsequent certificates in a certification path MUST be located.
+ Restrictions apply to the subject distinguished name and apply to
+ subject alternative names. Restrictions apply only when the
+
+
+
+Housley, et. al. Standards Track [Page 37]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ specified name form is present. If no name of the type is in the
+ certificate, the certificate is acceptable.
+
+ Name constraints are not applied to certificates whose issuer and
+ subject are identical (unless the certificate is the final
+ certificate in the path). (This could prevent CAs that use name
+ constraints from employing self-issued certificates to implement key
+ rollover.)
+
+ Restrictions are defined in terms of permitted or excluded name
+ subtrees. Any name matching a restriction in the excludedSubtrees
+ field is invalid regardless of information appearing in the
+ permittedSubtrees. This extension MUST be critical.
+
+ Within this profile, the minimum and maximum fields are not used with
+ any name forms, thus minimum MUST be zero, and maximum MUST be
+ absent.
+
+ For URIs, the constraint applies to the host part of the name. The
+ constraint MAY specify a host or a domain. Examples would be
+ "foo.bar.com"; and ".xyz.com". When the the constraint begins with
+ a period, it MAY be expanded with one or more subdomains. That is,
+ the constraint ".xyz.com" is satisfied by both abc.xyz.com and
+ abc.def.xyz.com. However, the constraint ".xyz.com" is not satisfied
+ by "xyz.com". When the constraint does not begin with a period, it
+ specifies a host.
+
+ A name constraint for Internet mail addresses MAY specify a
+ particular mailbox, all addresses at a particular host, or all
+ mailboxes in a domain. To indicate a particular mailbox, the
+ constraint is the complete mail address. For example, "root@xyz.com"
+ indicates the root mailbox on the host "xyz.com". To indicate all
+ Internet mail addresses on a particular host, the constraint is
+ specified as the host name. For example, the constraint "xyz.com" is
+ satisfied by any mail address at the host "xyz.com". To specify any
+ address within a domain, the constraint is specified with a leading
+ period (as with URIs). For example, ".xyz.com" indicates all the
+ Internet mail addresses in the domain "xyz.com", but not Internet
+ mail addresses on the host "xyz.com".
+
+ DNS name restrictions are expressed as foo.bar.com. Any DNS name
+ that can be constructed by simply adding to the left hand side of the
+ name satisfies the name constraint. For example, www.foo.bar.com
+ would satisfy the constraint but foo1.bar.com would not.
+
+ Legacy implementations exist where an RFC 822 name is embedded in the
+ subject distinguished name in an attribute of type EmailAddress
+ (section 4.1.2.6). When rfc822 names are constrained, but the
+
+
+
+Housley, et. al. Standards Track [Page 38]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ certificate does not include a subject alternative name, the rfc822
+ name constraint MUST be applied to the attribute of type EmailAddress
+ in the subject distinguished name. The ASN.1 syntax for EmailAddress
+ and the corresponding OID are supplied in Appendix A.
+
+ Restrictions of the form directoryName MUST be applied to the subject
+ field in the certificate and to the subjectAltName extensions of type
+ directoryName. Restrictions of the form x400Address MUST be applied
+ to subjectAltName extensions of type x400Address.
+
+ When applying restrictions of the form directoryName, an
+ implementation MUST compare DN attributes. At a minimum,
+ implementations MUST perform the DN comparison rules specified in
+ Section 4.1.2.4. CAs issuing certificates with a restriction of the
+ form directoryName SHOULD NOT rely on implementation of the full ISO
+ DN name comparison algorithm. This implies name restrictions MUST be
+ stated identically to the encoding used in the subject field or
+ subjectAltName extension.
+
+ The syntax of iPAddress MUST be as described in section 4.2.1.7 with
+ the following additions specifically for Name Constraints. For IPv4
+ addresses, the ipAddress field of generalName MUST contain eight (8)
+ octets, encoded in the style of RFC 1519 (CIDR) to represent an
+ address range [RFC 1519]. For IPv6 addresses, the ipAddress field
+ MUST contain 32 octets similarly encoded. For example, a name
+ constraint for "class C" subnet 10.9.8.0 is represented as the octets
+ 0A 09 08 00 FF FF FF 00, representing the CIDR notation
+ 10.9.8.0/255.255.255.0.
+
+ The syntax and semantics for name constraints for otherName,
+ ediPartyName, and registeredID are not defined by this specification.
+
+ id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 }
+
+ NameConstraints ::= SEQUENCE {
+ permittedSubtrees [0] GeneralSubtrees OPTIONAL,
+ excludedSubtrees [1] GeneralSubtrees OPTIONAL }
+
+ GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
+
+ GeneralSubtree ::= SEQUENCE {
+ base GeneralName,
+ minimum [0] BaseDistance DEFAULT 0,
+ maximum [1] BaseDistance OPTIONAL }
+
+ BaseDistance ::= INTEGER (0..MAX)
+
+
+
+
+
+Housley, et. al. Standards Track [Page 39]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+4.2.1.12 Policy Constraints
+
+ The policy constraints extension can be used in certificates issued
+ to CAs. The policy constraints extension constrains path validation
+ in two ways. It can be used to prohibit policy mapping or require
+ that each certificate in a path contain an acceptable policy
+ identifier.
+
+ If the inhibitPolicyMapping field is present, the value indicates the
+ number of additional certificates that may appear in the path before
+ policy mapping is no longer permitted. For example, a value of one
+ indicates that policy mapping may be processed in certificates issued
+ by the subject of this certificate, but not in additional
+ certificates in the path.
+
+ If the requireExplicitPolicy field is present, the value of
+ requireExplicitPolicy indicates the number of additional certificates
+ that may appear in the path before an explicit policy is required for
+ the entire path. When an explicit policy is required, it is
+ necessary for all certificates in the path to contain an acceptable
+ policy identifier in the certificate policies extension. An
+ acceptable policy identifier is the identifier of a policy required
+ by the user of the certification path or the identifier of a policy
+ which has been declared equivalent through policy mapping.
+
+ Conforming CAs MUST NOT issue certificates where policy constraints
+ is a empty sequence. That is, at least one of the
+ inhibitPolicyMapping field or the requireExplicitPolicy field MUST be
+ present. The behavior of clients that encounter a empty policy
+ constraints field is not addressed in this profile.
+
+ This extension MAY be critical or non-critical.
+
+ id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 }
+
+ PolicyConstraints ::= SEQUENCE {
+ requireExplicitPolicy [0] SkipCerts OPTIONAL,
+ inhibitPolicyMapping [1] SkipCerts OPTIONAL }
+
+ SkipCerts ::= INTEGER (0..MAX)
+
+4.2.1.13 Extended Key Usage
+
+ This extension indicates one or more purposes for which the certified
+ public key may be used, in addition to or in place of the basic
+ purposes indicated in the key usage extension. In general, this
+ extension will appear only in end entity certificates. This
+ extension is defined as follows:
+
+
+
+Housley, et. al. Standards Track [Page 40]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 }
+
+ ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
+
+ KeyPurposeId ::= OBJECT IDENTIFIER
+
+ Key purposes may be defined by any organization with a need. Object
+ identifiers used to identify key purposes MUST be assigned in
+ accordance with IANA or ITU-T Recommendation X.660 [X.660].
+
+ This extension MAY, at the option of the certificate issuer, be
+ either critical or non-critical.
+
+ If the extension is present, then the certificate MUST only be used
+ for one of the purposes indicated. If multiple purposes are
+ indicated the application need not recognize all purposes indicated,
+ as long as the intended purpose is present. Certificate using
+ applications MAY require that a particular purpose be indicated in
+ order for the certificate to be acceptable to that application.
+
+ If a CA includes extended key usages to satisfy such applications,
+ but does not wish to restrict usages of the key, the CA can include
+ the special keyPurposeID anyExtendedKeyUsage. If the
+ anyExtendedKeyUsage keyPurposeID is present, the extension SHOULD NOT
+ be critical.
+
+ If a certificate contains both a key usage extension and an extended
+ key usage extension, then both extensions MUST be processed
+ independently and the certificate MUST only be used for a purpose
+ consistent with both extensions. If there is no purpose consistent
+ with both extensions, then the certificate MUST NOT be used for any
+ purpose.
+
+ The following key usage purposes are defined:
+
+ anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 }
+
+ id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
+
+ id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
+ -- TLS WWW server authentication
+ -- Key usage bits that may be consistent: digitalSignature,
+ -- keyEncipherment or keyAgreement
+
+ id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 }
+ -- TLS WWW client authentication
+ -- Key usage bits that may be consistent: digitalSignature
+ -- and/or keyAgreement
+
+
+
+Housley, et. al. Standards Track [Page 41]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 }
+ -- Signing of downloadable executable code
+ -- Key usage bits that may be consistent: digitalSignature
+
+ id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 }
+ -- E-mail protection
+ -- Key usage bits that may be consistent: digitalSignature,
+ -- nonRepudiation, and/or (keyEncipherment or keyAgreement)
+
+ id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }
+ -- Binding the hash of an object to a time
+ -- Key usage bits that may be consistent: digitalSignature
+ -- and/or nonRepudiation
+
+ id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }
+ -- Signing OCSP responses
+ -- Key usage bits that may be consistent: digitalSignature
+ -- and/or nonRepudiation
+
+4.2.1.14 CRL Distribution Points
+
+ The CRL distribution points extension identifies how CRL information
+ is obtained. The extension SHOULD be non-critical, but this profile
+ RECOMMENDS support for this extension by CAs and applications.
+ Further discussion of CRL management is contained in section 5.
+
+ The cRLDistributionPoints extension is a SEQUENCE of
+ DistributionPoint. A DistributionPoint consists of three fields,
+ each of which is optional: distributionPoint, reasons, and cRLIssuer.
+ While each of these fields is optional, a DistributionPoint MUST NOT
+ consist of only the reasons field; either distributionPoint or
+ cRLIssuer MUST be present. If the certificate issuer is not the CRL
+ issuer, then the cRLIssuer field MUST be present and contain the Name
+ of the CRL issuer. If the certificate issuer is also the CRL issuer,
+ then the cRLIssuer field MUST be omitted and the distributionPoint
+ field MUST be present. If the distributionPoint field is omitted,
+ cRLIssuer MUST be present and include a Name corresponding to an
+ X.500 or LDAP directory entry where the CRL is located.
+
+ When the distributionPoint field is present, it contains either a
+ SEQUENCE of general names or a single value, nameRelativeToCRLIssuer.
+ If the cRLDistributionPoints extension contains a general name of
+ type URI, the following semantics MUST be assumed: the URI is a
+ pointer to the current CRL for the associated 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 other values are
+ not defined by this specification.
+
+
+
+
+Housley, et. al. Standards Track [Page 42]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ If the DistributionPointName contains multiple values, each name
+ describes a different mechanism to obtain the same CRL. For example,
+ the same CRL could be available for retrieval through both LDAP and
+ HTTP.
+
+ If the DistributionPointName contains the single value
+ nameRelativeToCRLIssuer, the value provides a distinguished name
+ fragment. The fragment is appended to the X.500 distinguished name
+ of the CRL issuer to obtain the distribution point name. If the
+ cRLIssuer field in the DistributionPoint is present, then the name
+ fragment is appended to the distinguished name that it contains;
+ otherwise, the name fragment is appended to the certificate issuer
+ distinguished name. The DistributionPointName MUST NOT use the
+ nameRealtiveToCRLIssuer alternative when cRLIssuer contains more than
+ one distinguished name.
+
+ If the DistributionPoint omits the reasons field, the CRL MUST
+ include revocation information for all reasons.
+
+ The cRLIssuer identifies the entity who signs and issues the CRL. If
+ present, the cRLIssuer MUST contain at least one an X.500
+ distinguished name (DN), and MAY also contain other name forms.
+ Since the cRLIssuer is compared to the CRL issuer name, the X.501
+ type Name MUST follow the encoding rules for the issuer name field in
+ the certificate (section 4.1.2.4).
+
+ id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 }
+
+ CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
+
+ DistributionPoint ::= SEQUENCE {
+ distributionPoint [0] DistributionPointName OPTIONAL,
+ reasons [1] ReasonFlags OPTIONAL,
+ cRLIssuer [2] GeneralNames OPTIONAL }
+
+ DistributionPointName ::= CHOICE {
+ fullName [0] GeneralNames,
+ nameRelativeToCRLIssuer [1] RelativeDistinguishedName }
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 43]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ ReasonFlags ::= BIT STRING {
+ unused (0),
+ keyCompromise (1),
+ cACompromise (2),
+ affiliationChanged (3),
+ superseded (4),
+ cessationOfOperation (5),
+ certificateHold (6),
+ privilegeWithdrawn (7),
+ aACompromise (8) }
+
+4.2.1.15 Inhibit Any-Policy
+
+ The inhibit any-policy extension can be used in certificates issued
+ to CAs. The inhibit any-policy indicates that the special anyPolicy
+ OID, with the value { 2 5 29 32 0 }, is not considered an explicit
+ match for other certificate policies. The value indicates the number
+ of additional certificates that may appear in the path before
+ anyPolicy is no longer permitted. For example, a value of one
+ indicates that anyPolicy may be processed in certificates issued by
+ the subject of this certificate, but not in additional certificates
+ in the path.
+
+ This extension MUST be critical.
+
+ id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 }
+
+ InhibitAnyPolicy ::= SkipCerts
+
+ SkipCerts ::= INTEGER (0..MAX)
+
+4.2.1.16 Freshest CRL (a.k.a. Delta CRL Distribution Point)
+
+ The freshest CRL extension identifies how delta CRL information is
+ obtained. The extension MUST be non-critical. Further discussion of
+ CRL management is contained in section 5.
+
+ The same syntax is used for this extension and the
+ cRLDistributionPoints extension, and is described in section
+ 4.2.1.14. The same conventions apply to both extensions.
+
+ id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 }
+
+ FreshestCRL ::= CRLDistributionPoints
+
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 44]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+4.2.2 Private Internet Extensions
+
+ This section defines two extensions for use in the Internet Public
+ Key Infrastructure. These extensions may be used to direct
+ applications to on-line information about the issuing CA or the
+ subject. As the information may be available in multiple forms, each
+ extension is a sequence of IA5String values, each of which represents
+ a URI. The URI implicitly specifies the location and format of the
+ information and the method for obtaining the information.
+
+ An object identifier is defined for the private extension. The
+ object identifier associated with the private extension is defined
+ under the arc id-pe within the arc id-pkix. Any future extensions
+ defined for the Internet PKI are also expected to be defined under
+ the arc id-pe.
+
+ id-pkix OBJECT IDENTIFIER ::=
+ { iso(1) identified-organization(3) dod(6) internet(1)
+ security(5) mechanisms(5) pkix(7) }
+
+ id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
+
+4.2.2.1 Authority Information Access
+
+ The authority information access extension indicates how to access CA
+ information and services for the issuer of the certificate in which
+ the extension appears. Information and services may include on-line
+ validation services and CA policy data. (The location of CRLs is not
+ specified in this extension; that information is provided by the
+ cRLDistributionPoints extension.) This extension may be included in
+ end entity or CA certificates, and it MUST be non-critical.
+
+ id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }
+
+ AuthorityInfoAccessSyntax ::=
+ SEQUENCE SIZE (1..MAX) OF AccessDescription
+
+ AccessDescription ::= SEQUENCE {
+ accessMethod OBJECT IDENTIFIER,
+ accessLocation GeneralName }
+
+ id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
+
+ id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }
+
+ id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }
+
+
+
+
+
+Housley, et. al. Standards Track [Page 45]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ Each entry in the sequence AuthorityInfoAccessSyntax describes the
+ format and location of additional information provided by the CA that
+ issued the certificate in which this extension appears. The type and
+ format of the information is specified by the accessMethod field; the
+ accessLocation field specifies the location of the information. The
+ retrieval mechanism may be implied by the accessMethod or specified
+ by accessLocation.
+
+ This profile defines two accessMethod OIDs: id-ad-caIssuers and
+ id-ad-ocsp.
+
+ The id-ad-caIssuers OID is used when the additional information lists
+ CAs that have issued certificates superior to the CA that issued the
+ certificate containing this extension. The referenced CA issuers
+ description is intended to aid certificate users in the selection of
+ a certification path that terminates at a point trusted by the
+ certificate user.
+
+ When id-ad-caIssuers appears as accessMethod, the accessLocation
+ field describes the referenced description server and the access
+ protocol to obtain the referenced description. The accessLocation
+ field is defined as a GeneralName, which can take several forms.
+ Where the information is available via http, ftp, or ldap,
+ accessLocation MUST be a uniformResourceIdentifier. Where the
+ information is available via the Directory Access Protocol (DAP),
+ accessLocation MUST be a directoryName. The entry for that
+ directoryName contains CA certificates in the crossCertificatePair
+ attribute. When the information is available via electronic mail,
+ accessLocation MUST be an rfc822Name. The semantics of other
+ id-ad-caIssuers accessLocation name forms are not defined.
+
+ The id-ad-ocsp OID is used when revocation information for the
+ certificate containing this extension is available using the Online
+ Certificate Status Protocol (OCSP) [RFC 2560].
+
+ When id-ad-ocsp appears as accessMethod, the accessLocation field is
+ the location of the OCSP responder, using the conventions defined in
+ [RFC 2560].
+
+ Additional access descriptors may be defined in other PKIX
+ specifications.
+
+4.2.2.2 Subject Information Access
+
+ The subject information access extension indicates how to access
+ information and services for the subject of the certificate in which
+ the extension appears. When the subject is a CA, information and
+ services may include certificate validation services and CA policy
+
+
+
+Housley, et. al. Standards Track [Page 46]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ data. When the subject is an end entity, the information describes
+ the type of services offered and how to access them. In this case,
+ the contents of this extension are defined in the protocol
+ specifications for the suported services. This extension may be
+ included in subject or CA certificates, and it MUST be non-critical.
+
+ id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 }
+
+ SubjectInfoAccessSyntax ::=
+ SEQUENCE SIZE (1..MAX) OF AccessDescription
+
+ AccessDescription ::= SEQUENCE {
+ accessMethod OBJECT IDENTIFIER,
+ accessLocation GeneralName }
+
+ Each entry in the sequence SubjectInfoAccessSyntax describes the
+ format and location of additional information provided by the subject
+ of the certificate in which this extension appears. The type and
+ format of the information is specified by the accessMethod field; the
+ accessLocation field specifies the location of the information. The
+ retrieval mechanism may be implied by the accessMethod or specified
+ by accessLocation.
+
+ This profile defines one access method to be used when the subject is
+ 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
+ the protocol specifications for other services.
+
+ 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
+ accessLocation field is defined as a GeneralName, which can take
+ several forms. Where the information is available via http, ftp, or
+ ldap, accessLocation MUST be a uniformResourceIdentifier. Where the
+ information is available via the directory access protocol (dap),
+ accessLocation MUST be a directoryName. When the information is
+ available via electronic mail, accessLocation MUST be an rfc822Name.
+ The semantics of other name forms of of accessLocation (when
+ accessMethod is id-ad-caRepository) are not defined by this
+ specification.
+
+ The id-ad-timeStamping OID is used when the subject offers
+ timestamping services using the Time Stamp Protocol defined in
+ [PKIXTSA]. Where the timestamping services are available via http or
+ ftp, accessLocation MUST be a uniformResourceIdentifier. Where the
+ timestamping services are available via electronic mail,
+ accessLocation MUST be an rfc822Name. Where timestamping services
+
+
+
+
+
+Housley, et. al. Standards Track [Page 47]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ are available using TCP/IP, the dNSName or ipAddress name forms may
+ be used. The semantics of other name forms of accessLocation (when
+ accessMethod is id-ad-timeStamping) are not defined by this
+ specification.
+
+ Additional access descriptors may be defined in other PKIX
+ specifications.
+
+ id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
+
+ id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 }
+
+ id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 }
+
+5 CRL and CRL Extensions Profile
+
+ As discussed above, one goal of this X.509 v2 CRL profile is to
+ foster the creation of an interoperable and reusable Internet PKI.
+ To achieve this goal, guidelines for the use of extensions are
+ specified, and some assumptions are made about the nature of
+ information included in the CRL.
+
+ CRLs may be used in a wide range of applications and environments
+ covering a broad spectrum of interoperability goals and an even
+ broader spectrum of operational and assurance requirements. This
+ profile establishes a common baseline for generic applications
+ requiring broad interoperability. The profile defines a set of
+ information that can be expected in every CRL. Also, the profile
+ defines common locations within the CRL for frequently used
+ attributes as well as common representations for these attributes.
+
+ CRL issuers issue CRLs. In general, the CRL issuer is the CA. CAs
+ publish CRLs to provide status information about the certificates
+ they issued. However, a CA may delegate this responsibility to
+ another trusted authority. Whenever the CRL issuer is not the CA
+ that issued the certificates, the CRL is referred to as an indirect
+ CRL.
+
+ Each CRL has a particular scope. The CRL scope is the set of
+ certificates that could appear on a given CRL. For example, the
+ scope could be "all certificates issued by CA X", "all CA
+ certificates issued by CA X", "all certificates issued by CA X that
+ have been revoked for reasons of key compromise and CA compromise",
+ or could be a set of certificates based on arbitrary local
+ information, such as "all certificates issued to the NIST employees
+ located in Boulder".
+
+
+
+
+
+Housley, et. al. Standards Track [Page 48]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ A complete CRL lists all unexpired certificates, within its scope,
+ that have been revoked for one of the revocation reasons covered by
+ the CRL scope. The CRL issuer MAY also generate delta CRLs. A delta
+ CRL only lists those certificates, within its scope, whose revocation
+ status has changed since the issuance of a referenced complete CRL.
+ The referenced complete CRL is referred to as a base CRL. The scope
+ of a delta CRL MUST be the same as the base CRL that it references.
+
+ This profile does not define any private Internet CRL extensions or
+ CRL entry extensions.
+
+ Environments with additional or special purpose requirements may
+ build on this profile or may replace it.
+
+ Conforming CAs are not required to issue CRLs if other revocation or
+ certificate status mechanisms are provided. When CRLs are issued,
+ the CRLs MUST be version 2 CRLs, include the date by which the next
+ CRL will be issued in the nextUpdate field (section 5.1.2.5), include
+ the CRL number extension (section 5.2.3), and include the authority
+ key identifier extension (section 5.2.1). Conforming applications
+ that support CRLs are REQUIRED to process both version 1 and version
+ 2 complete CRLs that provide revocation information for all
+ certificates issued by one CA. Conforming applications are NOT
+ REQUIRED to support processing of delta CRLs, indirect CRLs, or CRLs
+ with a scope other than all certificates issued by one CA.
+
+5.1 CRL Fields
+
+ The X.509 v2 CRL syntax is as follows. For signature calculation,
+ the data that is to be signed is ASN.1 DER encoded. ASN.1 DER
+ encoding is a tag, length, value encoding system for each element.
+
+ CertificateList ::= SEQUENCE {
+ tbsCertList TBSCertList,
+ signatureAlgorithm AlgorithmIdentifier,
+ signatureValue BIT STRING }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 49]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ TBSCertList ::= SEQUENCE {
+ version Version OPTIONAL,
+ -- if present, MUST be v2
+ signature AlgorithmIdentifier,
+ issuer Name,
+ thisUpdate Time,
+ nextUpdate Time OPTIONAL,
+ revokedCertificates SEQUENCE OF SEQUENCE {
+ userCertificate CertificateSerialNumber,
+ revocationDate Time,
+ crlEntryExtensions Extensions OPTIONAL
+ -- if present, MUST be v2
+ } OPTIONAL,
+ crlExtensions [0] EXPLICIT Extensions OPTIONAL
+ -- if present, MUST be v2
+ }
+
+ -- Version, Time, CertificateSerialNumber, and Extensions
+ -- are all defined in the ASN.1 in section 4.1
+
+ -- AlgorithmIdentifier is defined in section 4.1.1.2
+
+ The following items describe the use of the X.509 v2 CRL in the
+ Internet PKI.
+
+5.1.1 CertificateList Fields
+
+ The CertificateList is a SEQUENCE of three required fields. The
+ fields are described in detail in the following subsections.
+
+5.1.1.1 tbsCertList
+
+ The first field in the sequence is the tbsCertList. This field is
+ itself a sequence containing the name of the issuer, issue date,
+ issue date of the next list, the optional list of revoked
+ certificates, and optional CRL extensions. When there are no revoked
+ certificates, the revoked certificates list is absent. When one or
+ more certificates are revoked, each entry on the revoked certificate
+ list is defined by a sequence of user certificate serial number,
+ revocation date, and optional CRL entry extensions.
+
+5.1.1.2 signatureAlgorithm
+
+ The signatureAlgorithm field contains the algorithm identifier for
+ the algorithm used by the CRL issuer to sign the CertificateList.
+ The field is of type AlgorithmIdentifier, which is defined in section
+ 4.1.1.2. [PKIXALGS] lists the supported algorithms for this
+ specification, but other signature algorithms MAY also be supported.
+
+
+
+Housley, et. al. Standards Track [Page 50]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ This field MUST contain the same algorithm identifier as the
+ signature field in the sequence tbsCertList (section 5.1.2.2).
+
+5.1.1.3 signatureValue
+
+ The signatureValue field contains a digital signature computed upon
+ 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 encoded as a BIT STRING and included in the CRL signatureValue
+ field. The details of this process are specified for each of the
+ supported algorithms in [PKIXALGS].
+
+ CAs that are also CRL issuers MAY use one private key to digitally
+ sign certificates and CRLs, or 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 (section 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 (section 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"
+
+ The certificate list to be signed, or TBSCertList, is a sequence of
+ required and optional fields. The required fields identify 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 CRL issuer will issue
+ the next CRL.
+
+ Optional fields include lists of revoked certificates and CRL
+ extensions. The revoked certificate list is optional to support the
+ case where a CA has not revoked any unexpired certificates that it
+
+
+
+
+
+Housley, et. al. Standards Track [Page 51]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ has issued. The profile requires conforming CRL issuers to use the
+ CRL number and authority key identifier CRL extensions in all CRLs
+ issued.
+
+5.1.2.1 Version
+
+ This optional field describes the version of the encoded CRL. When
+ extensions are used, as required by this profile, this field MUST be
+ present and MUST specify version 2 (the integer value is 1).
+
+5.1.2.2 Signature
+
+ This field contains the algorithm identifier for the algorithm used
+ to sign the CRL. [PKIXALGS] lists OIDs for the most popular
+ signature algorithms used in the Internet PKI.
+
+ This field MUST contain the same algorithm identifier as the
+ signatureAlgorithm field in the sequence CertificateList (section
+ 5.1.1.2).
+
+5.1.2.3 Issuer Name
+
+ The issuer name identifies the entity who has signed and issued the
+ CRL. The issuer identity is carried in the issuer name field.
+ Alternative name forms may also appear in the issuerAltName extension
+ (section 5.2.2). The issuer name field MUST contain an X.500
+ distinguished name (DN). The issuer name field is defined as the
+ X.501 type Name, and MUST follow the encoding rules for the issuer
+ name field in the certificate (section 4.1.2.4).
+
+5.1.2.4 This Update
+
+ This field indicates the issue date of this CRL. ThisUpdate may be
+ encoded as UTCTime or GeneralizedTime.
+
+ CRL issuers conforming to this profile MUST encode thisUpdate as
+ UTCTime for dates through the year 2049. CRL issuers conforming to
+ this profile MUST encode thisUpdate as GeneralizedTime for dates in
+ the year 2050 or later.
+
+ Where encoded as UTCTime, thisUpdate MUST be specified and
+ interpreted as defined in section 4.1.2.5.1. Where encoded as
+ GeneralizedTime, thisUpdate MUST be specified and interpreted as
+ defined in section 4.1.2.5.2.
+
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 52]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+5.1.2.5 Next Update
+
+ 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
+ not be issued any later than the indicated date. CRL issuers SHOULD
+ issue CRLs with a nextUpdate time equal to or later than all previous
+ CRLs. nextUpdate may be encoded as UTCTime or GeneralizedTime.
+
+ This profile requires inclusion of nextUpdate in all CRLs issued by
+ conforming CRL issuers. Note that the ASN.1 syntax of TBSCertList
+ describes this field as OPTIONAL, which is consistent with the ASN.1
+ structure defined in [X.509]. The behavior of clients processing
+ CRLs which omit nextUpdate is not specified by this profile.
+
+ CRL issuers conforming to this profile MUST encode nextUpdate as
+ UTCTime for dates through the year 2049. CRL issuers conforming to
+ this profile MUST encode nextUpdate as GeneralizedTime for dates in
+ the year 2050 or later.
+
+ Where encoded as UTCTime, nextUpdate MUST be specified and
+ interpreted as defined in section 4.1.2.5.1. Where encoded as
+ GeneralizedTime, nextUpdate MUST be specified and interpreted as
+ defined in section 4.1.2.5.2.
+
+5.1.2.6 Revoked Certificates
+
+ When there are no revoked certificates, the revoked certificates list
+ MUST be absent. Otherwise, revoked certificates are listed by their
+ serial numbers. Certificates revoked by the CA are uniquely
+ identified by the certificate serial number. The date on which the
+ revocation occurred is specified. The time for revocationDate MUST
+ be expressed as described in section 5.1.2.4. Additional information
+ may be supplied in CRL entry extensions; CRL entry extensions are
+ discussed in section 5.3.
+
+5.1.2.7 Extensions
+
+ This field may only appear if the version is 2 (section 5.1.2.1). If
+ present, this field is a sequence of one or more CRL extensions. CRL
+ extensions are discussed in section 5.2.
+
+5.2 CRL Extensions
+
+ The extensions defined by ANSI X9, ISO/IEC, and ITU-T for X.509 v2
+ CRLs [X.509] [X9.55] provide methods for associating additional
+ attributes with CRLs. The X.509 v2 CRL format also allows
+ communities to define private extensions to carry information unique
+ to those communities. Each extension in a CRL may be designated as
+
+
+
+Housley, et. al. Standards Track [Page 53]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ critical or non-critical. A CRL validation MUST fail if it
+ encounters a critical extension which it does not know how to
+ process. However, an unrecognized non-critical extension may be
+ ignored. The following subsections present those extensions used
+ within Internet CRLs. Communities may elect to include extensions in
+ CRLs which are not defined in this specification. However, caution
+ should be exercised in adopting any critical extensions in CRLs which
+ might be used in a general context.
+
+ Conforming CRL issuers are REQUIRED to include the authority key
+ identifier (section 5.2.1) and the CRL number (section 5.2.3)
+ extensions in all CRLs issued.
+
+5.2.1 Authority Key Identifier
+
+ The authority key identifier extension provides a means of
+ identifying the public key corresponding to the private key used to
+ sign a CRL. The identification can be based on either the key
+ identifier (the subject key identifier in the CRL signer's
+ certificate) or on the issuer name and serial number. This extension
+ is especially useful where an issuer has more than one signing key,
+ either due to multiple concurrent key pairs or due to changeover.
+
+ Conforming CRL issuers MUST use the key identifier method, and MUST
+ include this extension in all CRLs issued.
+
+ The syntax for this CRL extension is defined in section 4.2.1.1.
+
+5.2.2 Issuer Alternative Name
+
+ The issuer alternative names extension allows additional identities
+ to be associated with the issuer of the CRL. Defined options include
+ an rfc822 name (electronic mail address), a DNS name, an IP address,
+ and a URI. Multiple instances of a name and multiple name forms may
+ be included. Whenever such identities are used, the issuer
+ alternative name extension MUST be used; however, a DNS name MAY be
+ represented in the issuer field using the domainComponent attribute
+ as described in section 4.1.2.4.
+
+ The issuerAltName extension SHOULD NOT be marked critical.
+
+ The OID and syntax for this CRL extension are defined in section
+ 4.2.1.8.
+
+
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 54]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+5.2.3 CRL Number
+
+ The CRL number is a non-critical CRL extension which conveys a
+ monotonically increasing sequence number for a given CRL scope and
+ CRL issuer. This extension allows users to easily determine when a
+ particular CRL supersedes another CRL. CRL numbers also support the
+ identification of complementary complete CRLs and delta CRLs. CRL
+ issuers conforming to this profile MUST include this extension in all
+ CRLs.
+
+ If a CRL issuer generates delta CRLs in addition to complete CRLs for
+ a given scope, the complete CRLs and delta CRLs MUST share one
+ numbering sequence. If a delta CRL and a complete CRL that cover the
+ same scope are issued at the same time, they MUST have the same CRL
+ number and provide the same revocation information. That is, the
+ combination of the delta CRL and an acceptable complete CRL MUST
+ provide the same revocation information as the simultaneously issued
+ complete CRL.
+
+ If a CRL issuer generates two CRLs (two complete CRLs, two delta
+ CRLs, or a complete CRL and a delta CRL) for the same scope at
+ different times, the two CRLs MUST NOT have the same CRL number.
+ That is, if the this update field (section 5.1.2.4) in the two CRLs
+ are not identical, the CRL numbers MUST be different.
+
+ Given the requirements above, CRL numbers can be expected to contain
+ long integers. CRL verifiers MUST be able to handle CRLNumber values
+ up to 20 octets. Conformant CRL issuers MUST NOT use CRLNumber
+ values longer than 20 octets.
+
+ id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }
+
+ CRLNumber ::= INTEGER (0..MAX)
+
+5.2.4 Delta CRL Indicator
+
+ The delta CRL indicator is a critical CRL extension that identifies a
+ CRL as being a delta CRL. Delta CRLs contain updates to revocation
+ information previously distributed, rather than all the information
+ that would appear in a complete CRL. The use of delta CRLs can
+ significantly reduce network load and processing time in some
+ environments. Delta CRLs are generally smaller than the CRLs they
+ update, so applications that obtain delta CRLs consume less network
+ bandwidth than applications that obtain the corresponding complete
+ CRLs. Applications which store revocation information in a format
+ other than the CRL structure can add new revocation information to
+ the local database without reprocessing information.
+
+
+
+
+Housley, et. al. Standards Track [Page 55]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ The delta CRL indicator extension contains the single value of type
+ BaseCRLNumber. The CRL number identifies the CRL, complete for a
+ given scope, that was used as the starting point in the generation of
+ this delta CRL. A conforming CRL issuer MUST publish the referenced
+ base CRL as a complete CRL. The delta CRL contains all updates to
+ the revocation status for that same scope. The combination of a
+ delta CRL plus the referenced base CRL is equivalent to a complete
+ CRL, for the applicable scope, at the time of publication of the
+ delta CRL.
+
+ When a conforming CRL issuer generates a delta CRL, the delta CRL
+ MUST include a critical delta CRL indicator extension.
+
+ When a delta CRL is issued, it MUST cover the same set of reasons and
+ the same set of certificates that were covered by the base CRL it
+ references. That is, the scope of the delta CRL MUST be the same as
+ the scope of the complete CRL referenced as the base. The referenced
+ base CRL and the delta CRL MUST omit the issuing distribution point
+ extension or contain identical issuing distribution point extensions.
+ Further, the CRL issuer MUST use the same private key to sign the
+ delta CRL and any complete CRL that it can be used to update.
+
+ An application that supports delta CRLs can construct a CRL that is
+ complete for a given scope by combining a delta CRL for that scope
+ with either an issued CRL that is complete for that scope or a
+ locally constructed CRL that is complete for that scope.
+
+ When a delta CRL is combined with a complete CRL or a locally
+ constructed CRL, the resulting locally constructed CRL has the CRL
+ number specified in the CRL number extension found in the delta CRL
+ used in its construction. In addition, the resulting locally
+ constructed CRL has the thisUpdate and nextUpdate times specified in
+ the corresponding fields of the delta CRL used in its construction.
+ In addition, the locally constructed CRL inherits the issuing
+ distribution point from the delta CRL.
+
+ A complete CRL and a delta CRL MAY be combined if the following four
+ conditions are satisfied:
+
+ (a) The complete CRL and delta CRL have the same issuer.
+
+ (b) The complete CRL and delta CRL have the same scope. The two
+ CRLs have the same scope if either of the following conditions are
+ met:
+
+ (1) The issuingDistributionPoint extension is omitted from
+ both the complete CRL and the delta CRL.
+
+
+
+
+Housley, et. al. Standards Track [Page 56]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ (2) The issuingDistributionPoint extension is present in both
+ the complete CRL and the delta CRL, and the values for each of
+ the fields in the extensions are the same in both CRLs.
+
+ (c) The CRL number of the complete CRL is equal to or greater
+ than the BaseCRLNumber specified in the delta CRL. That is, the
+ complete CRL contains (at a minimum) all the revocation
+ information held by the referenced base CRL.
+
+ (d) The CRL number of the complete CRL is less than the CRL
+ number of the delta CRL. That is, the delta CRL follows the
+ complete CRL in the numbering sequence.
+
+ CRL issuers MUST ensure that the combination of a delta CRL and any
+ appropriate complete CRL accurately reflects the current revocation
+ status. The CRL issuer MUST include an entry in the delta CRL for
+ each certificate within the scope of the delta CRL whose status has
+ changed since the generation of the referenced base CRL:
+
+ (a) If the certificate is revoked for a reason included in the
+ scope of the CRL, list the certificate as revoked.
+
+ (b) If the certificate is valid and was listed on the referenced
+ base CRL or any subsequent CRL with reason code certificateHold,
+ and the reason code certificateHold is included in the scope of
+ the CRL, list the certificate with the reason code removeFromCRL.
+
+ (c) If the certificate is revoked for a reason outside the scope
+ of the CRL, but the certificate was listed on the referenced base
+ CRL or any subsequent CRL with a reason code included in the scope
+ of this CRL, list the certificate as revoked but omit the reason
+ code.
+
+ (d) If the certificate is revoked for a reason outside the scope
+ of the CRL and the certificate was neither listed on the
+ referenced base CRL nor any subsequent CRL with a reason code
+ included in the scope of this CRL, do not list the certificate on
+ this CRL.
+
+ The status of a certificate is considered to have changed if it is
+ revoked, placed on hold, released from hold, or if its revocation
+ reason changes.
+
+ It is appropriate to list a certificate with reason code
+ removeFromCRL on a delta CRL even if the certificate was not on hold
+ in the referenced base CRL. If the certificate was placed on hold in
+
+
+
+
+
+Housley, et. al. Standards Track [Page 57]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ any CRL issued after the base but before this delta CRL and then
+ released from hold, it MUST be listed on the delta CRL with
+ revocation reason removeFromCRL.
+
+ A CRL issuer MAY optionally list a certificate on a delta CRL with
+ reason code removeFromCRL if the notAfter time specified in the
+ certificate precedes the thisUpdate time specified in the delta CRL
+ and the certificate was listed on the referenced base CRL or in any
+ CRL issued after the base but before this delta CRL.
+
+ If a certificate revocation notice first appears on a delta CRL, then
+ it is possible for the certificate validity period to expire before
+ the next complete CRL for the same scope is issued. In this case,
+ the revocation notice MUST be included in all subsequent delta CRLs
+ until the revocation notice is included on at least one explicitly
+ issued complete CRL for this scope.
+
+ An application that supports delta CRLs MUST be able to construct a
+ current complete CRL by combining a previously issued complete CRL
+ and the most current delta CRL. An application that supports delta
+ CRLs MAY also be able to construct a current complete CRL by
+ combining a previously locally constructed complete CRL and the
+ current delta CRL. A delta CRL is considered to be the current one
+ if the current time is between the times contained in the thisUpdate
+ and nextUpdate fields. Under some circumstances, the CRL issuer may
+ publish one or more delta CRLs before indicated by the nextUpdate
+ field. If more than one current delta CRL for a given scope is
+ encountered, the application SHOULD consider the one with the latest
+ value in thisUpdate to be the most current one.
+
+ id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }
+
+ BaseCRLNumber ::= CRLNumber
+
+5.2.5 Issuing Distribution Point
+
+ The issuing distribution point is a critical CRL extension that
+ identifies the CRL distribution point and scope for a particular CRL,
+ and it indicates whether the CRL covers revocation for end entity
+ certificates only, CA certificates only, attribute certificates only,
+
+ or a limited set of reason codes. Although the extension is
+ critical, conforming implementations are not required to support this
+ extension.
+
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 58]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ The CRL is signed using the CRL issuer's private key. CRL
+ Distribution 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 the CRL distribution point, which may be different
+ than the Directory entry of the CRL issuer.
+
+ The reason codes associated with a distribution point MUST be
+ specified in onlySomeReasons. If onlySomeReasons does not appear,
+ the distribution point MUST contain revocations for all reason codes.
+ CAs may use CRL distribution points to partition the CRL on the basis
+ of compromise and routine revocation. In this case, the revocations
+ with reason code keyCompromise (1), cACompromise (2), and
+ aACompromise (8) appear in one distribution point, and the
+ revocations with other reason codes appear in another distribution
+ point.
+
+ If the distributionPoint field is present and contains a URI, the
+ following semantics MUST be assumed: the object is a pointer to the
+ most current CRL issued by this CRL issuer. The URI schemes ftp,
+ http, mailto [RFC1738] and ldap [RFC1778] are defined for this
+ purpose. The URI MUST be an absolute pathname, not a relative
+ pathname, and MUST specify the host.
+
+ If the distributionPoint field is absent, the CRL MUST contain
+ entries for all revoked unexpired certificates issued by the CRL
+ issuer, if any, within the scope of the CRL.
+
+ The CRL issuer MUST assert the indirectCRL boolean, if the scope of
+ the CRL includes certificates issued by authorities other than the
+ CRL issuer. The authority responsible for each entry is indicated by
+ the certificate issuer CRL entry extension (section 5.3.4).
+
+ id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 }
+
+ issuingDistributionPoint ::= SEQUENCE {
+ distributionPoint [0] DistributionPointName OPTIONAL,
+ onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE,
+ onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE,
+ onlySomeReasons [3] ReasonFlags OPTIONAL,
+ indirectCRL [4] BOOLEAN DEFAULT FALSE,
+ onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
+
+5.2.6 Freshest CRL (a.k.a. Delta CRL Distribution Point)
+
+ The freshest CRL extension identifies how delta CRL information for
+ this complete CRL is obtained. The extension MUST be non-critical.
+ This extension MUST NOT appear in delta CRLs.
+
+
+
+
+Housley, et. al. Standards Track [Page 59]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ The same syntax is used for this extension as the
+ cRLDistributionPoints certificate extension, and is described in
+ section 4.2.1.14. However, only the distribution point field is
+ meaningful in this context. The reasons and CRLIssuer fields MUST be
+ omitted from this CRL extension.
+
+ Each distribution point name provides the location at which a delta
+ CRL for this complete CRL can be found. The scope of these delta
+ CRLs MUST be the same as the scope of this complete CRL. The
+ contents of this CRL extension are only used to locate delta CRLs;
+ the contents are not used to validate the CRL or the referenced delta
+ CRLs. The encoding conventions defined for distribution points in
+ section 4.2.1.14 apply to this extension.
+
+ id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 }
+
+ FreshestCRL ::= CRLDistributionPoints
+
+5.3 CRL Entry Extensions
+
+ The CRL entry extensions defined by ISO/IEC, ITU-T, and ANSI X9 for
+ X.509 v2 CRLs provide methods for associating additional attributes
+ with CRL entries [X.509] [X9.55]. The X.509 v2 CRL format also
+ allows communities to define private CRL entry extensions to carry
+ information unique to those communities. Each extension in a CRL
+ entry may be designated as critical or non-critical. A CRL
+ validation MUST fail if it encounters a critical CRL entry extension
+ which it does not know how to process. However, an unrecognized non-
+ critical CRL entry extension may be ignored. The following
+ subsections present recommended extensions used within Internet CRL
+ entries and standard locations for information. Communities may
+ elect to use additional CRL entry extensions; however, caution should
+ be exercised in adopting any critical extensions in CRL entries which
+ might be used in a general context.
+
+ All CRL entry extensions used in this specification are non-critical.
+ Support for these extensions is optional for conforming CRL issuers
+ and applications. However, CRL issuers SHOULD include reason codes
+ (section 5.3.1) and invalidity dates (section 5.3.3) whenever this
+ information is available.
+
+5.3.1 Reason Code
+
+ The reasonCode is a non-critical CRL entry extension that identifies
+ the reason for the certificate revocation. CRL issuers are strongly
+ encouraged to include meaningful reason codes in CRL entries;
+ however, the reason code CRL entry extension SHOULD be absent instead
+ of using the unspecified (0) reasonCode value.
+
+
+
+Housley, et. al. Standards Track [Page 60]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ id-ce-cRLReason OBJECT IDENTIFIER ::= { id-ce 21 }
+
+ -- reasonCode ::= { CRLReason }
+
+ CRLReason ::= ENUMERATED {
+ unspecified (0),
+ keyCompromise (1),
+ cACompromise (2),
+ affiliationChanged (3),
+ superseded (4),
+ cessationOfOperation (5),
+ certificateHold (6),
+ removeFromCRL (8),
+ privilegeWithdrawn (9),
+ aACompromise (10) }
+
+5.3.2 Hold Instruction Code
+
+ The hold instruction code is a non-critical CRL entry extension that
+ provides a registered instruction identifier which indicates the
+ action to be taken after encountering a certificate that has been
+ placed on hold.
+
+ id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 }
+
+ holdInstructionCode ::= OBJECT IDENTIFIER
+
+ The following instruction codes have been defined. Conforming
+ applications that process this extension MUST recognize the following
+ instruction codes.
+
+ holdInstruction OBJECT IDENTIFIER ::=
+ { iso(1) member-body(2) us(840) x9-57(10040) 2 }
+
+ id-holdinstruction-none OBJECT IDENTIFIER ::= {holdInstruction 1}
+ id-holdinstruction-callissuer
+ OBJECT IDENTIFIER ::= {holdInstruction 2}
+ id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3}
+
+ Conforming applications which encounter an id-holdinstruction-
+ callissuer MUST call the certificate issuer or reject the
+ certificate. Conforming applications which encounter an id-
+ holdinstruction-reject MUST reject the certificate. The hold
+ instruction id-holdinstruction-none is semantically equivalent to the
+ absence of a holdInstructionCode, and its use is strongly deprecated
+ for the Internet PKI.
+
+
+
+
+
+Housley, et. al. Standards Track [Page 61]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+5.3.3 Invalidity Date
+
+ The invalidity date is a non-critical CRL entry extension that
+ provides the date on which it is known or suspected that the private
+ key was compromised or that the certificate otherwise became invalid.
+ This date may be earlier than the revocation date in the CRL entry,
+ which is the date at which the CA processed the revocation. When a
+ revocation is first posted by a CRL issuer in a CRL, the invalidity
+ date may precede the date of issue of earlier CRLs, but the
+ revocation date SHOULD NOT precede the date of issue of earlier CRLs.
+ Whenever this information is available, CRL issuers are strongly
+ encouraged to share it with CRL users.
+
+ The GeneralizedTime values included in this field MUST be expressed
+ in Greenwich Mean Time (Zulu), and MUST be specified and interpreted
+ as defined in section 4.1.2.5.2.
+
+ id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 }
+
+ invalidityDate ::= GeneralizedTime
+
+5.3.4 Certificate Issuer
+
+ This CRL entry extension identifies the certificate issuer associated
+ with an entry in an indirect CRL, that is, a CRL that has the
+ indirectCRL indicator set in its issuing distribution point
+ extension. If this extension is not present on the first entry in an
+ indirect CRL, the certificate issuer defaults to the CRL issuer. On
+ subsequent entries in an indirect CRL, if this extension is not
+ present, the certificate issuer for the entry is the same as that for
+ the preceding entry. This field is defined as follows:
+
+ id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 }
+
+ certificateIssuer ::= GeneralNames
+
+ If used by conforming CRL issuers, this extension MUST always be
+ critical. If an implementation ignored this extension it could not
+ correctly attribute CRL entries to certificates. This specification
+ RECOMMENDS that implementations recognize this extension.
+
+6 Certification Path Validation
+
+ Certification path validation procedures for the Internet PKI are
+ based on the algorithm supplied in [X.509]. Certification path
+ processing verifies the binding between the subject distinguished
+ name and/or subject alternative name and subject public key. The
+ binding is limited by constraints which are specified in the
+
+
+
+Housley, et. al. Standards Track [Page 62]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ certificates which comprise the path and inputs which are specified
+ by the relying party. The basic constraints and policy constraints
+ extensions allow the certification path processing logic to automate
+ the decision making process.
+
+ This section describes an algorithm for validating certification
+ paths. Conforming implementations of this specification are not
+ required to implement this algorithm, but MUST provide functionality
+ equivalent to the external behavior resulting from this procedure.
+ Any algorithm may be used by a particular implementation so long as
+ it derives the correct result.
+
+ In section 6.1, the text describes basic path validation. Valid
+ paths begin with certificates issued by a trust anchor. The
+ algorithm requires the public key of the CA, the CA's name, and any
+ constraints upon the set of paths which may be validated using this
+ key.
+
+ The selection of a trust anchor is a matter of policy: it could 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 path
+ validation procedure is the same regardless of the choice of trust
+ anchor. In addition, different applications may rely on different
+ trust anchor, or may accept paths that begin with any of a set of
+ trust anchor.
+
+ Section 6.2 describes methods for using the path validation algorithm
+ in specific implementations. Two specific cases are discussed: the
+ case where paths may begin with one of several trusted CAs; and where
+ compatibility with the PEM architecture is required.
+
+ Section 6.3 describes the steps necessary to determine if a
+ certificate is revoked or on hold status when CRLs are the revocation
+ mechanism used by the certificate issuer.
+
+6.1 Basic Path Validation
+
+ This text describes an algorithm for X.509 path processing. A
+ conformant implementation MUST include an X.509 path processing
+ procedure that is functionally equivalent to the external behavior of
+ this algorithm. However, support for some of the certificate
+ extensions processed in this algorithm are OPTIONAL for compliant
+ implementations. Clients that do not support these extensions MAY
+ omit the corresponding steps in the path validation algorithm.
+
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 63]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ For example, clients are NOT REQUIRED to support the policy mapping
+ extension. Clients that do not support this extension MAY omit the
+ path validation steps where policy mappings are processed. Note that
+ clients MUST reject the certificate if it contains an unsupported
+ critical extension.
+
+ The algorithm presented in this section validates the certificate
+ with respect to the current date and time. A conformant
+ implementation MAY also support validation with respect to some point
+ in the past. Note that mechanisms are not available for validating a
+ certificate with respect to a time outside the certificate validity
+ period.
+
+ The trust anchor is an input to the algorithm. There is no
+ requirement that the same trust anchor be used to validate all
+ certification paths. Different trust anchors MAY be used to validate
+ different paths, as discussed further in Section 6.2.
+
+ The primary goal of path validation is to verify the binding between
+ a subject distinguished name or a subject alternative name and
+ subject public key, as represented in the end entity certificate,
+ based on the public key of the trust anchor. This requires obtaining
+ a sequence of certificates that support that binding. The procedure
+ performed to obtain this sequence of certificates is outside the
+ scope of this specification.
+
+ To meet this goal, the path validation process verifies, among other
+ things, that a prospective certification path (a sequence of n
+ certificates) satisfies the following conditions:
+
+ (a) for all x in {1, ..., n-1}, the subject of certificate x is
+ the issuer of certificate x+1;
+
+ (b) certificate 1 is issued by the trust anchor;
+
+ (c) certificate n is the certificate to be validated; and
+
+ (d) for all x in {1, ..., n}, the certificate was valid at the
+ time in question.
+
+ When the trust anchor is provided in the form of a self-signed
+ certificate, this self-signed certificate is not included as part of
+ the prospective certification path. Information about trust anchors
+ are provided as inputs to the certification path validation algorithm
+ (section 6.1.1).
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 64]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ A particular certification path may not, however, be appropriate for
+ all applications. Therefore, an application MAY augment this
+ algorithm to further limit the set of valid paths. The path
+ validation process also determines the set of certificate policies
+ that are valid for this path, based on the certificate policies
+ extension, policy mapping extension, policy constraints extension,
+ and inhibit any-policy extension. To achieve this, the path
+ validation algorithm constructs a valid policy tree. 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, otherwise the
+ result will be a null valid policy tree.
+
+ A certificate is 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)
+ initialization, (2) basic certificate processing, (3) preparation for
+ the next certificate, and (4) wrap-up. Steps (1) and (4) are
+ performed exactly once. Step (2) is performed for all certificates
+ in the path. Step (3) is performed for all certificates in the path
+ except the final certificate. Figure 2 provides a high-level
+ flowchart of this algorithm.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 65]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ +-------+
+ | START |
+ +-------+
+ |
+ V
+ +----------------+
+ | Initialization |
+ +----------------+
+ |
+ +<--------------------+
+ | |
+ V |
+ +----------------+ |
+ | Process Cert | |
+ +----------------+ |
+ | |
+ V |
+ +================+ |
+ | IF Last Cert | |
+ | in Path | |
+ +================+ |
+ | | |
+ THEN | | ELSE |
+ V V |
+ +----------------+ +----------------+ |
+ | Wrap up | | Prepare for | |
+ +----------------+ | Next Cert | |
+ | +----------------+ |
+ V | |
+ +-------+ +--------------+
+ | STOP |
+ +-------+
+
+
+ Figure 2. Certification Path Processing Flowchart
+
+6.1.1 Inputs
+
+ This algorithm assumes the following seven inputs are provided to the
+ path processing logic:
+
+ (a) a prospective certification path of length n.
+
+ (b) the current date/time.
+
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 66]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ (c) user-initial-policy-set: A set of certificate policy
+ identifiers naming the policies that are acceptable to the
+ certificate user. The user-initial-policy-set contains the
+ special value any-policy if the user is not concerned about
+ certificate policy.
+
+ (d) trust anchor information, describing a CA that serves as a
+ trust anchor for the certification path. The trust anchor
+ information includes:
+
+ (1) the trusted issuer name,
+
+ (2) the trusted public key algorithm,
+
+ (3) the trusted public key, and
+
+ (4) optionally, the trusted public key parameters associated
+ with the public key.
+
+ The trust anchor information may be provided to the path
+ processing procedure in the form of a self-signed certificate.
+ The trusted anchor information is trusted because it was delivered
+ to the path processing procedure by some trustworthy out-of-band
+ procedure. If the trusted public key algorithm requires
+ parameters, then the parameters are provided along with the
+ trusted public key.
+
+ (e) initial-policy-mapping-inhibit, which indicates if policy
+ mapping is allowed in the certification path.
+
+ (f) initial-explicit-policy, which indicates if the path must be
+ valid for at least one of the certificate policies in the user-
+ initial-policy-set.
+
+ (g) initial-any-policy-inhibit, which indicates whether the
+ anyPolicy OID should be processed if it is included in a
+ certificate.
+
+6.1.2 Initialization
+
+ This initialization phase establishes eleven state variables based
+ upon the seven inputs:
+
+ (a) valid_policy_tree: A tree of certificate policies with their
+ optional qualifiers; each of the leaves of the tree represents a
+ valid policy at this stage in the certification path validation.
+ If valid policies exist at this stage in the certification path
+ validation, the depth of the tree is equal to the number of
+
+
+
+Housley, et. al. Standards Track [Page 67]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ certificates in the chain that have been processed. If valid
+ policies do not exist at this stage in the certification path
+ validation, the tree is set to NULL. Once the tree is set to
+ NULL, policy processing ceases.
+
+ Each node in the valid_policy_tree includes four data objects: the
+ valid policy, a set of associated policy qualifiers, a set of one
+ or more expected policy values, and a criticality indicator. If
+ the node is at depth x, the components of the node have the
+ following semantics:
+
+ (1) The valid_policy is a single policy OID representing a
+ valid policy for the path of length x.
+
+ (2) The qualifier_set is a set of policy qualifiers associated
+ with the valid policy in certificate x.
+
+ (3) The criticality_indicator indicates whether the
+ certificate policy extension in certificate x was marked as
+ critical.
+
+ (4) The expected_policy_set contains one or more policy OIDs
+ that would satisfy this policy in the certificate x+1.
+
+ The initial value of the valid_policy_tree is a single node with
+ valid_policy anyPolicy, an empty qualifier_set, an
+ expected_policy_set with the single value anyPolicy, and a
+ criticality_indicator of FALSE. This node is considered to be at
+ depth zero.
+
+ Figure 3 is a graphic representation of the initial state of the
+ valid_policy_tree. Additional figures will use this format to
+ describe changes in the valid_policy_tree during path processing.
+
+ +----------------+
+ | anyPolicy | <---- valid_policy
+ +----------------+
+ | {} | <---- qualifier_set
+ +----------------+
+ | FALSE | <---- criticality_indicator
+ +----------------+
+ | {anyPolicy} | <---- expected_policy_set
+ +----------------+
+
+ Figure 3. Initial value of the valid_policy_tree state variable
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 68]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ (b) permitted_subtrees: A set of root names for each name type
+ (e.g., X.500 distinguished names, email addresses, or ip
+ addresses) defining a set of subtrees within which all subject
+ names in subsequent certificates in the certification path MUST
+ fall. This variable includes a set for each name type: the
+ initial value for the set for Distinguished Names is the set of
+ all Distinguished names; the initial value for the set of RFC822
+ names is the set of all RFC822 names, etc.
+
+ (c) excluded_subtrees: A set of root names for each name type
+ (e.g., X.500 distinguished names, email addresses, or ip
+ addresses) defining a set of subtrees within which no subject name
+ in subsequent certificates in the certification path may fall.
+ This variable includes a set for each name type, and the initial
+ value for each set is empty.
+
+ (d) explicit_policy: an integer which indicates if a non-NULL
+ valid_policy_tree is required. The integer indicates the number of
+ non-self-issued certificates to be processed before this
+ requirement is imposed. Once set, this variable may be decreased,
+ 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
+ remove this requirement. If initial-explicit-policy is set, then
+ the initial value is 0, otherwise the initial value is n+1.
+
+ (e) inhibit_any-policy: an integer which indicates whether the
+ anyPolicy policy identifier is considered a match. The integer
+ indicates the number of non-self-issued certificates to be
+ processed before the anyPolicy OID, if asserted in a certificate,
+ is ignored. Once set, this variable may be decreased, but may not
+ be increased. That is, if a certificate in the path inhibits
+ processing of anyPolicy, a later certificate can not permit it.
+ If initial-any-policy-inhibit is set, then the initial value is 0,
+ otherwise the initial value is n+1.
+
+ (f) policy_mapping: an integer which indicates if policy mapping
+ is permitted. The integer indicates the number of non-self-issued
+ certificates to be processed before policy mapping is inhibited.
+ Once set, this variable may be decreased, but may not be
+ increased. That is, if a certificate in the path specifies policy
+ mapping is not permitted, it can not be overridden by a later
+ certificate. If initial-policy-mapping-inhibit is set, then the
+ initial value is 0, otherwise the initial value is n+1.
+
+ (g) working_public_key_algorithm: the digital signature algorithm
+ used to verify the signature of a certificate. The
+ working_public_key_algorithm is initialized from the trusted
+ public key algorithm provided in the trust anchor information.
+
+
+
+Housley, et. al. Standards Track [Page 69]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ (h) working_public_key: the public key used to verify the
+ signature of a certificate. The working_public_key is initialized
+ from the trusted public key provided in the trust anchor
+ information.
+
+ (i) working_public_key_parameters: parameters associated with the
+ current public key, that may be required to verify a signature
+ (depending upon the algorithm). The working_public_key_parameters
+ variable is initialized from the trusted public key parameters
+ provided in the trust anchor information.
+
+ (j) working_issuer_name: the issuer distinguished name expected
+ in the next certificate in the chain. The working_issuer_name is
+ initialized to the trusted issuer provided in the trust anchor
+ information.
+
+ (k) max_path_length: this integer is initialized to n, is
+ decremented for each non-self-issued certificate in the path, and
+ may be reduced to the value in the path length constraint field
+ within the basic constraints extension of a CA certificate.
+
+ Upon completion of the initialization steps, perform the basic
+ certificate processing steps specified in 6.1.3.
+
+6.1.3 Basic Certificate Processing
+
+ The basic path processing actions to be performed for certificate i
+ (for all i in [1..n]) are listed below.
+
+ (a) Verify the basic certificate information. The certificate
+ MUST satisfy each of the following:
+
+ (1) The certificate was signed with the
+ working_public_key_algorithm using the working_public_key and
+ the working_public_key_parameters.
+
+ (2) The certificate validity period includes the current time.
+
+ (3) At the current time, the certificate is not revoked and is
+ not on hold status. This may be determined by obtaining the
+ appropriate CRL (section 6.3), status information, or by out-
+ of-band mechanisms.
+
+ (4) The certificate issuer name is the working_issuer_name.
+
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 70]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ (b) If certificate i is self-issued and it is not the final
+ certificate in the path, skip this step for certificate i.
+ Otherwise, verify that the subject name is within one of the
+ permitted_subtrees for X.500 distinguished names, and verify that
+ each of the alternative names in the subjectAltName extension
+ (critical or non-critical) is within one of the permitted_subtrees
+ for that name type.
+
+ (c) If certificate i is self-issued and it is not the final
+ certificate in the path, skip this step for certificate i.
+ Otherwise, verify that the subject name is not within one of the
+ excluded_subtrees for X.500 distinguished names, and verify that
+ each of the alternative names in the subjectAltName extension
+ (critical or non-critical) is not within one of the
+ excluded_subtrees for that name type.
+
+ (d) If the certificate policies extension is present in the
+ certificate and the valid_policy_tree is not NULL, process the
+ policy information by performing the following steps in order:
+
+ (1) For each policy P not equal to anyPolicy in the
+ certificate policies extension, let P-OID denote the OID in
+ policy P and P-Q denote the qualifier set for policy P.
+ Perform the following steps in order:
+
+ (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
+ node as follows: set the valid_policy to OID-P; set the
+ qualifier_set to P-Q, and set the expected_policy_set to
+ {P-OID}.
+
+ For example, consider a valid_policy_tree with a node of
+ depth i-1 where the expected_policy_set is {Gold, White}.
+ Assume the certificate policies Gold and Silver appear in
+ the certificate policies extension of certificate i. The
+ Gold policy is matched but the Silver policy is not. This
+ rule will generate a child node of depth i for the Gold
+ policy. The result is shown as Figure 4.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 71]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ +-----------------+
+ | Red |
+ +-----------------+
+ | {} |
+ +-----------------+ node of depth i-1
+ | FALSE |
+ +-----------------+
+ | {Gold, White} |
+ +-----------------+
+ |
+ |
+ |
+ V
+ +-----------------+
+ | Gold |
+ +-----------------+
+ | {} |
+ +-----------------+ node of depth i
+ | uninitialized |
+ +-----------------+
+ | {Gold} |
+ +-----------------+
+
+ Figure 4. Processing an exact match
+
+ (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 anyPolicy, generate a child node with the
+ following values: set the valid_policy to P-OID; set the
+ qualifier_set to P-Q, and set the expected_policy_set to
+ {P-OID}.
+
+ For example, consider a valid_policy_tree with a node of
+ depth i-1 where the valid_policy is anyPolicy. Assume the
+ certificate policies Gold and Silver appear in the
+ certificate policies extension of certificate i. The Gold
+ policy does not have a qualifier, but the Silver policy has
+ the qualifier Q-Silver. If Gold and Silver were not matched
+ in (i) above, this rule will generate two child nodes of
+ depth i, one for each policy. The result is shown as Figure
+ 5.
+
+
+
+
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 72]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ +-----------------+
+ | anyPolicy |
+ +-----------------+
+ | {} |
+ +-----------------+ node of depth i-1
+ | FALSE |
+ +-----------------+
+ | {anyPolicy} |
+ +-----------------+
+ / \
+ / \
+ / \
+ / \
+ +-----------------+ +-----------------+
+ | Gold | | Silver |
+ +-----------------+ +-----------------+
+ | {} | | {Q-Silver} |
+ +-----------------+ nodes of +-----------------+
+ | uninitialized | depth i | uninitialized |
+ +-----------------+ +-----------------+
+ | {Gold} | | {Silver} |
+ +-----------------+ +-----------------+
+
+ Figure 5. Processing unmatched policies when a leaf node
+ specifies anyPolicy
+
+ (2) If the certificate policies extension includes the policy
+ anyPolicy with the qualifier set AP-Q and either (a)
+ inhibit_any-policy is greater than 0 or (b) i<n and the
+ certificate is self-issued, then:
+
+ For each node in the valid_policy_tree of depth i-1, for each
+ value in the expected_policy_set (including anyPolicy) that
+ does not appear in a child node, create a child node with the
+ following values: set the valid_policy to the value from the
+ expected_policy_set in the parent node; set the qualifier_set
+ to AP-Q, and set the expected_policy_set to the value in the
+ valid_policy from this node.
+
+ For example, consider a valid_policy_tree with a node of depth
+ i-1 where the expected_policy_set is {Gold, Silver}. Assume
+ anyPolicy appears in the certificate policies extension of
+ certificate i, but Gold and Silver do not. This rule will
+ generate two child nodes of depth i, one for each policy. The
+ result is shown below as Figure 6.
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 73]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ +-----------------+
+ | Red |
+ +-----------------+
+ | {} |
+ +-----------------+ node of depth i-1
+ | FALSE |
+ +-----------------+
+ | {Gold, Silver} |
+ +-----------------+
+ / \
+ / \
+ / \
+ / \
+ +-----------------+ +-----------------+
+ | Gold | | Silver |
+ +-----------------+ +-----------------+
+ | {} | | {} |
+ +-----------------+ nodes of +-----------------+
+ | uninitialized | depth i | uninitialized |
+ +-----------------+ +-----------------+
+ | {Gold} | | {Silver} |
+ +-----------------+ +-----------------+
+
+ Figure 6. Processing unmatched policies when the certificate
+ policies extension specifies anyPolicy
+
+ (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
+ step until there are no nodes of depth i-1 or less without
+ children.
+
+ For example, consider the valid_policy_tree shown in Figure 7
+ below. The two nodes at depth i-1 that are marked with an 'X'
+ have no children, and are deleted. Applying this rule to the
+ resulting tree will cause the node at depth i-2 that is marked
+ with an 'Y' to be deleted. The following application of the
+ rule does not cause any nodes to be deleted, and this step is
+ complete.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 74]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ +-----------+
+ | | node of depth i-3
+ +-----------+
+ / | \
+ / | \
+ / | \
+ +-----------+ +-----------+ +-----------+
+ | | | | | Y | nodes of
+ +-----------+ +-----------+ +-----------+ depth i-2
+ / \ | |
+ / \ | |
+ / \ | |
+ +-----------+ +-----------+ +-----------+ +-----------+ nodes of
+ | | | X | | | | X | depth
+ +-----------+ +-----------+ +-----------+ +-----------+ i-1
+ | / | \
+ | / | \
+ | / | \
+ +-----------+ +-----------+ +-----------+ +-----------+ nodes of
+ | | | | | | | | depth
+ +-----------+ +-----------+ +-----------+ +-----------+ i
+
+ Figure 7. Pruning the valid_policy_tree
+
+ (4) If the certificate policies extension was marked as
+ critical, set the criticality_indicator in all nodes of depth i
+ to TRUE. If the certificate policies extension was not marked
+ critical, set the criticality_indicator in all nodes of depth i
+ to FALSE.
+
+ (e) If the certificate policies extension is not present, set the
+ valid_policy_tree to NULL.
+
+ (f) Verify that either explicit_policy is greater than 0 or the
+ valid_policy_tree is not equal to NULL;
+
+ If any of steps (a), (b), (c), or (f) fails, the procedure
+ terminates, returning a failure indication and an appropriate reason.
+
+ If i is not equal to n, continue by performing the preparatory steps
+ listed in 6.1.4. If i is equal to n, perform the wrap-up steps
+ listed in 6.1.5.
+
+6.1.4 Preparation for Certificate i+1
+
+ To prepare for processing of certificate i+1, perform the following
+ steps for certificate i:
+
+
+
+
+Housley, et. al. Standards Track [Page 75]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ (a) If a policy mapping extension is present, verify that the
+ special value anyPolicy does not appear as an issuerDomainPolicy
+ or a subjectDomainPolicy.
+
+ (b) If a policy mapping extension is present, then for each
+ issuerDomainPolicy ID-P in the policy mapping extension:
+
+ (1) If the policy_mapping variable is greater than 0, for each
+ node in the valid_policy_tree of depth i where ID-P is the
+ valid_policy, set expected_policy_set to the set of
+ subjectDomainPolicy values that are specified as equivalent to
+ ID-P by the policy mapping extension.
+
+ If no node of depth i in the valid_policy_tree has a
+ valid_policy of ID-P but there is a node of depth i with a
+ valid_policy of anyPolicy, then generate a child node of the
+ node of depth i-1 that has a valid_policy of anyPolicy as
+ follows:
+
+ (i) set the valid_policy to ID-P;
+
+ (ii) set the qualifier_set to the qualifier set of the
+ policy anyPolicy in the certificate policies extension of
+ certificate i;
+
+ (iii) set the criticality_indicator to the criticality of
+ the certificate policies extension of certificate i;
+
+ (iv) and set the expected_policy_set to the set of
+ subjectDomainPolicy values that are specified as equivalent
+ to ID-P by the policy mappings extension.
+
+ (2) If the policy_mapping variable is equal to 0:
+
+ (i) delete each node of depth i in the valid_policy_tree
+ where ID-P is the valid_policy.
+
+ (ii) 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 step until there are no nodes of depth i-1 or
+ less without children.
+
+ (c) Assign the certificate subject name to working_issuer_name.
+
+ (d) Assign the certificate subjectPublicKey to
+ working_public_key.
+
+
+
+
+
+Housley, et. al. Standards Track [Page 76]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ (e) If the subjectPublicKeyInfo field of the certificate contains
+ an algorithm field with non-null parameters, assign the parameters
+ to the working_public_key_parameters variable.
+
+ If the subjectPublicKeyInfo field of the certificate contains an
+ algorithm field with null parameters or parameters are omitted,
+ compare the certificate subjectPublicKey algorithm to the
+ working_public_key_algorithm. If the certificate subjectPublicKey
+ algorithm and the working_public_key_algorithm are different, set
+ the working_public_key_parameters to null.
+
+ (f) Assign the certificate subjectPublicKey algorithm to the
+ working_public_key_algorithm variable.
+
+ (g) If a name constraints extension is included in the
+ certificate, modify the permitted_subtrees and excluded_subtrees
+ state variables as follows:
+
+ (1) If permittedSubtrees is present in the certificate, set
+ the permitted_subtrees state variable to the intersection of
+ its previous value and the value indicated in the extension
+ field. If permittedSubtrees does not include a particular name
+ type, the permitted_subtrees state variable is unchanged for
+ that name type. For example, the intersection of nist.gov and
+ csrc.nist.gov is csrc.nist.gov. And, the intersection of
+ nist.gov and rsasecurity.com is the empty set.
+
+ (2) If excludedSubtrees is present in the certificate, set the
+ excluded_subtrees state variable to the union of its previous
+ value and the value indicated in the extension field. If
+ excludedSubtrees does not include a particular name type, the
+ excluded_subtrees state variable is unchanged for that name
+ type. For example, the union of the name spaces nist.gov and
+ csrc.nist.gov is nist.gov. And, the union of nist.gov and
+ rsasecurity.com is both name spaces.
+
+ (h) If the issuer and subject names are not identical:
+
+ (1) If explicit_policy is not 0, decrement explicit_policy by
+ 1.
+
+ (2) If policy_mapping is not 0, decrement policy_mapping by 1.
+
+ (3) If inhibit_any-policy is not 0, decrement inhibit_any-
+ policy by 1.
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 77]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ (i) If a policy constraints extension is included in the
+ certificate, modify the explicit_policy and policy_mapping state
+ variables as follows:
+
+ (1) If requireExplicitPolicy is present and is less than
+ explicit_policy, set explicit_policy to the value of
+ requireExplicitPolicy.
+
+ (2) If inhibitPolicyMapping is present and is less than
+ policy_mapping, set policy_mapping to the value of
+ inhibitPolicyMapping.
+
+ (j) If the inhibitAnyPolicy extension is included in the
+ certificate and is less than inhibit_any-policy, set inhibit_any-
+ policy to the value of inhibitAnyPolicy.
+
+ (k) Verify that the certificate is a CA certificate (as specified
+ in a basicConstraints extension or as verified out-of-band).
+
+ (l) If the certificate was not self-issued, verify that
+ max_path_length is greater than zero and decrement max_path_length
+ by 1.
+
+ (m) If pathLengthConstraint is present in the certificate and is
+ less than max_path_length, set max_path_length to the value of
+ pathLengthConstraint.
+
+ (n) If a key usage extension is present, verify that the
+ keyCertSign bit is set.
+
+ (o) Recognize and process any other critical extension present in
+ the certificate. Process any other recognized non-critical
+ extension present in the certificate.
+
+ If check (a), (k), (l), (n) or (o) fails, the procedure terminates,
+ returning a failure indication and an appropriate reason.
+
+ If (a), (k), (l), (n) and (o) have completed successfully, increment
+ i and perform the basic certificate processing specified in 6.1.3.
+
+6.1.5 Wrap-up procedure
+
+ To complete the processing of the end entity certificate, perform the
+ following steps for certificate n:
+
+ (a) If certificate n was not self-issued and explicit_policy is
+ not 0, decrement explicit_policy by 1.
+
+
+
+
+Housley, et. al. Standards Track [Page 78]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ (b) If a policy constraints extension is included in the
+ certificate and requireExplicitPolicy is present and has a value
+ of 0, set the explicit_policy state variable to 0.
+
+ (c) Assign the certificate subjectPublicKey to
+ working_public_key.
+
+ (d) If the subjectPublicKeyInfo field of the certificate contains
+ an algorithm field with non-null parameters, assign the parameters
+ to the working_public_key_parameters variable.
+
+ If the subjectPublicKeyInfo field of the certificate contains an
+ algorithm field with null parameters or parameters are omitted,
+ compare the certificate subjectPublicKey algorithm to the
+ working_public_key_algorithm. If the certificate subjectPublicKey
+ algorithm and the working_public_key_algorithm are different, set
+ the working_public_key_parameters to null.
+
+ (e) Assign the certificate subjectPublicKey algorithm to the
+ working_public_key_algorithm variable.
+
+ (f) Recognize and process any other critical extension present in
+ the certificate n. Process any other recognized non-critical
+ extension present in certificate n.
+
+ (g) Calculate the intersection of the valid_policy_tree and the
+ user-initial-policy-set, as follows:
+
+ (i) If the valid_policy_tree is NULL, the intersection is
+ NULL.
+
+ (ii) If the valid_policy_tree is not NULL and the user-
+ initial-policy-set is any-policy, the intersection is the
+ entire valid_policy_tree.
+
+ (iii) If the valid_policy_tree is not NULL and the user-
+ initial-policy-set is not any-policy, calculate the
+ intersection of the valid_policy_tree and the user-initial-
+ policy-set as follows:
+
+ 1. Determine the set of policy nodes whose parent nodes
+ have a valid_policy of anyPolicy. This is the
+ valid_policy_node_set.
+
+ 2. If the valid_policy of any node in the
+ valid_policy_node_set is not in the user-initial-policy-set
+ and is not anyPolicy, delete this node and all its children.
+
+
+
+
+Housley, et. al. Standards Track [Page 79]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ 3. If the valid_policy_tree includes a node of depth n with
+ the valid_policy anyPolicy and the user-initial-policy-set
+ is not any-policy perform the following steps:
+
+ a. Set P-Q to the qualifier_set in the node of depth n
+ with valid_policy anyPolicy.
+
+ b. For each P-OID in the user-initial-policy-set that is
+ not the valid_policy of a node in the
+ valid_policy_node_set, create a child node whose parent
+ is the node of depth n-1 with the valid_policy anyPolicy.
+ Set the values in the child node as follows: set the
+ valid_policy to P-OID; set the qualifier_set to P-Q; copy
+ the criticality_indicator from the node of depth n with
+ the valid_policy anyPolicy; and set the
+ expected_policy_set to {P-OID}.
+
+ c. Delete the node of depth n with the valid_policy
+ anyPolicy.
+
+ 4. If there is a node in the valid_policy_tree of depth n-1
+ or less without any child nodes, delete that node. Repeat
+ this step until there are no nodes of depth n-1 or less
+ without children.
+
+ If either (1) the value of explicit_policy variable is greater than
+ zero, or (2) the valid_policy_tree is not NULL, then path processing
+ has succeeded.
+
+6.1.6 Outputs
+
+ If path processing succeeds, the procedure terminates, returning a
+ success indication together with final value of the
+ valid_policy_tree, the working_public_key, the
+ working_public_key_algorithm, and the working_public_key_parameters.
+
+6.2 Using the Path Validation Algorithm
+
+ The path validation algorithm describes the process of validating a
+ single certification path. While each certification path begins with
+ a specific trust anchor, there is no requirement that all
+ certification paths validated by a particular system share a single
+ trust anchor. An implementation that supports multiple trust anchors
+ MAY augment the algorithm presented in section 6.1 to further limit
+ the set of valid certification paths which begin with a particular
+ trust anchor. For example, an implementation MAY modify the
+ algorithm to apply name constraints to a specific trust anchor during
+ the initialization phase, or the application MAY require the presence
+
+
+
+Housley, et. al. Standards Track [Page 80]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ of a particular alternative name form in the end entity certificate,
+ or the application MAY impose requirements on application-specific
+ extensions. Thus, the path validation algorithm presented in section
+ 6.1 defines the minimum conditions for a path to be considered valid.
+
+ 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
+ a particular path. The inputs to the path validation algorithm may
+ be different for each path. The inputs used to process a path may
+ reflect application-specific requirements or limitations in the trust
+ accorded a particular trust anchor. For example, a trusted CA may
+ only be trusted for a particular certificate policy. This
+ restriction can be expressed through the inputs to the path
+ validation procedure.
+
+ It is also possible to specify an extended version of the above
+ certification path processing procedure which results in default
+ behavior identical to the rules of PEM [RFC 1422]. In this extended
+ version, additional inputs to the procedure are a list of one or more
+ Policy Certification Authority (PCA) names and an indicator of the
+ position in the certification path where the PCA is expected. At the
+ nominated PCA position, the CA name is compared against this list.
+ If a recognized PCA name is found, then a constraint of
+ SubordinateToCA is implicitly assumed for the remainder of the
+ certification path and processing continues. If no valid PCA name is
+ found, and if the certification path cannot be validated on the basis
+ of identified policies, then the certification path is considered
+ invalid.
+
+6.3 CRL Validation
+
+ This section describes the steps necessary to determine if a
+ certificate is revoked or on hold status when CRLs are the revocation
+ mechanism used by the certificate issuer. Conforming implementations
+ that support CRLs are not required to implement this algorithm, but
+ they MUST be functionally equivalent to the external behavior
+ resulting from this procedure. Any algorithm may be used by a
+ particular implementation so long as it derives the correct result.
+
+ This algorithm assumes that all of the needed CRLs are available in a
+ local cache. Further, if the next update time of a CRL has passed,
+ the algorithm assumes a mechanism to fetch a current CRL and place it
+ in the local CRL cache.
+
+ This algorithm defines a set of inputs, a set of state variables, and
+ processing steps that are performed for each certificate in the path.
+ The algorithm output is the revocation status of the certificate.
+
+
+
+
+Housley, et. al. Standards Track [Page 81]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+6.3.1 Revocation Inputs
+
+ To support revocation processing, the algorithm requires two inputs:
+
+ (a) certificate: The algorithm requires the certificate serial
+ number and issuer name to determine whether a certificate is on a
+ particular CRL. The basicConstraints extension is used to
+ determine whether the supplied certificate is associated with a CA
+ or an end entity. If present, the algorithm uses the
+ cRLDistributionsPoint and freshestCRL extensions to determine
+ revocation status.
+
+ (b) use-deltas: This boolean input determines whether delta CRLs
+ are applied to CRLs.
+
+ Note that implementations supporting legacy PKIs, such as RFC 1422
+ and X.509 version 1, will need an additional input indicating
+ whether the supplied certificate is associated with a CA or an end
+ entity.
+
+6.3.2 Initialization and Revocation State Variables
+
+ To support CRL processing, the algorithm requires the following state
+ variables:
+
+ (a) reasons_mask: This variable contains the set of revocation
+ reasons supported by the CRLs and delta CRLs processed so far.
+ The legal members of the set are the possible revocation reason
+ values: unspecified, keyCompromise, caCompromise,
+ affiliationChanged, superseded, cessationOfOperation,
+ certificateHold, privilegeWithdrawn, and aACompromise. The
+ special value all-reasons is used to denote the set of all legal
+ members. This variable is initialized to the empty set.
+
+ (b) cert_status: This variable contains the status of the
+ certificate. This variable may be assigned one of the following
+ values: unspecified, keyCompromise, caCompromise,
+ affiliationChanged, superseded, cessationOfOperation,
+ certificateHold, removeFromCRL, privilegeWithdrawn, aACompromise,
+ the special value UNREVOKED, or the special value UNDETERMINED.
+ This variable is initialized to the special value UNREVOKED.
+
+ (c) interim_reasons_mask: This contains the set of revocation
+ reasons supported by the CRL or delta CRL currently being
+ processed.
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 82]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ Note: In some environments, it is not necessary to check all reason
+ codes. For example, some environments are only concerned with
+ caCompromise and keyCompromise for CA certificates. This algorithm
+ checks all reason codes. Additional processing and state variables
+ may be necessary to limit the checking to a subset of the reason
+ codes.
+
+6.3.3 CRL Processing
+
+ This algorithm begins by assuming the certificate is not revoked.
+ The algorithm checks one or more CRLs until either the certificate
+ status is determined to be revoked or sufficient CRLs have been
+ checked to cover all reason codes.
+
+ For each distribution point (DP) in the certificate CRL distribution
+ points extension, for each corresponding CRL in the local CRL cache,
+ while ((reasons_mask is not all-reasons) and (cert_status is
+ UNREVOKED)) perform the following:
+
+ (a) Update the local CRL cache by obtaining a complete CRL, a
+ delta CRL, or both, as required:
+
+ (1) If the current time is after the value of the CRL next
+ update field, then do one of the following:
+
+ (i) If use-deltas is set and either the certificate or the
+ CRL contains the freshest CRL extension, obtain a delta CRL
+ with the a next update value that is after the current time
+ and can be used to update the locally cached CRL as
+ specified in section 5.2.4.
+
+ (ii) Update the local CRL cache with a current complete
+ CRL, verify that the current time is before the next update
+ value in the new CRL, and continue processing with the new
+ CRL. If use-deltas is set, then obtain the current delta
+ CRL that can be used to update the new locally cached
+ complete CRL as specified in section 5.2.4.
+
+ (2) If the current time is before the value of the next update
+ field and use-deltas is set, then obtain the current delta CRL
+ that can be used to update the locally cached complete CRL as
+ specified in section 5.2.4.
+
+ (b) Verify the issuer and scope of the complete CRL as follows:
+
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 83]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ (1) If the DP includes cRLIssuer, then verify that the issuer
+ field in the complete CRL matches cRLIssuer in the DP and that
+ the complete CRL contains an issuing distribution point
+ extension with the indrectCRL boolean asserted. Otherwise,
+ verify that the CRL issuer matches the certificate issuer.
+
+ (2) If the complete CRL includes an issuing distribution point
+ (IDP) CRL extension check the following:
+
+ (i) If the distribution point name is present in the IDP
+ CRL extension and the distribution field is present in the
+ DP, then verify that one of the names in the IDP matches one
+ of the names in the DP. If the distribution point name is
+ present in the IDP CRL extension and the distribution field
+ is omitted from the DP, then verify that one of the names in
+ the IDP matches one of the names in the cRLIssuer field of
+ the DP.
+
+ (ii) If the onlyContainsUserCerts boolean is asserted in
+ the IDP CRL extension, verify that the certificate does not
+ include the basic constraints extension with the cA boolean
+ asserted.
+
+ (iii) If the onlyContainsCACerts boolean is asserted in the
+ IDP CRL extension, verify that the certificate includes the
+ basic constraints extension with the cA boolean asserted.
+
+ (iv) Verify that the onlyContainsAttributeCerts boolean is
+ not asserted.
+
+ (c) If use-deltas is set, verify the issuer and scope of the
+ delta CRL as follows:
+
+ (1) Verify that the delta CRL issuer matches complete CRL
+ issuer.
+
+ (2) If the complete CRL includes an issuing distribution point
+ (IDP) CRL extension, verify that the delta CRL contains a
+ matching IDP CRL extension. If the complete CRL omits an IDP
+ CRL extension, verify that the delta CRL also omits an IDP CRL
+ extension.
+
+ (3) Verify that the delta CRL authority key identifier
+ extension matches complete CRL authority key identifier
+ extension.
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 84]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ (d) Compute the interim_reasons_mask for this CRL as follows:
+
+ (1) If the issuing distribution point (IDP) CRL extension is
+ present and includes onlySomeReasons and the DP includes
+ reasons, then set interim_reasons_mask to the intersection of
+ reasons in the DP and onlySomeReasons in IDP CRL extension.
+
+ (2) If the IDP CRL extension includes onlySomeReasons but the
+ DP omits reasons, then set interim_reasons_mask to the value of
+ onlySomeReasons in IDP CRL extension.
+
+ (3) If the IDP CRL extension is not present or omits
+ onlySomeReasons but the DP includes reasons, then set
+ interim_reasons_mask to the value of DP reasons.
+
+ (4) If the IDP CRL extension is not present or omits
+ onlySomeReasons and the DP omits reasons, then set
+ interim_reasons_mask to the special value all-reasons.
+
+ (e) Verify that interim_reasons_mask includes one or more reasons
+ that is not included in the reasons_mask.
+
+ (f) Obtain and validate the certification path for the complete CRL
+ issuer. If a key usage extension is present in the CRL issuer's
+ certificate, verify that the cRLSign bit is set.
+
+ (g) Validate the signature on the complete CRL using the public key
+ validated in step (f).
+
+ (h) If use-deltas is set, then validate the signature on the delta
+ CRL using the public key validated in step (f).
+
+ (i) If use-deltas is set, then search for the certificate on the
+ delta CRL. If an entry is found that matches the certificate issuer
+ and serial number as described in section 5.3.4, then set the
+ cert_status variable to the indicated reason as follows:
+
+ (1) If the reason code CRL entry extension is present, set the
+ cert_status variable to the value of the reason code CRL entry
+ extension.
+
+ (2) If the reason code CRL entry extension is not present, set
+ the cert_status variable to the value unspecified.
+
+
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 85]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ (j) If (cert_status is UNREVOKED), then search for the
+ certificate on the complete CRL. If an entry is found that
+ matches the certificate issuer and serial number as described in
+ section 5.3.4, then set the cert_status variable to the indicated
+ reason as described in step (i).
+
+ (k) If (cert_status is removeFromCRL), then set cert_status to
+ UNREVOKED.
+
+ If ((reasons_mask is all-reasons) OR (cert_status is not UNREVOKED)),
+ then the revocation status has been determined, so return
+ cert_status.
+
+ If the revocation status has not been determined, repeat the process
+ above with any available CRLs not specified in a distribution point
+ but issued by the certificate issuer. For the processing of such a
+ CRL, assume a DP with both the reasons and the cRLIssuer fields
+ omitted and a distribution point name of the certificate issuer.
+ That is, the sequence of names in fullName is generated from the
+ certificate issuer field as well as the certificate issuerAltName
+ extension. If the revocation status remains undetermined, then
+ return the cert_status UNDETERMINED.
+
+7 References
+
+ [ISO 10646] ISO/IEC 10646-1:1993. International Standard --
+ Information technology -- Universal Multiple-Octet Coded
+ Character Set (UCS) -- Part 1: Architecture and Basic
+ Multilingual Plane.
+
+ [RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ September 1981.
+
+ [RFC 822] Crocker, D., "Standard for the format of ARPA Internet
+ text messages", STD 11, RFC 822, August 1982.
+
+ [RFC 1034] Mockapetris, P., "Domain Names - Concepts and
+ Facilities", STD 13, RFC 1034, November 1987.
+
+ [RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic
+ Mail: Part II: Certificate-Based Key Management," RFC
+ 1422, February 1993.
+
+ [RFC 1423] Balenson, D., "Privacy Enhancement for Internet
+ Electronic Mail: Part III: Algorithms, Modes, and
+ Identifiers," RFC 1423, February 1993.
+
+
+
+
+
+Housley, et. al. Standards Track [Page 86]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ [RFC 1510] Kohl, J. and C. Neuman, "The Kerberos Network
+ Authentication Service (V5)," RFC 1510, September 1993.
+
+ [RFC 1519] Fuller, V., T. Li, J. Yu and K. Varadhan, "Classless
+ Inter-Domain Routing (CIDR): An Address Assignment and
+ Aggregation Strategy", RFC 1519, September 1993.
+
+ [RFC 1738] Berners-Lee, T., L. Masinter and M. McCahill, "Uniform
+ Resource Locators (URL)", RFC 1738, December 1994.
+
+ [RFC 1778] Howes, T., S. Kille, W. Yeong and C. Robbins, "The String
+ Representation of Standard Attribute Syntaxes," RFC 1778,
+ March 1995.
+
+ [RFC 1883] Deering, S. and R. Hinden. "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 1883, December 1995.
+
+ [RFC 2044] F. Yergeau, F., "UTF-8, a transformation format of
+ Unicode and ISO 10646", RFC 2044, October 1996.
+
+ [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC 2247] Kille, S., M. Wahl, A. Grimstad, R. Huber and S.
+ Sataluri, "Using Domains in LDAP/X.500 Distinguished
+ Names", RFC 2247, January 1998.
+
+ [RFC 2252] Wahl, M., A. Coulbeck, T. Howes and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [RFC 2277] Alvestrand, H., "IETF Policy on Character Sets and
+ Languages", BCP 18, RFC 2277, January 1998.
+
+ [RFC 2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+ [RFC 2459] Housley, R., W. Ford, W. Polk and D. Solo, "Internet
+ X.509 Public Key Infrastructure: Certificate and CRL
+ Profile", RFC 2459, January 1999.
+
+ [RFC 2560] Myers, M., R. Ankney, A. Malpani, S. Galperin and C.
+ Adams, "Online Certificate Status Protocal - OCSP", June
+ 1999.
+
+ [SDN.701] SDN.701, "Message Security Protocol 4.0", Revision A,
+ 1997-02-06.
+
+
+
+
+Housley, et. al. Standards Track [Page 87]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ [X.501] ITU-T Recommendation X.501: Information Technology - Open
+ Systems Interconnection - The Directory: Models, 1993.
+
+ [X.509] ITU-T Recommendation X.509 (1997 E): Information
+ Technology - Open Systems Interconnection - The
+ Directory: Authentication Framework, June 1997.
+
+ [X.520] ITU-T Recommendation X.520: Information Technology - Open
+ Systems Interconnection - The Directory: Selected
+ Attribute Types, 1993.
+
+ [X.660] ITU-T Recommendation X.660 Information Technology - ASN.1
+ encoding rules: Specification of Basic Encoding Rules
+ (BER), Canonical Encoding Rules (CER) and Distinguished
+ Encoding Rules (DER), 1997.
+
+ [X.690] ITU-T Recommendation X.690 Information Technology - Open
+ Systems Interconnection - Procedures for the operation of
+ OSI Registration Authorities: General procedures, 1992.
+
+ [X9.55] ANSI X9.55-1995, Public Key Cryptography For The
+ Financial Services Industry: Extensions To Public Key
+ Certificates And Certificate Revocation Lists, 8
+ December, 1995.
+
+ [PKIXALGS] Bassham, L., Polk, W. and R. Housley, "Algorithms and
+ Identifiers for the Internet X.509 Public Key
+ Infrastructure Certificate and Certificate Revocation
+ Lists (CRL) Profile", RFC 3279, April 2002.
+
+ [PKIXTSA] Adams, C., Cain, P., Pinkas, D. and R. Zuccherato,
+ "Internet X.509 Public Key Infrastructure Time-Stamp
+ Protocol (TSP)", RFC 3161, August 2001.
+
+8 Intellectual Property Rights
+
+ The IETF has been notified of intellectual property rights claimed in
+ regard to some or all of the specification contained in this
+ document. For more information consult the online list of claimed
+ rights (see http://www.ietf.org/ipr.html).
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+
+
+
+Housley, et. al. Standards Track [Page 88]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ standards-related documentation can be found in BCP 11. Copies of
+ claims of rights made available for publication and any assurances of
+ licenses to be made available, or the result of an attempt made to
+ obtain a general license or permission for the use of such
+ proprietary rights by implementors or users of this specification can
+ be obtained from the IETF Secretariat.
+
+9 Security Considerations
+
+ The majority of this specification is devoted to the format and
+ content of certificates and CRLs. Since certificates and CRLs are
+ digitally signed, no additional integrity service is necessary.
+ Neither certificates nor CRLs need be kept secret, and unrestricted
+ and anonymous access to certificates and CRLs has no security
+ implications.
+
+ However, security factors outside the scope of this specification
+ will affect the assurance provided to certificate users. This
+ section highlights critical issues to be considered by implementers,
+ administrators, and users.
+
+ The procedures performed by CAs and RAs to validate the binding of
+ the subject's identity to their public key greatly affect the
+ assurance that ought to be placed in the certificate. Relying
+ parties might wish to review the CA's certificate practice statement.
+ This is particularly important when issuing certificates to other
+ CAs.
+
+ The use of a single key pair for both signature and other purposes is
+ strongly discouraged. Use of separate key pairs for signature and
+ key management provides several benefits to the users. The
+ ramifications associated with loss or disclosure of a signature key
+ are different from loss or disclosure of a key management key. Using
+ separate key pairs permits a balanced and flexible response.
+ Similarly, different validity periods or key lengths for each key
+ pair may be appropriate in some application environments.
+ Unfortunately, some legacy applications (e.g., SSL) use a single key
+ pair for signature and key management.
+
+ The protection afforded private keys is a critical security factor.
+ On a small scale, failure of users to protect their private keys will
+ permit an attacker to masquerade as them, or decrypt their personal
+ information. On a larger scale, compromise of a CA's private signing
+ key may have a catastrophic effect. If an attacker obtains the
+ private key unnoticed, the attacker may issue bogus certificates and
+ CRLs. Existence of bogus certificates and CRLs will undermine
+ confidence in the system. If such a compromise is detected, all
+ certificates issued to the compromised CA MUST be revoked, preventing
+
+
+
+Housley, et. al. Standards Track [Page 89]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ services between its users and users of other CAs. Rebuilding after
+ such a compromise will be problematic, so CAs are advised to
+ implement a combination of strong technical measures (e.g., tamper-
+ resistant cryptographic modules) and appropriate management
+ procedures (e.g., separation of duties) to avoid such an incident.
+
+ 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.
+ CAs SHOULD maintain secure backup for signing keys. The security of
+ the key backup procedures is a critical factor in avoiding key
+ compromise.
+
+ The availability and freshness of revocation information affects the
+ degree of assurance that ought to be placed in a certificate. While
+ certificates expire naturally, events may occur during its natural
+ lifetime which negate the binding between the subject and public key.
+ If revocation information is untimely or unavailable, the assurance
+ associated with the binding is clearly reduced. Relying parties
+ might not be able to process every critical extension that can appear
+ in a CRL. CAs SHOULD take extra care when making revocation
+ information available only through CRLs that contain critical
+ extensions, particularly if support for those extensions is not
+ mandated by this profile. For example, if revocation information is
+ supplied using a combination of delta CRLs and full CRLs, and the
+ delta CRLs are issued more frequently than the full CRLs, then
+ relying parties that cannot handle the critical extensions related to
+ delta CRL processing will not be able to obtain the most recent
+ revocation information. Alternatively, if a full CRL is issued
+ whenever a delta CRL is issued, then timely revocation information
+ will be available to all relying parties. Similarly, implementations
+ of the certification path validation mechanism described in section 6
+ that omit revocation checking provide less assurance than those that
+ support it.
+
+ The certification path validation algorithm depends on the certain
+ knowledge of the public keys (and other information) about one or
+ more trusted CAs. The decision to trust a CA is an important
+ decision as it ultimately determines the trust afforded a
+ certificate. The authenticated distribution of trusted CA public
+ keys (usually in the form of a "self-signed" certificate) is a
+ security critical out-of-band process that is beyond the scope of
+ this specification.
+
+ In addition, where a key compromise or CA failure occurs for a
+ trusted CA, the user will need to modify the information provided to
+ the path validation routine. Selection of too many trusted CAs makes
+
+
+
+
+
+Housley, et. al. Standards Track [Page 90]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ the trusted CA information difficult to maintain. On the other hand,
+ selection of only one trusted CA could limit users to a closed
+ community of users.
+
+ The quality of implementations that process certificates also affects
+ the degree of assurance provided. The path validation algorithm
+ described in section 6 relies upon the integrity of the trusted CA
+ information, and especially the integrity of the public keys
+ associated with the trusted CAs. By substituting public keys for
+ which an attacker has the private key, an attacker could trick the
+ user into accepting false certificates.
+
+ The binding between a key and certificate subject cannot be stronger
+ than the cryptographic module implementation and algorithms used to
+ generate the signature. Short key lengths or weak hash algorithms
+ will limit the utility of a certificate. CAs are encouraged to note
+ advances in cryptology so they can employ strong cryptographic
+ techniques. In addition, CAs SHOULD decline to issue certificates to
+ CAs or end entities that generate weak signatures.
+
+ Inconsistent application of name comparison rules can result in
+ acceptance of invalid X.509 certification paths, or rejection of
+ valid ones. The X.500 series of specifications defines rules for
+ comparing distinguished names that require comparison of strings
+ without regard to case, character set, multi-character white space
+ substring, or leading and trailing white space. This specification
+ relaxes these requirements, requiring support for binary comparison
+ at a minimum.
+
+ CAs MUST encode the distinguished name in the subject field of a CA
+ certificate identically to the distinguished name in the issuer field
+ in certificates issued by that CA. If CAs use different encodings,
+ implementations might fail to recognize name chains for paths that
+ include this certificate. As a consequence, valid paths could be
+ rejected.
+
+ In addition, name constraints for distinguished names MUST be stated
+ identically to the encoding used in the subject field or
+ subjectAltName extension. If not, then name constraints stated as
+ excludedSubTrees will not match and invalid paths will be accepted
+ and name constraints expressed as permittedSubtrees will not match
+ and valid paths will be rejected. To avoid acceptance of invalid
+ paths, CAs SHOULD state name constraints for distinguished names as
+ permittedSubtrees wherever possible.
+
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 91]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+Appendix A. Psuedo-ASN.1 Structures and OIDs
+
+ This section describes data objects used by conforming PKI components
+ in an "ASN.1-like" syntax. This syntax is a hybrid of the 1988 and
+ 1993 ASN.1 syntaxes. The 1988 ASN.1 syntax is augmented with 1993
+ UNIVERSAL Types UniversalString, BMPString and UTF8String.
+
+ The ASN.1 syntax does not permit the inclusion of type statements in
+ the ASN.1 module, and the 1993 ASN.1 standard does not permit use of
+ 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
+ standard.
+
+ This appendix may be converted into 1988 ASN.1 by replacing the
+ definitions for the UNIVERSAL Types with the 1988 catch-all "ANY".
+
+A.1 Explicitly Tagged Module, 1988 Syntax
+
+PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1)
+ security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) }
+
+DEFINITIONS EXPLICIT TAGS ::=
+
+BEGIN
+
+-- EXPORTS ALL --
+
+-- IMPORTS NONE --
+
+-- UNIVERSAL Types defined in 1993 and 1998 ASN.1
+-- and required by this specification
+
+UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING
+ -- UniversalString is defined in ASN.1:1993
+
+BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING
+ -- BMPString is the subtype of UniversalString and models
+ -- the Basic Multilingual Plane of ISO/IEC/ITU 10646-1
+
+UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
+ -- The content of this type conforms to RFC 2279.
+
+-- PKIX specific OIDs
+
+id-pkix OBJECT IDENTIFIER ::=
+ { iso(1) identified-organization(3) dod(6) internet(1)
+ security(5) mechanisms(5) pkix(7) }
+
+
+
+
+Housley, et. al. Standards Track [Page 92]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+-- PKIX arcs
+
+id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
+ -- arc for private certificate extensions
+id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
+ -- arc for policy qualifier types
+id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
+ -- arc for extended key purpose OIDS
+id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
+ -- arc for access descriptors
+
+-- policyQualifierIds for Internet policy qualifiers
+
+id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 }
+ -- OID for CPS qualifier
+id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 }
+ -- OID for user notice qualifier
+
+-- access descriptor definitions
+
+id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }
+id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }
+id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 }
+id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 }
+
+-- attribute data types
+
+Attribute ::= SEQUENCE {
+ type AttributeType,
+ values SET OF AttributeValue }
+ -- at least one value is required
+
+AttributeType ::= OBJECT IDENTIFIER
+
+AttributeValue ::= ANY
+
+AttributeTypeAndValue ::= SEQUENCE {
+ type AttributeType,
+ value AttributeValue }
+
+-- suggested naming attributes: Definition of the following
+-- information object set may be augmented to meet local
+-- requirements. Note that deleting members of the set may
+-- prevent interoperability with conforming implementations.
+-- presented in pairs: the AttributeType followed by the
+-- type definition for the corresponding AttributeValue
+--Arc for standard naming attributes
+id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 }
+
+
+
+Housley, et. al. Standards Track [Page 93]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+-- Naming attributes of type X520name
+
+id-at-name AttributeType ::= { id-at 41 }
+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 {
+ teletexString TeletexString (SIZE (1..ub-name)),
+ printableString PrintableString (SIZE (1..ub-name)),
+ universalString UniversalString (SIZE (1..ub-name)),
+ utf8String UTF8String (SIZE (1..ub-name)),
+ bmpString BMPString (SIZE (1..ub-name)) }
+
+-- Naming attributes of type X520CommonName
+
+id-at-commonName AttributeType ::= { id-at 3 }
+
+X520CommonName ::= CHOICE {
+ teletexString TeletexString (SIZE (1..ub-common-name)),
+ printableString PrintableString (SIZE (1..ub-common-name)),
+ universalString UniversalString (SIZE (1..ub-common-name)),
+ utf8String UTF8String (SIZE (1..ub-common-name)),
+ bmpString BMPString (SIZE (1..ub-common-name)) }
+
+-- Naming attributes of type X520LocalityName
+
+id-at-localityName AttributeType ::= { id-at 7 }
+
+X520LocalityName ::= CHOICE {
+ teletexString TeletexString (SIZE (1..ub-locality-name)),
+ printableString PrintableString (SIZE (1..ub-locality-name)),
+ universalString UniversalString (SIZE (1..ub-locality-name)),
+ utf8String UTF8String (SIZE (1..ub-locality-name)),
+ bmpString BMPString (SIZE (1..ub-locality-name)) }
+
+-- Naming attributes of type X520StateOrProvinceName
+
+id-at-stateOrProvinceName AttributeType ::= { id-at 8 }
+
+X520StateOrProvinceName ::= CHOICE {
+ teletexString TeletexString (SIZE (1..ub-state-name)),
+ printableString PrintableString (SIZE (1..ub-state-name)),
+ universalString UniversalString (SIZE (1..ub-state-name)),
+ utf8String UTF8String (SIZE (1..ub-state-name)),
+ bmpString BMPString (SIZE(1..ub-state-name)) }
+
+
+
+
+Housley, et. al. Standards Track [Page 94]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+-- Naming attributes of type X520OrganizationName
+
+id-at-organizationName AttributeType ::= { id-at 10 }
+
+X520OrganizationName ::= CHOICE {
+ teletexString TeletexString
+ (SIZE (1..ub-organization-name)),
+ printableString PrintableString
+ (SIZE (1..ub-organization-name)),
+ universalString UniversalString
+ (SIZE (1..ub-organization-name)),
+ utf8String UTF8String
+ (SIZE (1..ub-organization-name)),
+ bmpString BMPString
+ (SIZE (1..ub-organization-name)) }
+
+-- Naming attributes of type X520OrganizationalUnitName
+
+id-at-organizationalUnitName AttributeType ::= { id-at 11 }
+
+X520OrganizationalUnitName ::= CHOICE {
+ teletexString TeletexString
+ (SIZE (1..ub-organizational-unit-name)),
+ printableString PrintableString
+ (SIZE (1..ub-organizational-unit-name)),
+ universalString UniversalString
+ (SIZE (1..ub-organizational-unit-name)),
+ utf8String UTF8String
+ (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 }
+
+X520Title ::= CHOICE {
+ teletexString TeletexString (SIZE (1..ub-title)),
+ printableString PrintableString (SIZE (1..ub-title)),
+ universalString UniversalString (SIZE (1..ub-title)),
+ utf8String UTF8String (SIZE (1..ub-title)),
+ bmpString BMPString (SIZE (1..ub-title)) }
+
+-- Naming attributes of type X520dnQualifier
+
+id-at-dnQualifier AttributeType ::= { id-at 46 }
+
+X520dnQualifier ::= PrintableString
+
+
+
+Housley, et. al. Standards Track [Page 95]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+-- Naming attributes of type X520countryName (digraph from IS 3166)
+
+id-at-countryName AttributeType ::= { id-at 6 }
+
+X520countryName ::= PrintableString (SIZE (2))
+
+-- Naming attributes of type X520SerialNumber
+
+id-at-serialNumber AttributeType ::= { id-at 5 }
+
+X520SerialNumber ::= PrintableString (SIZE (1..ub-serial-number))
+
+-- Naming attributes of type X520Pseudonym
+
+id-at-pseudonym AttributeType ::= { id-at 65 }
+
+X520Pseudonym ::= CHOICE {
+ teletexString TeletexString (SIZE (1..ub-pseudonym)),
+ printableString PrintableString (SIZE (1..ub-pseudonym)),
+ universalString UniversalString (SIZE (1..ub-pseudonym)),
+ utf8String UTF8String (SIZE (1..ub-pseudonym)),
+ bmpString BMPString (SIZE (1..ub-pseudonym)) }
+
+-- Naming attributes of type DomainComponent (from RFC 2247)
+
+id-domainComponent AttributeType ::=
+ { 0 9 2342 19200300 100 1 25 }
+
+DomainComponent ::= IA5String
+
+-- Legacy attributes
+
+pkcs-9 OBJECT IDENTIFIER ::=
+ { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 }
+
+id-emailAddress AttributeType ::= { pkcs-9 1 }
+
+EmailAddress ::= IA5String (SIZE (1..ub-emailaddress-length))
+
+-- naming data types --
+
+Name ::= CHOICE { -- only one possibility for now --
+ rdnSequence RDNSequence }
+
+RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
+
+DistinguishedName ::= RDNSequence
+
+
+
+
+Housley, et. al. Standards Track [Page 96]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+RelativeDistinguishedName ::=
+ SET SIZE (1 .. MAX) OF AttributeTypeAndValue
+
+-- Directory string type --
+
+DirectoryString ::= CHOICE {
+ teletexString TeletexString (SIZE (1..MAX)),
+ printableString PrintableString (SIZE (1..MAX)),
+ universalString UniversalString (SIZE (1..MAX)),
+ utf8String UTF8String (SIZE (1..MAX)),
+ bmpString BMPString (SIZE (1..MAX)) }
+
+-- certificate and CRL specific structures begin here
+
+Certificate ::= SEQUENCE {
+ tbsCertificate TBSCertificate,
+ signatureAlgorithm AlgorithmIdentifier,
+ signature BIT STRING }
+
+TBSCertificate ::= SEQUENCE {
+ version [0] Version DEFAULT v1,
+ serialNumber CertificateSerialNumber,
+ signature AlgorithmIdentifier,
+ issuer Name,
+ validity Validity,
+ subject Name,
+ subjectPublicKeyInfo SubjectPublicKeyInfo,
+ issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
+ -- If present, version MUST be v2 or v3
+ subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
+ -- If present, version MUST be v2 or v3
+ extensions [3] Extensions OPTIONAL
+ -- If present, version MUST be v3 -- }
+
+Version ::= INTEGER { v1(0), v2(1), v3(2) }
+
+CertificateSerialNumber ::= INTEGER
+
+Validity ::= SEQUENCE {
+ notBefore Time,
+ notAfter Time }
+
+Time ::= CHOICE {
+ utcTime UTCTime,
+ generalTime GeneralizedTime }
+
+UniqueIdentifier ::= BIT STRING
+
+
+
+
+Housley, et. al. Standards Track [Page 97]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+SubjectPublicKeyInfo ::= SEQUENCE {
+ algorithm AlgorithmIdentifier,
+ subjectPublicKey BIT STRING }
+
+Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
+
+Extension ::= SEQUENCE {
+ extnID OBJECT IDENTIFIER,
+ critical BOOLEAN DEFAULT FALSE,
+ extnValue OCTET STRING }
+
+-- CRL structures
+
+CertificateList ::= SEQUENCE {
+ tbsCertList TBSCertList,
+ signatureAlgorithm AlgorithmIdentifier,
+ signature BIT STRING }
+
+TBSCertList ::= SEQUENCE {
+ version Version OPTIONAL,
+ -- if present, MUST be v2
+ signature AlgorithmIdentifier,
+ issuer Name,
+ thisUpdate Time,
+ nextUpdate Time OPTIONAL,
+ revokedCertificates SEQUENCE OF SEQUENCE {
+ userCertificate CertificateSerialNumber,
+ revocationDate Time,
+ crlEntryExtensions Extensions OPTIONAL
+ -- if present, MUST be v2
+ } OPTIONAL,
+ crlExtensions [0] Extensions OPTIONAL }
+ -- if present, MUST be v2
+
+-- Version, Time, CertificateSerialNumber, and Extensions were
+-- defined earlier for use in the certificate structure
+
+AlgorithmIdentifier ::= SEQUENCE {
+ algorithm OBJECT IDENTIFIER,
+ parameters ANY DEFINED BY algorithm OPTIONAL }
+ -- contains a value of the type
+ -- registered for use with the
+ -- algorithm object identifier value
+
+-- X.400 address syntax starts here
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 98]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ORAddress ::= SEQUENCE {
+ built-in-standard-attributes BuiltInStandardAttributes,
+ built-in-domain-defined-attributes
+ BuiltInDomainDefinedAttributes OPTIONAL,
+ -- see also teletex-domain-defined-attributes
+ extension-attributes ExtensionAttributes OPTIONAL }
+
+-- Built-in Standard Attributes
+
+BuiltInStandardAttributes ::= SEQUENCE {
+ country-name CountryName OPTIONAL,
+ administration-domain-name AdministrationDomainName OPTIONAL,
+ network-address [0] IMPLICIT NetworkAddress OPTIONAL,
+ -- see also extended-network-address
+ terminal-identifier [1] IMPLICIT TerminalIdentifier OPTIONAL,
+ private-domain-name [2] PrivateDomainName OPTIONAL,
+ organization-name [3] IMPLICIT OrganizationName OPTIONAL,
+ -- see also teletex-organization-name
+ numeric-user-identifier [4] IMPLICIT NumericUserIdentifier
+ OPTIONAL,
+ personal-name [5] IMPLICIT PersonalName OPTIONAL,
+ -- see also teletex-personal-name
+ organizational-unit-names [6] IMPLICIT OrganizationalUnitNames
+ OPTIONAL }
+ -- see also teletex-organizational-unit-names
+
+CountryName ::= [APPLICATION 1] CHOICE {
+ x121-dcc-code NumericString
+ (SIZE (ub-country-name-numeric-length)),
+ iso-3166-alpha2-code PrintableString
+ (SIZE (ub-country-name-alpha-length)) }
+
+AdministrationDomainName ::= [APPLICATION 2] CHOICE {
+ numeric NumericString (SIZE (0..ub-domain-name-length)),
+ printable PrintableString (SIZE (0..ub-domain-name-length)) }
+
+NetworkAddress ::= X121Address -- see also extended-network-address
+
+X121Address ::= NumericString (SIZE (1..ub-x121-address-length))
+
+TerminalIdentifier ::= PrintableString (SIZE
+(1..ub-terminal-id-length))
+
+PrivateDomainName ::= CHOICE {
+ numeric NumericString (SIZE (1..ub-domain-name-length)),
+ printable PrintableString (SIZE (1..ub-domain-name-length)) }
+
+
+
+
+
+Housley, et. al. Standards Track [Page 99]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+OrganizationName ::= PrintableString
+ (SIZE (1..ub-organization-name-length))
+ -- see also teletex-organization-name
+
+NumericUserIdentifier ::= NumericString
+ (SIZE (1..ub-numeric-user-id-length))
+
+PersonalName ::= SET {
+ surname [0] IMPLICIT PrintableString
+ (SIZE (1..ub-surname-length)),
+ given-name [1] IMPLICIT PrintableString
+ (SIZE (1..ub-given-name-length)) OPTIONAL,
+ initials [2] IMPLICIT PrintableString
+ (SIZE (1..ub-initials-length)) OPTIONAL,
+ generation-qualifier [3] IMPLICIT PrintableString
+ (SIZE (1..ub-generation-qualifier-length))
+ OPTIONAL }
+ -- see also teletex-personal-name
+
+OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units)
+ OF OrganizationalUnitName
+ -- see also teletex-organizational-unit-names
+
+OrganizationalUnitName ::= PrintableString (SIZE
+ (1..ub-organizational-unit-name-length))
+
+-- Built-in Domain-defined Attributes
+
+BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE
+ (1..ub-domain-defined-attributes) OF
+ BuiltInDomainDefinedAttribute
+
+BuiltInDomainDefinedAttribute ::= SEQUENCE {
+ type PrintableString (SIZE
+ (1..ub-domain-defined-attribute-type-length)),
+ value PrintableString (SIZE
+ (1..ub-domain-defined-attribute-value-length)) }
+
+-- Extension Attributes
+
+ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) OF
+ ExtensionAttribute
+
+ExtensionAttribute ::= SEQUENCE {
+ extension-attribute-type [0] IMPLICIT INTEGER
+ (0..ub-extension-attributes),
+ extension-attribute-value [1]
+ ANY DEFINED BY extension-attribute-type }
+
+
+
+Housley, et. al. Standards Track [Page 100]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+-- Extension types and attribute values
+
+common-name INTEGER ::= 1
+
+CommonName ::= PrintableString (SIZE (1..ub-common-name-length))
+
+teletex-common-name INTEGER ::= 2
+
+TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length))
+
+teletex-organization-name INTEGER ::= 3
+
+TeletexOrganizationName ::=
+ TeletexString (SIZE (1..ub-organization-name-length))
+
+teletex-personal-name INTEGER ::= 4
+
+TeletexPersonalName ::= SET {
+ surname [0] IMPLICIT TeletexString
+ (SIZE (1..ub-surname-length)),
+ given-name [1] IMPLICIT TeletexString
+ (SIZE (1..ub-given-name-length)) OPTIONAL,
+ initials [2] IMPLICIT TeletexString
+ (SIZE (1..ub-initials-length)) OPTIONAL,
+ generation-qualifier [3] IMPLICIT TeletexString
+ (SIZE (1..ub-generation-qualifier-length))
+ OPTIONAL }
+
+teletex-organizational-unit-names INTEGER ::= 5
+
+TeletexOrganizationalUnitNames ::= SEQUENCE SIZE
+ (1..ub-organizational-units) OF TeletexOrganizationalUnitName
+
+TeletexOrganizationalUnitName ::= TeletexString
+ (SIZE (1..ub-organizational-unit-name-length))
+
+pds-name INTEGER ::= 7
+
+PDSName ::= PrintableString (SIZE (1..ub-pds-name-length))
+
+physical-delivery-country-name INTEGER ::= 8
+
+PhysicalDeliveryCountryName ::= CHOICE {
+ x121-dcc-code NumericString (SIZE
+(ub-country-name-numeric-length)),
+ iso-3166-alpha2-code PrintableString
+ (SIZE (ub-country-name-alpha-length)) }
+
+
+
+
+Housley, et. al. Standards Track [Page 101]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+postal-code INTEGER ::= 9
+
+PostalCode ::= CHOICE {
+ numeric-code NumericString (SIZE (1..ub-postal-code-length)),
+ printable-code PrintableString (SIZE (1..ub-postal-code-length)) }
+
+physical-delivery-office-name INTEGER ::= 10
+
+PhysicalDeliveryOfficeName ::= PDSParameter
+
+physical-delivery-office-number INTEGER ::= 11
+
+PhysicalDeliveryOfficeNumber ::= PDSParameter
+
+extension-OR-address-components INTEGER ::= 12
+
+ExtensionORAddressComponents ::= PDSParameter
+
+physical-delivery-personal-name INTEGER ::= 13
+
+PhysicalDeliveryPersonalName ::= PDSParameter
+
+physical-delivery-organization-name INTEGER ::= 14
+
+PhysicalDeliveryOrganizationName ::= PDSParameter
+
+extension-physical-delivery-address-components INTEGER ::= 15
+
+ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter
+
+unformatted-postal-address INTEGER ::= 16
+
+UnformattedPostalAddress ::= SET {
+ printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines)
+ OF PrintableString (SIZE (1..ub-pds-parameter-length))
+ OPTIONAL,
+ teletex-string TeletexString
+ (SIZE (1..ub-unformatted-address-length)) OPTIONAL }
+
+street-address INTEGER ::= 17
+
+StreetAddress ::= PDSParameter
+
+post-office-box-address INTEGER ::= 18
+
+PostOfficeBoxAddress ::= PDSParameter
+
+poste-restante-address INTEGER ::= 19
+
+
+
+Housley, et. al. Standards Track [Page 102]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+PosteRestanteAddress ::= PDSParameter
+
+unique-postal-name INTEGER ::= 20
+
+UniquePostalName ::= PDSParameter
+
+local-postal-attributes INTEGER ::= 21
+
+LocalPostalAttributes ::= PDSParameter
+
+PDSParameter ::= SET {
+ printable-string PrintableString
+ (SIZE(1..ub-pds-parameter-length)) OPTIONAL,
+ teletex-string TeletexString
+ (SIZE(1..ub-pds-parameter-length)) OPTIONAL }
+
+extended-network-address INTEGER ::= 22
+
+ExtendedNetworkAddress ::= CHOICE {
+ e163-4-address SEQUENCE {
+ number [0] IMPLICIT NumericString
+ (SIZE (1..ub-e163-4-number-length)),
+ sub-address [1] IMPLICIT NumericString
+ (SIZE (1..ub-e163-4-sub-address-length))
+ OPTIONAL },
+ psap-address [0] IMPLICIT PresentationAddress }
+
+PresentationAddress ::= SEQUENCE {
+ pSelector [0] EXPLICIT OCTET STRING OPTIONAL,
+ sSelector [1] EXPLICIT OCTET STRING OPTIONAL,
+ tSelector [2] EXPLICIT OCTET STRING OPTIONAL,
+ nAddresses [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING }
+
+terminal-type INTEGER ::= 23
+
+TerminalType ::= INTEGER {
+ telex (3),
+ teletex (4),
+ g3-facsimile (5),
+ g4-facsimile (6),
+ ia5-terminal (7),
+ videotex (8) } (0..ub-integer-options)
+
+-- Extension Domain-defined Attributes
+
+teletex-domain-defined-attributes INTEGER ::= 6
+
+
+
+
+
+Housley, et. al. Standards Track [Page 103]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+TeletexDomainDefinedAttributes ::= SEQUENCE SIZE
+ (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute
+
+TeletexDomainDefinedAttribute ::= SEQUENCE {
+ type TeletexString
+ (SIZE (1..ub-domain-defined-attribute-type-length)),
+ value TeletexString
+ (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
+-- Upper Bounds
+
+-- Upper Bounds
+ub-name INTEGER ::= 32768
+ub-common-name INTEGER ::= 64
+ub-locality-name INTEGER ::= 128
+ub-state-name INTEGER ::= 128
+ub-organization-name INTEGER ::= 64
+ub-organizational-unit-name INTEGER ::= 64
+ub-title INTEGER ::= 64
+ub-serial-number INTEGER ::= 64
+ub-match INTEGER ::= 128
+ub-emailaddress-length INTEGER ::= 128
+ub-common-name-length INTEGER ::= 64
+ub-country-name-alpha-length INTEGER ::= 2
+ub-country-name-numeric-length INTEGER ::= 3
+ub-domain-defined-attributes INTEGER ::= 4
+ub-domain-defined-attribute-type-length INTEGER ::= 8
+ub-domain-defined-attribute-value-length INTEGER ::= 128
+ub-domain-name-length INTEGER ::= 16
+ub-extension-attributes INTEGER ::= 256
+ub-e163-4-number-length INTEGER ::= 15
+ub-e163-4-sub-address-length INTEGER ::= 40
+ub-generation-qualifier-length INTEGER ::= 3
+ub-given-name-length INTEGER ::= 16
+ub-initials-length INTEGER ::= 5
+ub-integer-options INTEGER ::= 256
+ub-numeric-user-id-length INTEGER ::= 32
+ub-organization-name-length INTEGER ::= 64
+ub-organizational-unit-name-length INTEGER ::= 32
+ub-organizational-units INTEGER ::= 4
+ub-pds-name-length INTEGER ::= 16
+ub-pds-parameter-length INTEGER ::= 30
+ub-pds-physical-address-lines INTEGER ::= 6
+ub-postal-code-length INTEGER ::= 16
+ub-pseudonym INTEGER ::= 128
+ub-surname-length INTEGER ::= 40
+
+
+
+Housley, et. al. Standards Track [Page 104]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ub-terminal-id-length INTEGER ::= 24
+ub-unformatted-address-length INTEGER ::= 180
+ub-x121-address-length INTEGER ::= 16
+
+-- Note - upper bounds on string types, such as TeletexString, are
+-- measured in characters. Excepting PrintableString or IA5String, a
+-- significantly greater number of octets will be required to hold
+-- such a value. As a minimum, 16 octets, or twice the specified
+-- upper bound, whichever is the larger, should be allowed for
+-- TeletexString. For UTF8String or UniversalString at least four
+-- times the upper bound should be allowed.
+
+END
+
+A.2 Implicitly Tagged Module, 1988 Syntax
+
+PKIX1Implicit88 { iso(1) identified-organization(3) dod(6) internet(1)
+ security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19) }
+
+DEFINITIONS IMPLICIT TAGS ::=
+
+BEGIN
+
+-- EXPORTS ALL --
+
+IMPORTS
+ id-pe, id-kp, id-qt-unotice, id-qt-cps,
+ -- delete following line if "new" types are supported --
+ BMPString, UTF8String, -- end "new" types --
+ ORAddress, Name, RelativeDistinguishedName,
+ CertificateSerialNumber, Attribute, DirectoryString
+ FROM PKIX1Explicit88 { iso(1) identified-organization(3)
+ dod(6) internet(1) security(5) mechanisms(5) pkix(7)
+ id-mod(0) id-pkix1-explicit(18) };
+
+
+-- ISO arc for standard certificate and CRL extensions
+
+id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29}
+
+-- authority key identifier OID and syntax
+
+id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 }
+
+
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 105]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+AuthorityKeyIdentifier ::= SEQUENCE {
+ keyIdentifier [0] KeyIdentifier OPTIONAL,
+ authorityCertIssuer [1] GeneralNames OPTIONAL,
+ authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }
+ -- authorityCertIssuer and authorityCertSerialNumber MUST both
+ -- be present or both be absent
+
+KeyIdentifier ::= OCTET STRING
+
+-- subject key identifier OID and syntax
+
+id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 }
+
+SubjectKeyIdentifier ::= KeyIdentifier
+
+-- key usage extension OID and syntax
+
+id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 }
+
+KeyUsage ::= BIT STRING {
+ digitalSignature (0),
+ nonRepudiation (1),
+ keyEncipherment (2),
+ dataEncipherment (3),
+ keyAgreement (4),
+ keyCertSign (5),
+ cRLSign (6),
+ encipherOnly (7),
+ decipherOnly (8) }
+
+-- private key usage period extension OID and syntax
+
+id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 }
+
+PrivateKeyUsagePeriod ::= SEQUENCE {
+ notBefore [0] GeneralizedTime OPTIONAL,
+ notAfter [1] GeneralizedTime OPTIONAL }
+ -- either notBefore or notAfter MUST be present
+
+-- certificate policies extension OID and syntax
+
+id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 }
+
+anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificatePolicies 0 }
+
+CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
+
+PolicyInformation ::= SEQUENCE {
+
+
+
+Housley, et. al. Standards Track [Page 106]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ policyIdentifier CertPolicyId,
+ policyQualifiers SEQUENCE SIZE (1..MAX) OF
+ PolicyQualifierInfo OPTIONAL }
+
+CertPolicyId ::= OBJECT IDENTIFIER
+
+PolicyQualifierInfo ::= SEQUENCE {
+ policyQualifierId PolicyQualifierId,
+ qualifier ANY DEFINED BY policyQualifierId }
+
+-- Implementations that recognize additional policy qualifiers MUST
+-- augment the following definition for PolicyQualifierId
+
+PolicyQualifierId ::=
+ OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )
+
+-- CPS pointer qualifier
+
+CPSuri ::= IA5String
+
+-- user notice qualifier
+
+UserNotice ::= SEQUENCE {
+ noticeRef NoticeReference OPTIONAL,
+ explicitText DisplayText OPTIONAL}
+
+NoticeReference ::= SEQUENCE {
+ organization DisplayText,
+ noticeNumbers SEQUENCE OF INTEGER }
+
+DisplayText ::= CHOICE {
+ ia5String IA5String (SIZE (1..200)),
+ visibleString VisibleString (SIZE (1..200)),
+ bmpString BMPString (SIZE (1..200)),
+ utf8String UTF8String (SIZE (1..200)) }
+
+-- policy mapping extension OID and syntax
+
+id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 }
+
+PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
+ issuerDomainPolicy CertPolicyId,
+ subjectDomainPolicy CertPolicyId }
+
+-- subject alternative name extension OID and syntax
+
+id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 }
+
+
+
+
+Housley, et. al. Standards Track [Page 107]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+SubjectAltName ::= GeneralNames
+
+GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
+
+GeneralName ::= CHOICE {
+ otherName [0] AnotherName,
+ rfc822Name [1] IA5String,
+ dNSName [2] IA5String,
+ x400Address [3] ORAddress,
+ directoryName [4] Name,
+ ediPartyName [5] EDIPartyName,
+ uniformResourceIdentifier [6] IA5String,
+ iPAddress [7] OCTET STRING,
+ registeredID [8] OBJECT IDENTIFIER }
+
+-- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as
+-- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax
+
+AnotherName ::= SEQUENCE {
+ type-id OBJECT IDENTIFIER,
+ value [0] EXPLICIT ANY DEFINED BY type-id }
+
+EDIPartyName ::= SEQUENCE {
+ nameAssigner [0] DirectoryString OPTIONAL,
+ partyName [1] DirectoryString }
+
+-- issuer alternative name extension OID and syntax
+
+id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 }
+
+IssuerAltName ::= GeneralNames
+
+id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 }
+
+SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute
+
+-- basic constraints extension OID and syntax
+
+id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 }
+
+BasicConstraints ::= SEQUENCE {
+ cA BOOLEAN DEFAULT FALSE,
+ pathLenConstraint INTEGER (0..MAX) OPTIONAL }
+
+-- name constraints extension OID and syntax
+
+id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 }
+
+
+
+
+Housley, et. al. Standards Track [Page 108]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+NameConstraints ::= SEQUENCE {
+ permittedSubtrees [0] GeneralSubtrees OPTIONAL,
+ excludedSubtrees [1] GeneralSubtrees OPTIONAL }
+
+GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
+
+GeneralSubtree ::= SEQUENCE {
+ base GeneralName,
+ minimum [0] BaseDistance DEFAULT 0,
+ maximum [1] BaseDistance OPTIONAL }
+
+BaseDistance ::= INTEGER (0..MAX)
+
+-- policy constraints extension OID and syntax
+
+id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 }
+
+PolicyConstraints ::= SEQUENCE {
+ requireExplicitPolicy [0] SkipCerts OPTIONAL,
+ inhibitPolicyMapping [1] SkipCerts OPTIONAL }
+
+SkipCerts ::= INTEGER (0..MAX)
+
+-- CRL distribution points extension OID and syntax
+
+id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31}
+
+CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
+
+DistributionPoint ::= SEQUENCE {
+ distributionPoint [0] DistributionPointName OPTIONAL,
+ reasons [1] ReasonFlags OPTIONAL,
+ cRLIssuer [2] GeneralNames OPTIONAL }
+
+DistributionPointName ::= CHOICE {
+ fullName [0] GeneralNames,
+ nameRelativeToCRLIssuer [1] RelativeDistinguishedName }
+
+ReasonFlags ::= BIT STRING {
+ unused (0),
+ keyCompromise (1),
+ cACompromise (2),
+ affiliationChanged (3),
+ superseded (4),
+ cessationOfOperation (5),
+ certificateHold (6),
+ privilegeWithdrawn (7),
+ aACompromise (8) }
+
+
+
+Housley, et. al. Standards Track [Page 109]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+-- extended key usage extension OID and syntax
+
+id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37}
+
+ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
+
+
+KeyPurposeId ::= OBJECT IDENTIFIER
+
+-- permit unspecified key uses
+
+anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 }
+
+-- extended key purpose OIDs
+
+id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
+id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 }
+id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 }
+id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 }
+id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }
+id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }
+
+-- inhibit any policy OID and syntax
+
+id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 }
+
+InhibitAnyPolicy ::= SkipCerts
+
+-- freshest (delta)CRL extension OID and syntax
+
+id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 }
+
+FreshestCRL ::= CRLDistributionPoints
+
+-- authority info access
+
+id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }
+
+AuthorityInfoAccessSyntax ::=
+ SEQUENCE SIZE (1..MAX) OF AccessDescription
+
+AccessDescription ::= SEQUENCE {
+ accessMethod OBJECT IDENTIFIER,
+ accessLocation GeneralName }
+
+-- subject info access
+
+id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 }
+
+
+
+Housley, et. al. Standards Track [Page 110]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+SubjectInfoAccessSyntax ::=
+ SEQUENCE SIZE (1..MAX) OF AccessDescription
+
+-- CRL number extension OID and syntax
+
+id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }
+
+CRLNumber ::= INTEGER (0..MAX)
+
+-- issuing distribution point extension OID and syntax
+
+id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 }
+
+IssuingDistributionPoint ::= SEQUENCE {
+ distributionPoint [0] DistributionPointName OPTIONAL,
+ onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE,
+ onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE,
+ onlySomeReasons [3] ReasonFlags OPTIONAL,
+ indirectCRL [4] BOOLEAN DEFAULT FALSE,
+ onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
+
+id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }
+
+BaseCRLNumber ::= CRLNumber
+
+-- CRL reasons extension OID and syntax
+
+id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 }
+
+CRLReason ::= ENUMERATED {
+ unspecified (0),
+ keyCompromise (1),
+ cACompromise (2),
+ affiliationChanged (3),
+ superseded (4),
+ cessationOfOperation (5),
+ certificateHold (6),
+ removeFromCRL (8),
+ privilegeWithdrawn (9),
+ aACompromise (10) }
+
+-- certificate issuer CRL entry extension OID and syntax
+
+id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 }
+
+CertificateIssuer ::= GeneralNames
+
+-- hold instruction extension OID and syntax
+
+
+
+Housley, et. al. Standards Track [Page 111]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 }
+
+HoldInstructionCode ::= OBJECT IDENTIFIER
+
+-- ANSI x9 holdinstructions
+
+-- ANSI x9 arc holdinstruction arc
+
+holdInstruction OBJECT IDENTIFIER ::=
+ {joint-iso-itu-t(2) member-body(2) us(840) x9cm(10040) 2}
+
+-- ANSI X9 holdinstructions referenced by this standard
+
+id-holdinstruction-none OBJECT IDENTIFIER ::=
+ {holdInstruction 1} -- deprecated
+
+id-holdinstruction-callissuer OBJECT IDENTIFIER ::=
+ {holdInstruction 2}
+
+id-holdinstruction-reject OBJECT IDENTIFIER ::=
+ {holdInstruction 3}
+
+-- invalidity date CRL entry extension OID and syntax
+
+id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 }
+
+InvalidityDate ::= GeneralizedTime
+
+END
+
+Appendix B. ASN.1 Notes
+
+ CAs MUST force the serialNumber to be a non-negative integer, that
+ is, the sign bit in the DER encoding of the INTEGER value MUST be
+ zero - this can be done by adding a leading (leftmost) `00'H octet if
+ necessary. This removes a potential ambiguity in mapping between a
+ string of octets and an integer value.
+
+ As noted in section 4.1.2.2, serial numbers can be expected to
+ contain long integers. Certificate users MUST be able to handle
+ serialNumber values up to 20 octets in length. Conformant CAs MUST
+ NOT use serialNumber values longer than 20 octets.
+
+ As noted in section 5.2.3, CRL numbers can be expected to contain
+ long integers. CRL validators MUST be able to handle cRLNumber
+ values up to 20 octets in length. Conformant CRL issuers MUST NOT
+ use cRLNumber values longer than 20 octets.
+
+
+
+
+Housley, et. al. Standards Track [Page 112]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1
+ constructs. A valid ASN.1 sequence will have zero or more entries.
+ The SIZE (1..MAX) construct constrains the sequence to have at least
+ one entry. MAX indicates the upper bound is unspecified.
+ Implementations are free to choose an upper bound that suits their
+ environment.
+
+ The construct "positiveInt ::= INTEGER (0..MAX)" defines positiveInt
+ as a subtype of INTEGER containing integers greater than or equal to
+ zero. The upper bound is unspecified. Implementations are free to
+ select an upper bound that suits their environment.
+
+ The character string type PrintableString supports a very basic Latin
+ character set: the lower case letters 'a' through 'z', upper case
+ letters 'A' through 'Z', the digits '0' through '9', eleven special
+ characters ' = ( ) + , - . / : ? and space.
+
+ Implementers should note that the at sign ('@') and underscore ('_')
+ characters are not supported by the ASN.1 type PrintableString.
+ These characters often appear in internet addresses. Such addresses
+ MUST be encoded using an ASN.1 type that supports them. They are
+ usually encoded as IA5String in either the emailAddress attribute
+ within a distinguished name or the rfc822Name field of GeneralName.
+ Conforming implementations MUST NOT encode strings which include
+ either the at sign or underscore character as PrintableString.
+
+ The character string type TeletexString is a superset of
+ PrintableString. TeletexString supports a fairly standard (ASCII-
+ like) Latin character set, Latin characters with non-spacing accents
+ and Japanese characters.
+
+ Named bit lists are BIT STRINGs where the values have been assigned
+ names. This specification makes use of named bit lists in the
+ definitions for the key usage, CRL distribution points and freshest
+ CRL certificate extensions, as well as the freshest CRL and issuing
+ distribution point CRL extensions. When DER encoding a named bit
+ list, trailing zeroes MUST be omitted. That is, the encoded value
+ ends with the last named bit that is set to one.
+
+ The character string type UniversalString supports any of the
+ characters allowed by ISO 10646-1 [ISO 10646]. ISO 10646-1 is the
+ Universal multiple-octet coded Character Set (UCS). ISO 10646-1
+ specifies the architecture and the "basic multilingual plane" -- a
+ large standard character set which includes all major world character
+ standards.
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 113]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ The character string type UTF8String was introduced in the 1997
+ version of ASN.1, and UTF8String was added to the list of choices for
+ DirectoryString in the 2001 version of X.520 [X.520]. UTF8String is
+ a universal type and has been assigned tag number 12. The content of
+ UTF8String was defined by RFC 2044 [RFC 2044] and updated in RFC 2279
+ [RFC 2279].
+
+ In anticipation of these changes, and in conformance with IETF Best
+ Practices codified in RFC 2277 [RFC 2277], IETF Policy on Character
+ Sets and Languages, this document includes UTF8String as a choice in
+ DirectoryString and the CPS qualifier extensions.
+
+ Implementers should note that the DER encoding of the SET OF values
+ requires ordering of the encodings of the values. In particular,
+ this issue arises with respect to distinguished names.
+
+ Implementers should note that the DER encoding of SET or SEQUENCE
+ components whose value is the DEFAULT omit the component from the
+ encoded certificate or CRL. For example, a BasicConstraints
+ extension whose cA value is FALSE would omit the cA boolean from the
+ encoded certificate.
+
+ Object Identifiers (OIDs) are used throughout this specification to
+ identify certificate policies, public key and signature algorithms,
+ certificate extensions, etc. There is no maximum size for OIDs.
+ This specification mandates support for OIDs which have arc elements
+ with values that are less than 2^28, that is, they MUST be between 0
+ and 268,435,455, inclusive. This allows each arc element to be
+ represented within a single 32 bit word. Implementations MUST also
+ support OIDs where the length of the dotted decimal (see [RFC 2252],
+ section 4.1) string representation can be up to 100 bytes
+ (inclusive). Implementations MUST be able to handle OIDs with up to
+ 20 elements (inclusive). CAs SHOULD NOT issue certificates which
+ contain OIDs that exceed these requirements. Likewise, CRL issuers
+ SHOULD NOT issue CRLs which contain OIDs that exceed these
+ requirements.
+
+ Implementors are warned that the X.500 standards community has
+ developed a series of extensibility rules. These rules determine
+ when an ASN.1 definition can be changed without assigning a new
+ object identifier (OID). For example, at least two extension
+ definitions included in RFC 2459 [RFC 2459], the predecessor to this
+ profile document, have different ASN.1 definitions in this
+ specification, but the same OID is used. If unknown elements appear
+ within an extension, and the extension is not marked critical, those
+ unknown elements ought to be ignored, as follows:
+
+ (a) ignore all unknown bit name assignments within a bit string;
+
+
+
+Housley, et. al. Standards Track [Page 114]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ (b) ignore all unknown named numbers in an ENUMERATED type or
+ INTEGER type that is being used in the enumerated style, provided
+ the number occurs as an optional element of a SET or SEQUENCE; and
+
+ (c) ignore all unknown elements in SETs, at the end of SEQUENCEs,
+ or in CHOICEs where the CHOICE is itself an optional element of a
+ SET or SEQUENCE.
+
+ If an extension containing unexpected values is marked critical, the
+ implementation MUST reject the certificate or CRL containing the
+ unrecognized extension.
+
+Appendix C. Examples
+
+ This section contains four examples: three certificates and a CRL.
+ The first two certificates and the CRL comprise a minimal
+ certification path.
+
+ Section C.1 contains an annotated hex dump of a "self-signed"
+ certificate issued by a CA whose distinguished name is
+ cn=us,o=gov,ou=nist. The certificate contains a DSA public key with
+ parameters, and is signed by the corresponding DSA private key.
+
+ Section C.2 contains an annotated hex dump of an end entity
+ certificate. The end entity certificate contains a DSA public key,
+ and is signed by the private key corresponding to the "self-signed"
+ certificate in section C.1.
+
+ Section C.3 contains a dump of an end entity certificate which
+ contains an RSA public key and is signed with RSA and MD5. This
+ certificate is not part of the minimal certification path.
+
+ Section C.4 contains an annotated hex dump of a CRL. The CRL is
+ issued by the CA whose distinguished name is cn=us,o=gov,ou=nist and
+ the list of revoked certificates includes the end entity certificate
+ presented in C.2.
+
+ The certificates were processed using Peter Gutman's dumpasn1 utility
+ to generate the output. The source for the dumpasn1 utility is
+ available at <http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c>. The
+ binaries for the certificates and CRLs are available at
+ <http://csrc.nist.gov/pki/pkixtools>.
+
+C.1 Certificate
+
+ This section contains an annotated hex dump of a 699 byte version 3
+ certificate. The certificate contains the following information:
+ (a) the serial number is 23 (17 hex);
+
+
+
+Housley, et. al. Standards Track [Page 115]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ (b) the certificate is signed with DSA and the SHA-1 hash algorithm;
+ (c) the issuer's distinguished name is OU=NIST; O=gov; C=US
+ (d) and the subject's distinguished name is OU=NIST; O=gov; C=US
+ (e) the certificate was issued on June 30, 1997 and will expire on
+ December 31, 1997;
+ (f) the certificate contains a 1024 bit DSA public key with
+ parameters;
+ (g) the certificate contains a subject key identifier extension
+ generated using method (1) of section 4.2.1.2; and
+ (h) the certificate is a CA certificate (as indicated through the
+ basic constraints extension.)
+
+ 0 30 699: SEQUENCE {
+ 4 30 635: SEQUENCE {
+ 8 A0 3: [0] {
+ 10 02 1: INTEGER 2
+ : }
+ 13 02 1: INTEGER 17
+ 16 30 9: SEQUENCE {
+ 18 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
+ : }
+ 27 30 42: SEQUENCE {
+ 29 31 11: SET {
+ 31 30 9: SEQUENCE {
+ 33 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
+ 38 13 2: PrintableString 'US'
+ : }
+ : }
+ 42 31 12: SET {
+ 44 30 10: SEQUENCE {
+ 46 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
+ 51 13 3: PrintableString 'gov'
+ : }
+ : }
+ 56 31 13: SET {
+ 58 30 11: SEQUENCE {
+ 60 06 3: OBJECT IDENTIFIER
+ : organizationalUnitName (2 5 4 11)
+ 65 13 4: PrintableString 'NIST'
+ : }
+ : }
+ : }
+ 71 30 30: SEQUENCE {
+ 73 17 13: UTCTime '970630000000Z'
+ 88 17 13: UTCTime '971231000000Z'
+ : }
+103 30 42: SEQUENCE {
+105 31 11: SET {
+
+
+
+Housley, et. al. Standards Track [Page 116]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+107 30 9: SEQUENCE {
+109 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
+114 13 2: PrintableString 'US'
+ : }
+ : }
+118 31 12: SET {
+120 30 10: SEQUENCE {
+122 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
+127 13 3: PrintableString 'gov'
+ : }
+ : }
+132 31 13: SET {
+134 30 11: SEQUENCE {
+136 06 3: OBJECT IDENTIFIER
+ : organizationalUnitName (2 5 4 11)
+141 13 4: PrintableString 'NIST'
+ : }
+ : }
+ : }
+147 30 440: SEQUENCE {
+151 30 300: SEQUENCE {
+155 06 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1)
+164 30 287: SEQUENCE {
+168 02 129: INTEGER
+ : 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC
+ : FB 95 32 AC 01 12 33 B9 E0 1C AD 90 9B BC
+ : 48 54 9E F3 94 77 3C 2C 71 35 55 E6 FE 4F
+ : 22 CB D5 D8 3E 89 93 33 4D FC BD 4F 41 64
+ : 3E A2 98 70 EC 31 B4 50 DE EB F1 98 28 0A
+ : C9 3E 44 B3 FD 22 97 96 83 D0 18 A3 E3 BD
+ : 35 5B FF EE A3 21 72 6A 7B 96 DA B9 3F 1E
+ : 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A
+ : FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48
+ : 63 FE 43
+300 02 21: INTEGER
+ : 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA
+ : 55 F7 7D 57 74 81 E5
+323 02 129: INTEGER
+ : 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91
+ : C0 8E 47 F1 0A C3 01 47 C2 44 42 36 A9 92
+ : 81 DE 57 C5 E0 68 86 58 00 7B 1F F9 9B 77
+ : A1 C5 10 A5 80 91 78 51 51 3C F6 FC FC CC
+ : 46 C6 81 78 92 84 3D F4 93 3D 0C 38 7E 1A
+ : 5B 99 4E AB 14 64 F6 0C 21 22 4E 28 08 9C
+ : 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 39 A2
+ : 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF
+ : F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE
+ : 1E 57 18
+
+
+
+Housley, et. al. Standards Track [Page 117]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ : }
+ : }
+455 03 133: BIT STRING 0 unused bits, encapsulates {
+459 02 129: INTEGER
+ : 00 B5 9E 1F 49 04 47 D1 DB F5 3A DD CA 04
+ : 75 E8 DD 75 F6 9B 8A B1 97 D6 59 69 82 D3
+ : 03 4D FD 3B 36 5F 4A F2 D1 4E C1 07 F5 D1
+ : 2A D3 78 77 63 56 EA 96 61 4D 42 0B 7A 1D
+ : FB AB 91 A4 CE DE EF 77 C8 E5 EF 20 AE A6
+ : 28 48 AF BE 69 C3 6A A5 30 F2 C2 B9 D9 82
+ : 2B 7D D9 C4 84 1F DE 0D E8 54 D7 1B 99 2E
+ : B3 D0 88 F6 D6 63 9B A7 E2 0E 82 D4 3B 8A
+ : 68 1B 06 56 31 59 0B 49 EB 99 A5 D5 81 41
+ : 7B C9 55
+ : }
+ : }
+591 A3 50: [3] {
+593 30 48: SEQUENCE {
+595 30 29: SEQUENCE {
+597 06 3: OBJECT IDENTIFIER
+ : subjectKeyIdentifier (2 5 29 14)
+602 04 22: OCTET STRING, encapsulates {
+604 04 20: OCTET STRING
+ : 86 CA A5 22 81 62 EF AD 0A 89 BC AD 72 41
+ : 2C 29 49 F4 86 56
+ : }
+ : }
+626 30 15: SEQUENCE {
+628 06 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19)
+633 01 1: BOOLEAN TRUE
+636 04 5: OCTET STRING, encapsulates {
+638 30 3: SEQUENCE {
+640 01 1: BOOLEAN TRUE
+ : }
+ : }
+ : }
+ : }
+ : }
+ : }
+643 30 9: SEQUENCE {
+645 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
+ : }
+654 03 47: BIT STRING 0 unused bits, encapsulates {
+657 30 44: SEQUENCE {
+659 02 20: INTEGER
+ : 43 1B CF 29 25 45 C0 4E 52 E7 7D D6 FC B1
+ : 66 4C 83 CF 2D 77
+681 02 20: INTEGER
+
+
+
+Housley, et. al. Standards Track [Page 118]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ : 0B 5B 9A 24 11 98 E8 F3 86 90 04 F6 08 A9
+ : E1 8D A5 CC 3A D4
+ : }
+ : }
+ : }
+
+C.2 Certificate
+
+ This section contains an annotated hex dump of a 730 byte version 3
+ certificate. The certificate contains the following information:
+ (a) the serial number is 18 (12 hex);
+ (b) the certificate is signed with DSA and the SHA-1 hash algorithm;
+ (c) the issuer's distinguished name is OU=nist; O=gov; C=US
+ (d) and the subject's distinguished name is CN=Tim Polk; OU=nist;
+ O=gov; C=US
+ (e) the certificate was valid from July 30, 1997 through December 1,
+ 1997;
+ (f) the certificate contains a 1024 bit DSA public key;
+ (g) the certificate is an end entity certificate, as the basic
+ constraints extension is not present;
+ (h) the certificate contains an authority key identifier extension
+ matching the subject key identifier of the certificate in Appendix
+ C.1; and
+ (i) the certificate includes one alternative name - an RFC 822
+ address of "wpolk@nist.gov".
+
+ 0 30 730: SEQUENCE {
+ 4 30 665: SEQUENCE {
+ 8 A0 3: [0] {
+ 10 02 1: INTEGER 2
+ : }
+ 13 02 1: INTEGER 18
+ 16 30 9: SEQUENCE {
+ 18 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
+ : }
+ 27 30 42: SEQUENCE {
+ 29 31 11: SET {
+ 31 30 9: SEQUENCE {
+ 33 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
+ 38 13 2: PrintableString 'US'
+ : }
+ : }
+ 42 31 12: SET {
+ 44 30 10: SEQUENCE {
+ 46 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
+ 51 13 3: PrintableString 'gov'
+ : }
+ : }
+
+
+
+Housley, et. al. Standards Track [Page 119]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ 56 31 13: SET {
+ 58 30 11: SEQUENCE {
+ 60 06 3: OBJECT IDENTIFIER
+ : organizationalUnitName (2 5 4 11)
+ 65 13 4: PrintableString 'NIST'
+ : }
+ : }
+ : }
+ 71 30 30: SEQUENCE {
+ 73 17 13: UTCTime '970730000000Z'
+ 88 17 13: UTCTime '971201000000Z'
+ : }
+ 103 30 61: SEQUENCE {
+ 105 31 11: SET {
+ 107 30 9: SEQUENCE {
+ 109 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
+ 114 13 2: PrintableString 'US'
+ : }
+ : }
+ 118 31 12: SET {
+ 120 30 10: SEQUENCE {
+ 122 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
+ 127 13 3: PrintableString 'gov'
+ : }
+ : }
+ 132 31 13: SET {
+ 134 30 11: SEQUENCE {
+ 136 06 3: OBJECT IDENTIFIER
+ : organizationalUnitName (2 5 4 11)
+ 141 13 4: PrintableString 'NIST'
+ : }
+ : }
+ 147 31 17: SET {
+ 149 30 15: SEQUENCE {
+ 151 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
+ 156 13 8: PrintableString 'Tim Polk'
+ : }
+ : }
+ : }
+ 166 30 439: SEQUENCE {
+ 170 30 300: SEQUENCE {
+ 174 06 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1)
+ 183 30 287: SEQUENCE {
+ 187 02 129: INTEGER
+ : 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC
+ : FB 95 32 AC 01 12 33 B9 E0 1C AD 90 9B BC
+ : 48 54 9E F3 94 77 3C 2C 71 35 55 E6 FE 4F
+ : 22 CB D5 D8 3E 89 93 33 4D FC BD 4F 41 64
+
+
+
+Housley, et. al. Standards Track [Page 120]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ : 3E A2 98 70 EC 31 B4 50 DE EB F1 98 28 0A
+ : C9 3E 44 B3 FD 22 97 96 83 D0 18 A3 E3 BD
+ : 35 5B FF EE A3 21 72 6A 7B 96 DA B9 3F 1E
+ : 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A
+ : FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48
+ : 63 FE 43
+ 319 02 21: INTEGER
+ : 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA
+ : 55 F7 7D 57 74 81 E5
+ 342 02 129: INTEGER
+ : 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91
+ : C0 8E 47 F1 0A C3 01 47 C2 44 42 36 A9 92
+ : 81 DE 57 C5 E0 68 86 58 00 7B 1F F9 9B 77
+ : A1 C5 10 A5 80 91 78 51 51 3C F6 FC FC CC
+ : 46 C6 81 78 92 84 3D F4 93 3D 0C 38 7E 1A
+ : 5B 99 4E AB 14 64 F6 0C 21 22 4E 28 08 9C
+ : 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 39 A2
+ : 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF
+ : F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE
+ : 1E 57 18
+ : }
+ : }
+ 474 03 132: BIT STRING 0 unused bits, encapsulates {
+ 478 02 128: INTEGER
+ : 30 B6 75 F7 7C 20 31 AE 38 BB 7E 0D 2B AB
+ : A0 9C 4B DF 20 D5 24 13 3C CD 98 E5 5F 6C
+ : B7 C1 BA 4A BA A9 95 80 53 F0 0D 72 DC 33
+ : 37 F4 01 0B F5 04 1F 9D 2E 1F 62 D8 84 3A
+ : 9B 25 09 5A 2D C8 46 8E 2B D4 F5 0D 3B C7
+ : 2D C6 6C B9 98 C1 25 3A 44 4E 8E CA 95 61
+ : 35 7C CE 15 31 5C 23 13 1E A2 05 D1 7A 24
+ : 1C CB D3 72 09 90 FF 9B 9D 28 C0 A1 0A EC
+ : 46 9F 0D B8 D0 DC D0 18 A6 2B 5E F9 8F B5
+ : 95 BE
+ : }
+ : }
+ 609 A3 62: [3] {
+ 611 30 60: SEQUENCE {
+ 613 30 25: SEQUENCE {
+ 615 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17)
+ 620 04 18: OCTET STRING, encapsulates {
+ 622 30 16: SEQUENCE {
+ 624 81 14: [1] 'wpolk@nist.gov'
+ : }
+ : }
+ : }
+ 640 30 31: SEQUENCE {
+ 642 06 3: OBJECT IDENTIFIER
+
+
+
+Housley, et. al. Standards Track [Page 121]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ : authorityKeyIdentifier (2 5 29 35)
+ 647 04 24: OCTET STRING, encapsulates {
+ 649 30 22: SEQUENCE {
+ 651 80 20: [0]
+ : 86 CA A5 22 81 62 EF AD 0A 89 BC AD 72
+ : 41 2C 29 49 F4 86 56
+ : }
+ : }
+ : }
+ : }
+ : }
+ : }
+ 673 30 9: SEQUENCE {
+ 675 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
+ : }
+ 684 03 48: BIT STRING 0 unused bits, encapsulates {
+ 687 30 45: SEQUENCE {
+ 689 02 20: INTEGER
+ : 36 97 CB E3 B4 2C E1 BB 61 A9 D3 CC 24 CC
+ : 22 92 9F F4 F5 87
+ 711 02 21: INTEGER
+ : 00 AB C9 79 AF D2 16 1C A9 E3 68 A9 14 10
+ : B4 A0 2E FF 22 5A 73
+ : }
+ : }
+ : }
+
+C.3 End Entity Certificate Using RSA
+
+ This section contains an annotated hex dump of a 654 byte version 3
+ certificate. The certificate contains the following information:
+ (a) the serial number is 256;
+ (b) the certificate is signed with RSA and the SHA-1 hash algorithm;
+ (c) the issuer's distinguished name is OU=NIST; O=gov; C=US
+ (d) and the subject's distinguished name is CN=Tim Polk; OU=NIST;
+ O=gov; C=US
+ (e) the certificate was issued on May 21, 1996 at 09:58:26 and
+ expired on May 21, 1997 at 09:58:26;
+ (f) the certificate contains a 1024 bit RSA public key;
+ (g) the certificate is an end entity certificate (not a CA
+ certificate);
+ (h) the certificate includes an alternative subject name of
+ "<http://www.itl.nist.gov/div893/staff/polk/index.html>" and an
+ alternative issuer name of "<http://www.nist.gov/>" - both are URLs;
+ (i) the certificate include an authority key identifier extension
+ and a certificate policies extension specifying the policy OID
+ 2.16.840.1.101.3.2.1.48.9; and
+
+
+
+
+Housley, et. al. Standards Track [Page 122]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ (j) the certificate includes a critical key usage extension
+ specifying that the public key is intended for verification of
+ digital signatures.
+
+ 0 30 654: SEQUENCE {
+ 4 30 503: SEQUENCE {
+ 8 A0 3: [0] {
+ 10 02 1: INTEGER 2
+ : }
+ 13 02 2: INTEGER 256
+ 17 30 13: SEQUENCE {
+ 19 06 9: OBJECT IDENTIFIER
+ : sha1withRSAEncryption (1 2 840 113549 1 1 5)
+ 30 05 0: NULL
+ : }
+ 32 30 42: SEQUENCE {
+ 34 31 11: SET {
+ 36 30 9: SEQUENCE {
+ 38 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
+ 43 13 2: PrintableString 'US'
+ : }
+ : }
+ 47 31 12: SET {
+ 49 30 10: SEQUENCE {
+ 51 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
+ 56 13 3: PrintableString 'gov'
+ : }
+ : }
+ 61 31 13: SET {
+ 63 30 11: SEQUENCE {
+ 65 06 3: OBJECT IDENTIFIER
+ : organizationalUnitName (2 5 4 11)
+ 70 13 4: PrintableString 'NIST'
+ : }
+ : }
+ : }
+ 76 30 30: SEQUENCE {
+ 78 17 13: UTCTime '960521095826Z'
+ 93 17 13: UTCTime '970521095826Z'
+ : }
+108 30 61: SEQUENCE {
+110 31 11: SET {
+112 30 9: SEQUENCE {
+114 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
+119 13 2: PrintableString 'US'
+ : }
+ : }
+123 31 12: SET {
+
+
+
+Housley, et. al. Standards Track [Page 123]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+125 30 10: SEQUENCE {
+127 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
+132 13 3: PrintableString 'gov'
+ : }
+ : }
+137 31 13: SET {
+139 30 11: SEQUENCE {
+141 06 3: OBJECT IDENTIFIER
+ : organizationalUnitName (2 5 4 11)
+146 13 4: PrintableString 'NIST'
+ : }
+ : }
+152 31 17: SET {
+154 30 15: SEQUENCE {
+156 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
+161 13 8: PrintableString 'Tim Polk'
+ : }
+ : }
+ : }
+171 30 159: SEQUENCE {
+174 30 13: SEQUENCE {
+176 06 9: OBJECT IDENTIFIER
+ : rsaEncryption (1 2 840 113549 1 1 1)
+187 05 0: NULL
+ : }
+189 03 141: BIT STRING 0 unused bits, encapsulates {
+193 30 137: SEQUENCE {
+196 02 129: INTEGER
+ : 00 E1 6A E4 03 30 97 02 3C F4 10 F3 B5 1E
+ : 4D 7F 14 7B F6 F5 D0 78 E9 A4 8A F0 A3 75
+ : EC ED B6 56 96 7F 88 99 85 9A F2 3E 68 77
+ : 87 EB 9E D1 9F C0 B4 17 DC AB 89 23 A4 1D
+ : 7E 16 23 4C 4F A8 4D F5 31 B8 7C AA E3 1A
+ : 49 09 F4 4B 26 DB 27 67 30 82 12 01 4A E9
+ : 1A B6 C1 0C 53 8B 6C FC 2F 7A 43 EC 33 36
+ : 7E 32 B2 7B D5 AA CF 01 14 C6 12 EC 13 F2
+ : 2D 14 7A 8B 21 58 14 13 4C 46 A3 9A F2 16
+ : 95 FF 23
+328 02 3: INTEGER 65537
+ : }
+ : }
+ : }
+333 A3 175: [3] {
+336 30 172: SEQUENCE {
+339 30 63: SEQUENCE {
+341 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17)
+346 04 56: OCTET STRING, encapsulates {
+348 30 54: SEQUENCE {
+
+
+
+Housley, et. al. Standards Track [Page 124]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+350 86 52: [6]
+ : 'http://www.itl.nist.gov/div893/staff/'
+ : 'polk/index.html'
+ : }
+ : }
+ : }
+404 30 31: SEQUENCE {
+406 06 3: OBJECT IDENTIFIER issuerAltName (2 5 29 18)
+411 04 24: OCTET STRING, encapsulates {
+413 30 22: SEQUENCE {
+415 86 20: [6] 'http://www.nist.gov/'
+ : }
+ : }
+ : }
+437 30 31: SEQUENCE {
+439 06 3: OBJECT IDENTIFIER
+ : authorityKeyIdentifier (2 5 29 35)
+444 04 24: OCTET STRING, encapsulates {
+446 30 22: SEQUENCE {
+448 80 20: [0]
+ : 08 68 AF 85 33 C8 39 4A 7A F8 82 93 8E
+ : 70 6A 4A 20 84 2C 32
+ : }
+ : }
+ : }
+470 30 23: SEQUENCE {
+472 06 3: OBJECT IDENTIFIER
+ : certificatePolicies (2 5 29 32)
+477 04 16: OCTET STRING, encapsulates {
+479 30 14: SEQUENCE {
+481 30 12: SEQUENCE {
+483 06 10: OBJECT IDENTIFIER
+ : '2 16 840 1 101 3 2 1 48 9'
+ : }
+ : }
+ : }
+ : }
+495 30 14: SEQUENCE {
+497 06 3: OBJECT IDENTIFIER keyUsage (2 5 29 15)
+502 01 1: BOOLEAN TRUE
+505 04 4: OCTET STRING, encapsulates {
+507 03 2: BIT STRING 7 unused bits
+ : '1'B (bit 0)
+ : }
+ : }
+ : }
+ : }
+ : }
+
+
+
+Housley, et. al. Standards Track [Page 125]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+511 30 13: SEQUENCE {
+513 06 9: OBJECT IDENTIFIER
+ : sha1withRSAEncryption (1 2 840 113549 1 1 5)
+524 05 0: NULL
+ : }
+526 03 129: BIT STRING 0 unused bits
+ : 1E 07 77 6E 66 B5 B6 B8 57 F0 03 DC 6F 77
+ : 6D AF 55 1D 74 E5 CE 36 81 FC 4B C5 F4 47
+ : 82 C4 0A 25 AA 8D D6 7D 3A 89 AB 44 34 39
+ : F6 BD 61 1A 78 85 7A B8 1E 92 A2 22 2F CE
+ : 07 1A 08 8E F1 46 03 59 36 4A CB 60 E6 03
+ : 40 01 5B 2A 44 D6 E4 7F EB 43 5E 74 0A E6
+ : E4 F9 3E E1 44 BE 1F E7 5F 5B 2C 41 8D 08
+ : BD 26 FE 6A A6 C3 2F B2 3B 41 12 6B C1 06
+ : 8A B8 4C 91 59 EB 2F 38 20 2A 67 74 20 0B
+ : 77 F3
+ : }
+
+C.4 Certificate Revocation List
+
+ This section contains an annotated hex dump of a version 2 CRL with
+ one extension (cRLNumber). The CRL was issued by OU=NIST; O=gov;
+ C=US on August 7, 1997; the next scheduled issuance was September 7,
+ 1997. The CRL includes one revoked certificates: serial number 18
+ (12 hex), which was revoked on July 31, 1997 due to keyCompromise.
+ The CRL itself is number 18, and it was signed with DSA and SHA-1.
+
+ 0 30 203: SEQUENCE {
+ 3 30 140: SEQUENCE {
+ 6 02 1: INTEGER 1
+ 9 30 9: SEQUENCE {
+ 11 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
+ : }
+ 20 30 42: SEQUENCE {
+ 22 31 11: SET {
+ 24 30 9: SEQUENCE {
+ 26 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
+ 31 13 2: PrintableString 'US'
+ : }
+ : }
+ 35 31 12: SET {
+ 37 30 10: SEQUENCE {
+ 39 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
+ 44 13 3: PrintableString 'gov'
+ : }
+ : }
+ 49 31 13: SET {
+ 51 30 11: SEQUENCE {
+
+
+
+Housley, et. al. Standards Track [Page 126]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+ 53 06 3: OBJECT IDENTIFIER
+ : organizationalUnitName (2 5 4 11)
+ 58 13 4: PrintableString 'NIST'
+ : }
+ : }
+ : }
+ 64 17 13: UTCTime '970807000000Z'
+ 79 17 13: UTCTime '970907000000Z'
+ 94 30 34: SEQUENCE {
+ 96 30 32: SEQUENCE {
+ 98 02 1: INTEGER 18
+101 17 13: UTCTime '970731000000Z'
+116 30 12: SEQUENCE {
+118 30 10: SEQUENCE {
+120 06 3: OBJECT IDENTIFIER cRLReason (2 5 29 21)
+125 04 3: OCTET STRING, encapsulates {
+127 0A 1: ENUMERATED 1
+ : }
+ : }
+ : }
+ : }
+ : }
+130 A0 14: [0] {
+132 30 12: SEQUENCE {
+134 30 10: SEQUENCE {
+136 06 3: OBJECT IDENTIFIER cRLNumber (2 5 29 20)
+141 04 3: OCTET STRING, encapsulates {
+143 02 1: INTEGER 12
+ : }
+ : }
+ : }
+ : }
+ : }
+146 30 9: SEQUENCE {
+148 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
+ : }
+157 03 47: BIT STRING 0 unused bits, encapsulates {
+160 30 44: SEQUENCE {
+162 02 20: INTEGER
+ : 22 4E 9F 43 BA 95 06 34 F2 BB 5E 65 DB A6
+ : 80 05 C0 3A 29 47
+184 02 20: INTEGER
+ : 59 1A 57 C9 82 D7 02 21 14 C3 D4 0B 32 1B
+ : 96 16 B1 1F 46 5A
+ : }
+ : }
+ : }
+
+
+
+
+Housley, et. al. Standards Track [Page 127]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+Author Addresses
+
+ Russell Housley
+ RSA Laboratories
+ 918 Spring Knoll Drive
+ Herndon, VA 20170
+ USA
+
+ EMail: rhousley@rsasecurity.com
+
+ Warwick Ford
+ VeriSign, Inc.
+ 401 Edgewater Place
+ Wakefield, MA 01880
+ USA
+
+ EMail: wford@verisign.com
+
+ Tim Polk
+ NIST
+ Building 820, Room 426
+ Gaithersburg, MD 20899
+ USA
+
+ EMail: wpolk@nist.gov
+
+ David Solo
+ Citigroup
+ 909 Third Ave, 16th Floor
+ New York, NY 10043
+ USA
+
+ EMail: dsolo@alum.mit.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 128]
+\f
+RFC 3280 Internet X.509 Public Key Infrastructure April 2002
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley, et. al. Standards Track [Page 129]
+\f
projects / thirdparty / gnutls.git / commitdiff
