added rfc3280
git-svn-id: https://asn1c.svn.sourceforge.net/svnroot/asn1c/trunk@279 59561ff5-6e30-0410-9f3c-9617f08c8826
diff --git a/examples/rfc3280.txt b/examples/rfc3280.txt
new file mode 100644
index 0000000..433908b
--- /dev/null
+++ b/examples/rfc3280.txt
@@ -0,0 +1,7227 @@
+
+
+
+
+
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+