7 Network Working Group R. Housley
8 Request for Comments: 3280 RSA Laboratories
9 Obsoletes: 2459 W. Polk
10 Category: Standards Track NIST
17 Internet X.509 Public Key Infrastructure
18 Certificate and Certificate Revocation List (CRL) Profile
22 This document specifies an Internet standards track protocol for the
23 Internet community, and requests discussion and suggestions for
24 improvements. Please refer to the current edition of the "Internet
25 Official Protocol Standards" (STD 1) for the standardization state
26 and status of this protocol. Distribution of this memo is unlimited.
30 Copyright (C) The Internet Society (2002). All Rights Reserved.
34 This memo profiles the X.509 v3 certificate and X.509 v2 Certificate
35 Revocation List (CRL) for use in the Internet. An overview of this
36 approach and model are provided as an introduction. The X.509 v3
37 certificate format is described in detail, with additional
38 information regarding the format and semantics of Internet name
39 forms. Standard certificate extensions are described and two
40 Internet-specific extensions are defined. A set of required
41 certificate extensions is specified. The X.509 v2 CRL format is
42 described in detail, and required extensions are defined. An
43 algorithm for X.509 certification path validation is described. An
44 ASN.1 module and examples are provided in the appendices.
48 1 Introduction . . . . . . . . . . . . . . . . . . . . . . 4
49 2 Requirements and Assumptions . . . . . . . . . . . . . . 5
50 2.1 Communication and Topology . . . . . . . . . . . . . . 6
51 2.2 Acceptability Criteria . . . . . . . . . . . . . . . . 6
52 2.3 User Expectations . . . . . . . . . . . . . . . . . . . 7
53 2.4 Administrator Expectations . . . . . . . . . . . . . . 7
54 3 Overview of Approach . . . . . . . . . . . . . . . . . . 7
58 Housley, et. al. Standards Track [Page 1]
60 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
63 3.1 X.509 Version 3 Certificate . . . . . . . . . . . . . . 8
64 3.2 Certification Paths and Trust . . . . . . . . . . . . . 9
65 3.3 Revocation . . . . . . . . . . . . . . . . . . . . . . 11
66 3.4 Operational Protocols . . . . . . . . . . . . . . . . . 13
67 3.5 Management Protocols . . . . . . . . . . . . . . . . . 13
68 4 Certificate and Certificate Extensions Profile . . . . . 14
69 4.1 Basic Certificate Fields . . . . . . . . . . . . . . . 15
70 4.1.1 Certificate Fields . . . . . . . . . . . . . . . . . 16
71 4.1.1.1 tbsCertificate . . . . . . . . . . . . . . . . . . 16
72 4.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . 16
73 4.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . 16
74 4.1.2 TBSCertificate . . . . . . . . . . . . . . . . . . . 17
75 4.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . 17
76 4.1.2.2 Serial number . . . . . . . . . . . . . . . . . . . 17
77 4.1.2.3 Signature . . . . . . . . . . . . . . . . . . . . . 18
78 4.1.2.4 Issuer . . . . . . . . . . . . . . . . . . . . . . 18
79 4.1.2.5 Validity . . . . . . . . . . . . . . . . . . . . . 22
80 4.1.2.5.1 UTCTime . . . . . . . . . . . . . . . . . . . . . 22
81 4.1.2.5.2 GeneralizedTime . . . . . . . . . . . . . . . . . 22
82 4.1.2.6 Subject . . . . . . . . . . . . . . . . . . . . . . 23
83 4.1.2.7 Subject Public Key Info . . . . . . . . . . . . . . 24
84 4.1.2.8 Unique Identifiers . . . . . . . . . . . . . . . . 24
85 4.1.2.9 Extensions . . . . . . . . . . . . . . . . . . . . . 24
86 4.2 Certificate Extensions . . . . . . . . . . . . . . . . 24
87 4.2.1 Standard Extensions . . . . . . . . . . . . . . . . . 25
88 4.2.1.1 Authority Key Identifier . . . . . . . . . . . . . 26
89 4.2.1.2 Subject Key Identifier . . . . . . . . . . . . . . 27
90 4.2.1.3 Key Usage . . . . . . . . . . . . . . . . . . . . . 28
91 4.2.1.4 Private Key Usage Period . . . . . . . . . . . . . 29
92 4.2.1.5 Certificate Policies . . . . . . . . . . . . . . . 30
93 4.2.1.6 Policy Mappings . . . . . . . . . . . . . . . . . . 33
94 4.2.1.7 Subject Alternative Name . . . . . . . . . . . . . 33
95 4.2.1.8 Issuer Alternative Name . . . . . . . . . . . . . . 36
96 4.2.1.9 Subject Directory Attributes . . . . . . . . . . . 36
97 4.2.1.10 Basic Constraints . . . . . . . . . . . . . . . . 36
98 4.2.1.11 Name Constraints . . . . . . . . . . . . . . . . . 37
99 4.2.1.12 Policy Constraints . . . . . . . . . . . . . . . . 40
100 4.2.1.13 Extended Key Usage . . . . . . . . . . . . . . . . 40
101 4.2.1.14 CRL Distribution Points . . . . . . . . . . . . . 42
102 4.2.1.15 Inhibit Any-Policy . . . . . . . . . . . . . . . . 44
103 4.2.1.16 Freshest CRL . . . . . . . . . . . . . . . . . . . 44
104 4.2.2 Internet Certificate Extensions . . . . . . . . . . . 45
105 4.2.2.1 Authority Information Access . . . . . . . . . . . 45
106 4.2.2.2 Subject Information Access . . . . . . . . . . . . 46
107 5 CRL and CRL Extensions Profile . . . . . . . . . . . . . 48
108 5.1 CRL Fields . . . . . . . . . . . . . . . . . . . . . . 49
109 5.1.1 CertificateList Fields . . . . . . . . . . . . . . . 50
110 5.1.1.1 tbsCertList . . . . . . . . . . . . . . . . . . . . 50
114 Housley, et. al. Standards Track [Page 2]
116 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
119 5.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . 50
120 5.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . 51
121 5.1.2 Certificate List "To Be Signed" . . . . . . . . . . . 51
122 5.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . 52
123 5.1.2.2 Signature . . . . . . . . . . . . . . . . . . . . . 52
124 5.1.2.3 Issuer Name . . . . . . . . . . . . . . . . . . . . 52
125 5.1.2.4 This Update . . . . . . . . . . . . . . . . . . . . 52
126 5.1.2.5 Next Update . . . . . . . . . . . . . . . . . . . . 53
127 5.1.2.6 Revoked Certificates . . . . . . . . . . . . . . . 53
128 5.1.2.7 Extensions . . . . . . . . . . . . . . . . . . . . 53
129 5.2 CRL Extensions . . . . . . . . . . . . . . . . . . . . 53
130 5.2.1 Authority Key Identifier . . . . . . . . . . . . . . 54
131 5.2.2 Issuer Alternative Name . . . . . . . . . . . . . . . 54
132 5.2.3 CRL Number . . . . . . . . . . . . . . . . . . . . . 55
133 5.2.4 Delta CRL Indicator . . . . . . . . . . . . . . . . . 55
134 5.2.5 Issuing Distribution Point . . . . . . . . . . . . . 58
135 5.2.6 Freshest CRL . . . . . . . . . . . . . . . . . . . . 59
136 5.3 CRL Entry Extensions . . . . . . . . . . . . . . . . . 60
137 5.3.1 Reason Code . . . . . . . . . . . . . . . . . . . . . 60
138 5.3.2 Hold Instruction Code . . . . . . . . . . . . . . . . 61
139 5.3.3 Invalidity Date . . . . . . . . . . . . . . . . . . . 62
140 5.3.4 Certificate Issuer . . . . . . . . . . . . . . . . . 62
141 6 Certificate Path Validation . . . . . . . . . . . . . . . 62
142 6.1 Basic Path Validation . . . . . . . . . . . . . . . . . 63
143 6.1.1 Inputs . . . . . . . . . . . . . . . . . . . . . . . 66
144 6.1.2 Initialization . . . . . . . . . . . . . . . . . . . 67
145 6.1.3 Basic Certificate Processing . . . . . . . . . . . . 70
146 6.1.4 Preparation for Certificate i+1 . . . . . . . . . . . 75
147 6.1.5 Wrap-up procedure . . . . . . . . . . . . . . . . . . 78
148 6.1.6 Outputs . . . . . . . . . . . . . . . . . . . . . . . 80
149 6.2 Extending Path Validation . . . . . . . . . . . . . . . 80
150 6.3 CRL Validation . . . . . . . . . . . . . . . . . . . . 81
151 6.3.1 Revocation Inputs . . . . . . . . . . . . . . . . . . 82
152 6.3.2 Initialization and Revocation State Variables . . . . 82
153 6.3.3 CRL Processing . . . . . . . . . . . . . . . . . . . 83
154 7 References . . . . . . . . . . . . . . . . . . . . . . . 86
155 8 Intellectual Property Rights . . . . . . . . . . . . . . 88
156 9 Security Considerations . . . . . . . . . . . . . . . . . 89
157 Appendix A. ASN.1 Structures and OIDs . . . . . . . . . . . 92
158 A.1 Explicitly Tagged Module, 1988 Syntax . . . . . . . . . 92
159 A.2 Implicitly Tagged Module, 1988 Syntax . . . . . . . . . 105
160 Appendix B. ASN.1 Notes . . . . . . . . . . . . . . . . . . 112
161 Appendix C. Examples . . . . . . . . . . . . . . . . . . . 115
162 C.1 DSA Self-Signed Certificate . . . . . . . . . . . . . . 115
163 C.2 End Entity Certificate Using DSA . . . . . . . . . . . 119
164 C.3 End Entity Certificate Using RSA . . . . . . . . . . . 122
165 C.4 Certificate Revocation List . . . . . . . . . . . . . . 126
166 Author Addresses . . . . . . . . . . . . . . . . . . . . . . 128
170 Housley, et. al. Standards Track [Page 3]
172 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
175 Full Copyright Statement . . . . . . . . . . . . . . . . . . 129
179 This specification is one part of a family of standards for the X.509
180 Public Key Infrastructure (PKI) for the Internet.
182 This specification profiles the format and semantics of certificates
183 and certificate revocation lists (CRLs) for the Internet PKI.
184 Procedures are described for processing of certification paths in the
185 Internet environment. Finally, ASN.1 modules are provided in the
186 appendices for all data structures defined or referenced.
188 Section 2 describes Internet PKI requirements, and the assumptions
189 which affect the scope of this document. Section 3 presents an
190 architectural model and describes its relationship to previous IETF
191 and ISO/IEC/ITU-T standards. In particular, this document's
192 relationship with the IETF PEM specifications and the ISO/IEC/ITU-T
193 X.509 documents are described.
195 Section 4 profiles the X.509 version 3 certificate, and section 5
196 profiles the X.509 version 2 CRL. The profiles include the
197 identification of ISO/IEC/ITU-T and ANSI extensions which may be
198 useful in the Internet PKI. The profiles are presented in the 1988
199 Abstract Syntax Notation One (ASN.1) rather than the 1997 ASN.1
200 syntax used in the most recent ISO/IEC/ITU-T standards.
202 Section 6 includes certification path validation procedures. These
203 procedures are based upon the ISO/IEC/ITU-T definition.
204 Implementations are REQUIRED to derive the same results but are not
205 required to use the specified procedures.
207 Procedures for identification and encoding of public key materials
208 and digital signatures are defined in [PKIXALGS]. Implementations of
209 this specification are not required to use any particular
210 cryptographic algorithms. However, conforming implementations which
211 use the algorithms identified in [PKIXALGS] MUST identify and encode
212 the public key materials and digital signatures as described in that
215 Finally, three appendices are provided to aid implementers. Appendix
216 A contains all ASN.1 structures defined or referenced within this
217 specification. As above, the material is presented in the 1988
218 ASN.1. Appendix B contains notes on less familiar features of the
219 ASN.1 notation used within this specification. Appendix C contains
220 examples of a conforming certificate and a conforming CRL.
226 Housley, et. al. Standards Track [Page 4]
228 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
231 This specification obsoletes RFC 2459. This specification differs
232 from RFC 2459 in five basic areas:
234 * To promote interoperable implementations, a detailed algorithm
235 for certification path validation is included in section 6.1 of
236 this specification; RFC 2459 provided only a high-level
237 description of path validation.
239 * An algorithm for determining the status of a certificate using
240 CRLs is provided in section 6.3 of this specification. This
241 material was not present in RFC 2459.
243 * To accommodate new usage models, detailed information describing
244 the use of delta CRLs is provided in Section 5 of this
247 * Identification and encoding of public key materials and digital
248 signatures are not included in this specification, but are now
249 described in a companion specification [PKIXALGS].
251 * Four additional extensions are specified: three certificate
252 extensions and one CRL extension. The certificate extensions are
253 subject info access, inhibit any-policy, and freshest CRL. The
254 freshest CRL extension is also defined as a CRL extension.
256 * Throughout the specification, clarifications have been
257 introduced to enhance consistency with the ITU-T X.509
258 specification. X.509 defines the certificate and CRL format as
259 well as many of the extensions that appear in this specification.
260 These changes were introduced to improve the likelihood of
261 interoperability between implementations based on this
262 specification with implementations based on the ITU-T
265 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
266 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
267 document are to be interpreted as described in RFC 2119.
269 2 Requirements and Assumptions
271 The goal of this specification is to develop a profile to facilitate
272 the use of X.509 certificates within Internet applications for those
273 communities wishing to make use of X.509 technology. Such
274 applications may include WWW, electronic mail, user authentication,
275 and IPsec. In order to relieve some of the obstacles to using X.509
282 Housley, et. al. Standards Track [Page 5]
284 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
287 certificates, this document defines a profile to promote the
288 development of certificate management systems; development of
289 application tools; and interoperability determined by policy.
291 Some communities will need to supplement, or possibly replace, this
292 profile in order to meet the requirements of specialized application
293 domains or environments with additional authorization, assurance, or
294 operational requirements. However, for basic applications, common
295 representations of frequently used attributes are defined so that
296 application developers can obtain necessary information without
297 regard to the issuer of a particular certificate or certificate
298 revocation list (CRL).
300 A certificate user should review the certificate policy generated by
301 the certification authority (CA) before relying on the authentication
302 or non-repudiation services associated with the public key in a
303 particular certificate. To this end, this standard does not
304 prescribe legally binding rules or duties.
306 As supplemental authorization and attribute management tools emerge,
307 such as attribute certificates, it may be appropriate to limit the
308 authenticated attributes that are included in a certificate. These
309 other management tools may provide more appropriate methods of
310 conveying many authenticated attributes.
312 2.1 Communication and Topology
314 The users of certificates will operate in a wide range of
315 environments with respect to their communication topology, especially
316 users of secure electronic mail. This profile supports users without
317 high bandwidth, real-time IP connectivity, or high connection
318 availability. In addition, the profile allows for the presence of
319 firewall or other filtered communication.
321 This profile does not assume the deployment of an X.500 Directory
322 system or a LDAP directory system. The profile does not prohibit the
323 use of an X.500 Directory or a LDAP directory; however, any means of
324 distributing certificates and certificate revocation lists (CRLs) may
327 2.2 Acceptability Criteria
329 The goal of the Internet Public Key Infrastructure (PKI) is to meet
330 the needs of deterministic, automated identification, authentication,
331 access control, and authorization functions. Support for these
332 services determines the attributes contained in the certificate as
333 well as the ancillary control information in the certificate such as
334 policy data and certification path constraints.
338 Housley, et. al. Standards Track [Page 6]
340 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
343 2.3 User Expectations
345 Users of the Internet PKI are people and processes who use client
346 software and are the subjects named in certificates. These uses
347 include readers and writers of electronic mail, the clients for WWW
348 browsers, WWW servers, and the key manager for IPsec within a router.
349 This profile recognizes the limitations of the platforms these users
350 employ and the limitations in sophistication and attentiveness of the
351 users themselves. This manifests itself in minimal user
352 configuration responsibility (e.g., trusted CA keys, rules), explicit
353 platform usage constraints within the certificate, certification path
354 constraints which shield the user from many malicious actions, and
355 applications which sensibly automate validation functions.
357 2.4 Administrator Expectations
359 As with user expectations, the Internet PKI profile is structured to
360 support the individuals who generally operate CAs. Providing
361 administrators with unbounded choices increases the chances that a
362 subtle CA administrator mistake will result in broad compromise.
363 Also, unbounded choices greatly complicate the software that process
364 and validate the certificates created by the CA.
366 3 Overview of Approach
368 Following is a simplified view of the architectural model assumed by
369 the PKIX specifications.
371 The components in this model are:
373 end entity: user of PKI certificates and/or end user system that is
374 the subject of a certificate;
375 CA: certification authority;
376 RA: registration authority, i.e., an optional system to which
377 a CA delegates certain management functions;
378 CRL issuer: an optional system to which a CA delegates the
379 publication of certificate revocation lists;
380 repository: a system or collection of distributed systems that stores
381 certificates and CRLs and serves as a means of
382 distributing these certificates and CRLs to end entities.
384 Note that an Attribute Authority (AA) might also choose to delegate
385 the publication of CRLs to a CRL issuer.
394 Housley, et. al. Standards Track [Page 7]
396 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
401 | e | <-------------------->| End entity |
402 | r | Operational +------------+
404 | i | and management | Management
405 | f | transactions | transactions PKI
408 | a | ======================= +--+------------+ ==============
412 | & | +------+ | entities
413 | | <---------------------| RA |<----+ |
414 | C | Publish certificate +------+ | |
419 | e | <------------------------------| CA |
420 | p | Publish certificate +------------+
421 | o | Publish CRL ^ ^
423 | i | +------------+ | | transactions
424 | t | <--------------| CRL Issuer |<----+ |
425 | o | Publish CRL +------------+ v
430 Figure 1 - PKI Entities
432 3.1 X.509 Version 3 Certificate
434 Users of a public key require confidence that the associated private
435 key is owned by the correct remote subject (person or system) with
436 which an encryption or digital signature mechanism will be used.
437 This confidence is obtained through the use of public key
438 certificates, which are data structures that bind public key values
439 to subjects. The binding is asserted by having a trusted CA
440 digitally sign each certificate. The CA may base this assertion upon
441 technical means (a.k.a., proof of possession through a challenge-
442 response protocol), presentation of the private key, or on an
443 assertion by the subject. A certificate has a limited valid lifetime
444 which is indicated in its signed contents. Because a certificate's
445 signature and timeliness can be independently checked by a
446 certificate-using client, certificates can be distributed via
450 Housley, et. al. Standards Track [Page 8]
452 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
455 untrusted communications and server systems, and can be cached in
456 unsecured storage in certificate-using systems.
458 ITU-T X.509 (formerly CCITT X.509) or ISO/IEC 9594-8, which was first
459 published in 1988 as part of the X.500 Directory recommendations,
460 defines a standard certificate format [X.509]. The certificate
461 format in the 1988 standard is called the version 1 (v1) format.
462 When X.500 was revised in 1993, two more fields were added, resulting
463 in the version 2 (v2) format.
465 The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993,
466 include specifications for a public key infrastructure based on X.509
467 v1 certificates [RFC 1422]. The experience gained in attempts to
468 deploy RFC 1422 made it clear that the v1 and v2 certificate formats
469 are deficient in several respects. Most importantly, more fields
470 were needed to carry information which PEM design and implementation
471 experience had proven necessary. In response to these new
472 requirements, ISO/IEC, ITU-T and ANSI X9 developed the X.509 version
473 3 (v3) certificate format. The v3 format extends the v2 format by
474 adding provision for additional extension fields. Particular
475 extension field types may be specified in standards or may be defined
476 and registered by any organization or community. In June 1996,
477 standardization of the basic v3 format was completed [X.509].
479 ISO/IEC, ITU-T, and ANSI X9 have also developed standard extensions
480 for use in the v3 extensions field [X.509][X9.55]. These extensions
481 can convey such data as additional subject identification
482 information, key attribute information, policy information, and
483 certification path constraints.
485 However, the ISO/IEC, ITU-T, and ANSI X9 standard extensions are very
486 broad in their applicability. In order to develop interoperable
487 implementations of X.509 v3 systems for Internet use, it is necessary
488 to specify a profile for use of the X.509 v3 extensions tailored for
489 the Internet. It is one goal of this document to specify a profile
490 for Internet WWW, electronic mail, and IPsec applications.
491 Environments with additional requirements may build on this profile
494 3.2 Certification Paths and Trust
496 A user of a security service requiring knowledge of a public key
497 generally needs to obtain and validate a certificate containing the
498 required public key. If the public key user does not already hold an
499 assured copy of the public key of the CA that signed the certificate,
500 the CA's name, and related information (such as the validity period
501 or name constraints), then it might need an additional certificate to
502 obtain that public key. In general, a chain of multiple certificates
506 Housley, et. al. Standards Track [Page 9]
508 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
511 may be needed, comprising a certificate of the public key owner (the
512 end entity) signed by one CA, and zero or more additional
513 certificates of CAs signed by other CAs. Such chains, called
514 certification paths, are required because a public key user is only
515 initialized with a limited number of assured CA public keys.
517 There are different ways in which CAs might be configured in order
518 for public key users to be able to find certification paths. For
519 PEM, RFC 1422 defined a rigid hierarchical structure of CAs. There
520 are three types of PEM certification authority:
522 (a) Internet Policy Registration Authority (IPRA): This
523 authority, operated under the auspices of the Internet Society,
524 acts as the root of the PEM certification hierarchy at level 1.
525 It issues certificates only for the next level of authorities,
526 PCAs. All certification paths start with the IPRA.
528 (b) Policy Certification Authorities (PCAs): PCAs are at level 2
529 of the hierarchy, each PCA being certified by the IPRA. A PCA
530 shall establish and publish a statement of its policy with respect
531 to certifying users or subordinate certification authorities.
532 Distinct PCAs aim to satisfy different user needs. For example,
533 one PCA (an organizational PCA) might support the general
534 electronic mail needs of commercial organizations, and another PCA
535 (a high-assurance PCA) might have a more stringent policy designed
536 for satisfying legally binding digital signature requirements.
538 (c) Certification Authorities (CAs): CAs are at level 3 of the
539 hierarchy and can also be at lower levels. Those at level 3 are
540 certified by PCAs. CAs represent, for example, particular
541 organizations, particular organizational units (e.g., departments,
542 groups, sections), or particular geographical areas.
544 RFC 1422 furthermore has a name subordination rule which requires
545 that a CA can only issue certificates for entities whose names are
546 subordinate (in the X.500 naming tree) to the name of the CA itself.
547 The trust associated with a PEM certification path is implied by the
548 PCA name. The name subordination rule ensures that CAs below the PCA
549 are sensibly constrained as to the set of subordinate entities they
550 can certify (e.g., a CA for an organization can only certify entities
551 in that organization's name tree). Certificate user systems are able
552 to mechanically check that the name subordination rule has been
555 The RFC 1422 uses the X.509 v1 certificate formats. The limitations
556 of X.509 v1 required imposition of several structural restrictions to
557 clearly associate policy information or restrict the utility of
558 certificates. These restrictions included:
562 Housley, et. al. Standards Track [Page 10]
564 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
567 (a) a pure top-down hierarchy, with all certification paths
570 (b) a naming subordination rule restricting the names of a CA's
573 (c) use of the PCA concept, which requires knowledge of
574 individual PCAs to be built into certificate chain verification
575 logic. Knowledge of individual PCAs was required to determine if
576 a chain could be accepted.
578 With X.509 v3, most of the requirements addressed by RFC 1422 can be
579 addressed using certificate extensions, without a need to restrict
580 the CA structures used. In particular, the certificate extensions
581 relating to certificate policies obviate the need for PCAs and the
582 constraint extensions obviate the need for the name subordination
583 rule. As a result, this document supports a more flexible
584 architecture, including:
586 (a) Certification paths start with a public key of a CA in a
587 user's own domain, or with the public key of the top of a
588 hierarchy. Starting with the public key of a CA in a user's own
589 domain has certain advantages. In some environments, the local
590 domain is the most trusted.
592 (b) Name constraints may be imposed through explicit inclusion of
593 a name constraints extension in a certificate, but are not
596 (c) Policy extensions and policy mappings replace the PCA
597 concept, which permits a greater degree of automation. The
598 application can determine if the certification path is acceptable
599 based on the contents of the certificates instead of a priori
600 knowledge of PCAs. This permits automation of certification path
605 When a certificate is issued, it is expected to be in use for its
606 entire validity period. However, various circumstances may cause a
607 certificate to become invalid prior to the expiration of the validity
608 period. Such circumstances include change of name, change of
609 association between subject and CA (e.g., an employee terminates
610 employment with an organization), and compromise or suspected
611 compromise of the corresponding private key. Under such
612 circumstances, the CA needs to revoke the certificate.
618 Housley, et. al. Standards Track [Page 11]
620 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
623 X.509 defines one method of certificate revocation. This method
624 involves each CA periodically issuing a signed data structure called
625 a certificate revocation list (CRL). A CRL is a time stamped list
626 identifying revoked certificates which is signed by a CA or CRL
627 issuer and made freely available in a public repository. Each
628 revoked certificate is identified in a CRL by its certificate serial
629 number. When a certificate-using system uses a certificate (e.g.,
630 for verifying a remote user's digital signature), that system not
631 only checks the certificate signature and validity but also acquires
632 a suitably-recent CRL and checks that the certificate serial number
633 is not on that CRL. The meaning of "suitably-recent" may vary with
634 local policy, but it usually means the most recently-issued CRL. A
635 new CRL is issued on a regular periodic basis (e.g., hourly, daily,
636 or weekly). An entry is added to the CRL as part of the next update
637 following notification of revocation. An entry MUST NOT be removed
638 from the CRL until it appears on one regularly scheduled CRL issued
639 beyond the revoked certificate's validity period.
641 An advantage of this revocation method is that CRLs may be
642 distributed by exactly the same means as certificates themselves,
643 namely, via untrusted servers and untrusted communications.
645 One limitation of the CRL revocation method, using untrusted
646 communications and servers, is that the time granularity of
647 revocation is limited to the CRL issue period. For example, if a
648 revocation is reported now, that revocation will not be reliably
649 notified to certificate-using systems until all currently issued CRLs
650 are updated -- this may be up to one hour, one day, or one week
651 depending on the frequency that CRLs are issued.
653 As with the X.509 v3 certificate format, in order to facilitate
654 interoperable implementations from multiple vendors, the X.509 v2 CRL
655 format needs to be profiled for Internet use. It is one goal of this
656 document to specify that profile. However, this profile does not
657 require the issuance of CRLs. Message formats and protocols
658 supporting on-line revocation notification are defined in other PKIX
659 specifications. On-line methods of revocation notification may be
660 applicable in some environments as an alternative to the X.509 CRL.
661 On-line revocation checking may significantly reduce the latency
662 between a revocation report and the distribution of the information
663 to relying parties. Once the CA accepts a revocation report as
664 authentic and valid, any query to the on-line service will correctly
665 reflect the certificate validation impacts of the revocation.
666 However, these methods impose new security requirements: the
667 certificate validator needs to trust the on-line validation service
668 while the repository does not need to be trusted.
674 Housley, et. al. Standards Track [Page 12]
676 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
679 3.4 Operational Protocols
681 Operational protocols are required to deliver certificates and CRLs
682 (or status information) to certificate using client systems.
683 Provisions are needed for a variety of different means of certificate
684 and CRL delivery, including distribution procedures based on LDAP,
685 HTTP, FTP, and X.500. Operational protocols supporting these
686 functions are defined in other PKIX specifications. These
687 specifications may include definitions of message formats and
688 procedures for supporting all of the above operational environments,
689 including definitions of or references to appropriate MIME content
692 3.5 Management Protocols
694 Management protocols are required to support on-line interactions
695 between PKI user and management entities. For example, a management
696 protocol might be used between a CA and a client system with which a
697 key pair is associated, or between two CAs which cross-certify each
698 other. The set of functions which potentially need to be supported
699 by management protocols include:
701 (a) registration: This is the process whereby a user first makes
702 itself known to a CA (directly, or through an RA), prior to that
703 CA issuing a certificate or certificates for that user.
705 (b) initialization: Before a client system can operate securely
706 it is necessary to install key materials which have the
707 appropriate relationship with keys stored elsewhere in the
708 infrastructure. For example, the client needs to be securely
709 initialized with the public key and other assured information of
710 the trusted CA(s), to be used in validating certificate paths.
712 Furthermore, a client typically needs to be initialized with its
715 (c) certification: This is the process in which a CA issues a
716 certificate for a user's public key, and returns that certificate
717 to the user's client system and/or posts that certificate in a
720 (d) key pair recovery: As an option, user client key materials
721 (e.g., a user's private key used for encryption purposes) may be
722 backed up by a CA or a key backup system. If a user needs to
723 recover these backed up key materials (e.g., as a result of a
724 forgotten password or a lost key chain file), an on-line protocol
725 exchange may be needed to support such recovery.
730 Housley, et. al. Standards Track [Page 13]
732 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
735 (e) key pair update: All key pairs need to be updated regularly,
736 i.e., replaced with a new key pair, and new certificates issued.
738 (f) revocation request: An authorized person advises a CA of an
739 abnormal situation requiring certificate revocation.
741 (g) cross-certification: Two CAs exchange information used in
742 establishing a cross-certificate. A cross-certificate is a
743 certificate issued by one CA to another CA which contains a CA
744 signature key used for issuing certificates.
746 Note that on-line protocols are not the only way of implementing the
747 above functions. For all functions there are off-line methods of
748 achieving the same result, and this specification does not mandate
749 use of on-line protocols. For example, when hardware tokens are
750 used, many of the functions may be achieved as part of the physical
751 token delivery. Furthermore, some of the above functions may be
752 combined into one protocol exchange. In particular, two or more of
753 the registration, initialization, and certification functions can be
754 combined into one protocol exchange.
756 The PKIX series of specifications defines a set of standard message
757 formats supporting the above functions. The protocols for conveying
758 these messages in different environments (e.g., e-mail, file
759 transfer, and WWW) are described in those specifications.
761 4 Certificate and Certificate Extensions Profile
763 This section presents a profile for public key certificates that will
764 foster interoperability and a reusable PKI. This section is based
765 upon the X.509 v3 certificate format and the standard certificate
766 extensions defined in [X.509]. The ISO/IEC and ITU-T documents use
767 the 1997 version of ASN.1; while this document uses the 1988 ASN.1
768 syntax, the encoded certificate and standard extensions are
769 equivalent. This section also defines private extensions required to
770 support a PKI for the Internet community.
772 Certificates may be used in a wide range of applications and
773 environments covering a broad spectrum of interoperability goals and
774 a broader spectrum of operational and assurance requirements. The
775 goal of this document is to establish a common baseline for generic
776 applications requiring broad interoperability and limited special
777 purpose requirements. In particular, the emphasis will be on
778 supporting the use of X.509 v3 certificates for informal Internet
779 electronic mail, IPsec, and WWW applications.
786 Housley, et. al. Standards Track [Page 14]
788 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
791 4.1 Basic Certificate Fields
793 The X.509 v3 certificate basic syntax is as follows. For signature
794 calculation, the data that is to be signed is encoded using the ASN.1
795 distinguished encoding rules (DER) [X.690]. ASN.1 DER encoding is a
796 tag, length, value encoding system for each element.
798 Certificate ::= SEQUENCE {
799 tbsCertificate TBSCertificate,
800 signatureAlgorithm AlgorithmIdentifier,
801 signatureValue BIT STRING }
803 TBSCertificate ::= SEQUENCE {
804 version [0] EXPLICIT Version DEFAULT v1,
805 serialNumber CertificateSerialNumber,
806 signature AlgorithmIdentifier,
810 subjectPublicKeyInfo SubjectPublicKeyInfo,
811 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
812 -- If present, version MUST be v2 or v3
813 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
814 -- If present, version MUST be v2 or v3
815 extensions [3] EXPLICIT Extensions OPTIONAL
816 -- If present, version MUST be v3
819 Version ::= INTEGER { v1(0), v2(1), v3(2) }
821 CertificateSerialNumber ::= INTEGER
823 Validity ::= SEQUENCE {
829 generalTime GeneralizedTime }
831 UniqueIdentifier ::= BIT STRING
833 SubjectPublicKeyInfo ::= SEQUENCE {
834 algorithm AlgorithmIdentifier,
835 subjectPublicKey BIT STRING }
837 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
842 Housley, et. al. Standards Track [Page 15]
844 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
847 Extension ::= SEQUENCE {
848 extnID OBJECT IDENTIFIER,
849 critical BOOLEAN DEFAULT FALSE,
850 extnValue OCTET STRING }
852 The following items describe the X.509 v3 certificate for use in the
855 4.1.1 Certificate Fields
857 The Certificate is a SEQUENCE of three required fields. The fields
858 are described in detail in the following subsections.
860 4.1.1.1 tbsCertificate
862 The field contains the names of the subject and issuer, a public key
863 associated with the subject, a validity period, and other associated
864 information. The fields are described in detail in section 4.1.2;
865 the tbsCertificate usually includes extensions which are described in
868 4.1.1.2 signatureAlgorithm
870 The signatureAlgorithm field contains the identifier for the
871 cryptographic algorithm used by the CA to sign this certificate.
872 [PKIXALGS] lists supported signature algorithms, but other signature
873 algorithms MAY also be supported.
875 An algorithm identifier is defined by the following ASN.1 structure:
877 AlgorithmIdentifier ::= SEQUENCE {
878 algorithm OBJECT IDENTIFIER,
879 parameters ANY DEFINED BY algorithm OPTIONAL }
881 The algorithm identifier is used to identify a cryptographic
882 algorithm. The OBJECT IDENTIFIER component identifies the algorithm
883 (such as DSA with SHA-1). The contents of the optional parameters
884 field will vary according to the algorithm identified.
886 This field MUST contain the same algorithm identifier as the
887 signature field in the sequence tbsCertificate (section 4.1.2.3).
889 4.1.1.3 signatureValue
891 The signatureValue field contains a digital signature computed upon
892 the ASN.1 DER encoded tbsCertificate. The ASN.1 DER encoded
893 tbsCertificate is used as the input to the signature function. This
898 Housley, et. al. Standards Track [Page 16]
900 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
903 signature value is encoded as a BIT STRING and included in the
904 signature field. The details of this process are specified for each
905 of algorithms listed in [PKIXALGS].
907 By generating this signature, a CA certifies the validity of the
908 information in the tbsCertificate field. In particular, the CA
909 certifies the binding between the public key material and the subject
914 The sequence TBSCertificate contains information associated with the
915 subject of the certificate and the CA who issued it. Every
916 TBSCertificate contains the names of the subject and issuer, a public
917 key associated with the subject, a validity period, a version number,
918 and a serial number; some MAY contain optional unique identifier
919 fields. The remainder of this section describes the syntax and
920 semantics of these fields. A TBSCertificate usually includes
921 extensions. Extensions for the Internet PKI are described in Section
926 This field describes the version of the encoded certificate. When
927 extensions are used, as expected in this profile, version MUST be 3
928 (value is 2). If no extensions are present, but a UniqueIdentifier
929 is present, the version SHOULD be 2 (value is 1); however version MAY
930 be 3. If only basic fields are present, the version SHOULD be 1 (the
931 value is omitted from the certificate as the default value); however
932 the version MAY be 2 or 3.
934 Implementations SHOULD be prepared to accept any version certificate.
935 At a minimum, conforming implementations MUST recognize version 3
938 Generation of version 2 certificates is not expected by
939 implementations based on this profile.
941 4.1.2.2 Serial number
943 The serial number MUST be a positive integer assigned by the CA to
944 each certificate. It MUST be unique for each certificate issued by a
945 given CA (i.e., the issuer name and serial number identify a unique
946 certificate). CAs MUST force the serialNumber to be a non-negative
954 Housley, et. al. Standards Track [Page 17]
956 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
959 Given the uniqueness requirements above, serial numbers can be
960 expected to contain long integers. Certificate users MUST be able to
961 handle serialNumber values up to 20 octets. Conformant CAs MUST NOT
962 use serialNumber values longer than 20 octets.
964 Note: Non-conforming CAs may issue certificates with serial numbers
965 that are negative, or zero. Certificate users SHOULD be prepared to
966 gracefully handle such certificates.
970 This field contains the algorithm identifier for the algorithm used
971 by the CA to sign the certificate.
973 This field MUST contain the same algorithm identifier as the
974 signatureAlgorithm field in the sequence Certificate (section
975 4.1.1.2). The contents of the optional parameters field will vary
976 according to the algorithm identified. [PKIXALGS] lists the
977 supported signature algorithms, but other signature algorithms MAY
982 The issuer field identifies the entity who has signed and issued the
983 certificate. The issuer field MUST contain a non-empty distinguished
984 name (DN). The issuer field is defined as the X.501 type Name
985 [X.501]. Name is defined by the following ASN.1 structures:
990 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
992 RelativeDistinguishedName ::=
993 SET OF AttributeTypeAndValue
995 AttributeTypeAndValue ::= SEQUENCE {
997 value AttributeValue }
999 AttributeType ::= OBJECT IDENTIFIER
1001 AttributeValue ::= ANY DEFINED BY AttributeType
1010 Housley, et. al. Standards Track [Page 18]
1012 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
1015 DirectoryString ::= CHOICE {
1016 teletexString TeletexString (SIZE (1..MAX)),
1017 printableString PrintableString (SIZE (1..MAX)),
1018 universalString UniversalString (SIZE (1..MAX)),
1019 utf8String UTF8String (SIZE (1..MAX)),
1020 bmpString BMPString (SIZE (1..MAX)) }
1022 The Name describes a hierarchical name composed of attributes, such
1023 as country name, and corresponding values, such as US. The type of
1024 the component AttributeValue is determined by the AttributeType; in
1025 general it will be a DirectoryString.
1027 The DirectoryString type is defined as a choice of PrintableString,
1028 TeletexString, BMPString, UTF8String, and UniversalString. The
1029 UTF8String encoding [RFC 2279] is the preferred encoding, and all
1030 certificates issued after December 31, 2003 MUST use the UTF8String
1031 encoding of DirectoryString (except as noted below). Until that
1032 date, conforming CAs MUST choose from the following options when
1033 creating a distinguished name, including their own:
1035 (a) if the character set is sufficient, the string MAY be
1036 represented as a PrintableString;
1038 (b) failing (a), if the BMPString character set is sufficient the
1039 string MAY be represented as a BMPString; and
1041 (c) failing (a) and (b), the string MUST be represented as a
1042 UTF8String. If (a) or (b) is satisfied, the CA MAY still choose
1043 to represent the string as a UTF8String.
1045 Exceptions to the December 31, 2003 UTF8 encoding requirements are as
1048 (a) CAs MAY issue "name rollover" certificates to support an
1049 orderly migration to UTF8String encoding. Such certificates would
1050 include the CA's UTF8String encoded name as issuer and and the old
1051 name encoding as subject, or vice-versa.
1053 (b) As stated in section 4.1.2.6, the subject field MUST be
1054 populated with a non-empty distinguished name matching the
1055 contents of the issuer field in all certificates issued by the
1056 subject CA regardless of encoding.
1058 The TeletexString and UniversalString are included for backward
1059 compatibility, and SHOULD NOT be used for certificates for new
1060 subjects. However, these types MAY be used in certificates where the
1061 name was previously established. Certificate users SHOULD be
1062 prepared to receive certificates with these types.
1066 Housley, et. al. Standards Track [Page 19]
1068 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
1071 In addition, many legacy implementations support names encoded in the
1072 ISO 8859-1 character set (Latin1String) [ISO 8859-1] but tag them as
1073 TeletexString. TeletexString encodes a larger character set than ISO
1074 8859-1, but it encodes some characters differently. Implementations
1075 SHOULD be prepared to handle both encodings.
1077 As noted above, distinguished names are composed of attributes. This
1078 specification does not restrict the set of attribute types that may
1079 appear in names. However, conforming implementations MUST be
1080 prepared to receive certificates with issuer names containing the set
1081 of attribute types defined below. This specification RECOMMENDS
1082 support for additional attribute types.
1084 Standard sets of attributes have been defined in the X.500 series of
1085 specifications [X.520]. Implementations of this specification MUST
1086 be prepared to receive the following standard attribute types in
1087 issuer and subject (section 4.1.2.6) names:
1091 * organizational-unit,
1092 * distinguished name qualifier,
1093 * state or province name,
1094 * common name (e.g., "Susan Housley"), and
1097 In addition, implementations of this specification SHOULD be prepared
1098 to receive the following standard attribute types in issuer and
1107 * generation qualifier (e.g., "Jr.", "3rd", or "IV").
1109 The syntax and associated object identifiers (OIDs) for these
1110 attribute types are provided in the ASN.1 modules in Appendix A.
1112 In addition, implementations of this specification MUST be prepared
1113 to receive the domainComponent attribute, as defined in [RFC 2247].
1114 The Domain Name System (DNS) provides a hierarchical resource
1115 labeling system. This attribute provides a convenient mechanism for
1116 organizations that wish to use DNs that parallel their DNS names.
1117 This is not a replacement for the dNSName component of the
1122 Housley, et. al. Standards Track [Page 20]
1124 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
1127 alternative name field. Implementations are not required to convert
1128 such names into DNS names. The syntax and associated OID for this
1129 attribute type is provided in the ASN.1 modules in Appendix A.
1131 Certificate users MUST be prepared to process the issuer
1132 distinguished name and subject distinguished name (section 4.1.2.6)
1133 fields to perform name chaining for certification path validation
1134 (section 6). Name chaining is performed by matching the issuer
1135 distinguished name in one certificate with the subject name in a CA
1138 This specification requires only a subset of the name comparison
1139 functionality specified in the X.500 series of specifications.
1140 Conforming implementations are REQUIRED to implement the following
1141 name comparison rules:
1143 (a) attribute values encoded in different types (e.g.,
1144 PrintableString and BMPString) MAY be assumed to represent
1147 (b) attribute values in types other than PrintableString are case
1148 sensitive (this permits matching of attribute values as binary
1151 (c) attribute values in PrintableString are not case sensitive
1152 (e.g., "Marianne Swanson" is the same as "MARIANNE SWANSON"); and
1154 (d) attribute values in PrintableString are compared after
1155 removing leading and trailing white space and converting internal
1156 substrings of one or more consecutive white space characters to a
1159 These name comparison rules permit a certificate user to validate
1160 certificates issued using languages or encodings unfamiliar to the
1163 In addition, implementations of this specification MAY use these
1164 comparison rules to process unfamiliar attribute types for name
1165 chaining. This allows implementations to process certificates with
1166 unfamiliar attributes in the issuer name.
1168 Note that the comparison rules defined in the X.500 series of
1169 specifications indicate that the character sets used to encode data
1170 in distinguished names are irrelevant. The characters themselves are
1171 compared without regard to encoding. Implementations of this profile
1172 are permitted to use the comparison algorithm defined in the X.500
1173 series. Such an implementation will recognize a superset of name
1174 matches recognized by the algorithm specified above.
1178 Housley, et. al. Standards Track [Page 21]
1180 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
1185 The certificate validity period is the time interval during which the
1186 CA warrants that it will maintain information about the status of the
1187 certificate. The field is represented as a SEQUENCE of two dates:
1188 the date on which the certificate validity period begins (notBefore)
1189 and the date on which the certificate validity period ends
1190 (notAfter). Both notBefore and notAfter may be encoded as UTCTime or
1193 CAs conforming to this profile MUST always encode certificate
1194 validity dates through the year 2049 as UTCTime; certificate validity
1195 dates in 2050 or later MUST be encoded as GeneralizedTime.
1197 The validity period for a certificate is the period of time from
1198 notBefore through notAfter, inclusive.
1202 The universal time type, UTCTime, is a standard ASN.1 type intended
1203 for representation of dates and time. UTCTime specifies the year
1204 through the two low order digits and time is specified to the
1205 precision of one minute or one second. UTCTime includes either Z
1206 (for Zulu, or Greenwich Mean Time) or a time differential.
1208 For the purposes of this profile, UTCTime values MUST be expressed
1209 Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are
1210 YYMMDDHHMMSSZ), even where the number of seconds is zero. Conforming
1211 systems MUST interpret the year field (YY) as follows:
1213 Where YY is greater than or equal to 50, the year SHALL be
1214 interpreted as 19YY; and
1216 Where YY is less than 50, the year SHALL be interpreted as 20YY.
1218 4.1.2.5.2 GeneralizedTime
1220 The generalized time type, GeneralizedTime, is a standard ASN.1 type
1221 for variable precision representation of time. Optionally, the
1222 GeneralizedTime field can include a representation of the time
1223 differential between local and Greenwich Mean Time.
1225 For the purposes of this profile, GeneralizedTime values MUST be
1226 expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e.,
1227 times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero.
1228 GeneralizedTime values MUST NOT include fractional seconds.
1234 Housley, et. al. Standards Track [Page 22]
1236 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
1241 The subject field identifies the entity associated with the public
1242 key stored in the subject public key field. The subject name MAY be
1243 carried in the subject field and/or the subjectAltName extension. If
1244 the subject is a CA (e.g., the basic constraints extension, as
1245 discussed in 4.2.1.10, is present and the value of cA is TRUE), then
1246 the subject field MUST be populated with a non-empty distinguished
1247 name matching the contents of the issuer field (section 4.1.2.4) in
1248 all certificates issued by the subject CA. If the subject is a CRL
1249 issuer (e.g., the key usage extension, as discussed in 4.2.1.3, is
1250 present and the value of cRLSign is TRUE) then the subject field MUST
1251 be populated with a non-empty distinguished name matching the
1252 contents of the issuer field (section 4.1.2.4) in all CRLs issued by
1253 the subject CRL issuer. If subject naming information is present
1254 only in the subjectAltName extension (e.g., a key bound only to an
1255 email address or URI), then the subject name MUST be an empty
1256 sequence and the subjectAltName extension MUST be critical.
1258 Where it is non-empty, the subject field MUST contain an X.500
1259 distinguished name (DN). The DN MUST be unique for each subject
1260 entity certified by the one CA as defined by the issuer name field.
1261 A CA MAY issue more than one certificate with the same DN to the same
1264 The subject name field is defined as the X.501 type Name.
1265 Implementation requirements for this field are those defined for the
1266 issuer field (section 4.1.2.4). When encoding attribute values of
1267 type DirectoryString, the encoding rules for the issuer field MUST be
1268 implemented. Implementations of this specification MUST be prepared
1269 to receive subject names containing the attribute types required for
1270 the issuer field. Implementations of this specification SHOULD be
1271 prepared to receive subject names containing the recommended
1272 attribute types for the issuer field. The syntax and associated
1273 object identifiers (OIDs) for these attribute types are provided in
1274 the ASN.1 modules in Appendix A. Implementations of this
1275 specification MAY use these comparison rules to process unfamiliar
1276 attribute types (i.e., for name chaining). This allows
1277 implementations to process certificates with unfamiliar attributes in
1280 In addition, legacy implementations exist where an RFC 822 name is
1281 embedded in the subject distinguished name as an EmailAddress
1282 attribute. The attribute value for EmailAddress is of type IA5String
1283 to permit inclusion of the character '@', which is not part of the
1284 PrintableString character set. EmailAddress attribute values are not
1285 case sensitive (e.g., "fanfeedback@redsox.com" is the same as
1286 "FANFEEDBACK@REDSOX.COM").
1290 Housley, et. al. Standards Track [Page 23]
1292 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
1295 Conforming implementations generating new certificates with
1296 electronic mail addresses MUST use the rfc822Name in the subject
1297 alternative name field (section 4.2.1.7) to describe such identities.
1298 Simultaneous inclusion of the EmailAddress attribute in the subject
1299 distinguished name to support legacy implementations is deprecated
1302 4.1.2.7 Subject Public Key Info
1304 This field is used to carry the public key and identify the algorithm
1305 with which the key is used (e.g., RSA, DSA, or Diffie-Hellman). The
1306 algorithm is identified using the AlgorithmIdentifier structure
1307 specified in section 4.1.1.2. The object identifiers for the
1308 supported algorithms and the methods for encoding the public key
1309 materials (public key and parameters) are specified in [PKIXALGS].
1311 4.1.2.8 Unique Identifiers
1313 These fields MUST only appear if the version is 2 or 3 (section
1314 4.1.2.1). These fields MUST NOT appear if the version is 1. The
1315 subject and issuer unique identifiers are present in the certificate
1316 to handle the possibility of reuse of subject and/or issuer names
1317 over time. This profile RECOMMENDS that names not be reused for
1318 different entities and that Internet certificates not make use of
1319 unique identifiers. CAs conforming to this profile SHOULD NOT
1320 generate certificates with unique identifiers. Applications
1321 conforming to this profile SHOULD be capable of parsing unique
1326 This field MUST only appear if the version is 3 (section 4.1.2.1).
1327 If present, this field is a SEQUENCE of one or more certificate
1328 extensions. The format and content of certificate extensions in the
1329 Internet PKI is defined in section 4.2.
1331 4.2 Certificate Extensions
1333 The extensions defined for X.509 v3 certificates provide methods for
1334 associating additional attributes with users or public keys and for
1335 managing a certification hierarchy. The X.509 v3 certificate format
1336 also allows communities to define private extensions to carry
1337 information unique to those communities. Each extension in a
1338 certificate is designated as either critical or non-critical. A
1339 certificate using system MUST reject the certificate if it encounters
1340 a critical extension it does not recognize; however, a non-critical
1341 extension MAY be ignored if it is not recognized. The following
1342 sections present recommended extensions used within Internet
1346 Housley, et. al. Standards Track [Page 24]
1348 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
1351 certificates and standard locations for information. Communities may
1352 elect to use additional extensions; however, caution ought to be
1353 exercised in adopting any critical extensions in certificates which
1354 might prevent use in a general context.
1356 Each extension includes an OID and an ASN.1 structure. When an
1357 extension appears in a certificate, the OID appears as the field
1358 extnID and the corresponding ASN.1 encoded structure is the value of
1359 the octet string extnValue. A certificate MUST NOT include more than
1360 one instance of a particular extension. For example, a certificate
1361 may contain only one authority key identifier extension (section
1362 4.2.1.1). An extension includes the boolean critical, with a default
1363 value of FALSE. The text for each extension specifies the acceptable
1364 values for the critical field.
1366 Conforming CAs MUST support key identifiers (sections 4.2.1.1 and
1367 4.2.1.2), basic constraints (section 4.2.1.10), key usage (section
1368 4.2.1.3), and certificate policies (section 4.2.1.5) extensions. If
1369 the CA issues certificates with an empty sequence for the subject
1370 field, the CA MUST support the subject alternative name extension
1371 (section 4.2.1.7). Support for the remaining extensions is OPTIONAL.
1372 Conforming CAs MAY support extensions that are not identified within
1373 this specification; certificate issuers are cautioned that marking
1374 such extensions as critical may inhibit interoperability.
1376 At a minimum, applications conforming to this profile MUST recognize
1377 the following extensions: key usage (section 4.2.1.3), certificate
1378 policies (section 4.2.1.5), the subject alternative name (section
1379 4.2.1.7), basic constraints (section 4.2.1.10), name constraints
1380 (section 4.2.1.11), policy constraints (section 4.2.1.12), extended
1381 key usage (section 4.2.1.13), and inhibit any-policy (section
1384 In addition, applications conforming to this profile SHOULD recognize
1385 the authority and subject key identifier (sections 4.2.1.1 and
1386 4.2.1.2), and policy mapping (section 4.2.1.6) extensions.
1388 4.2.1 Standard Extensions
1390 This section identifies standard certificate extensions defined in
1391 [X.509] for use in the Internet PKI. Each extension is associated
1392 with an OID defined in [X.509]. These OIDs are members of the id-ce
1393 arc, which is defined by the following:
1395 id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 }
1402 Housley, et. al. Standards Track [Page 25]
1404 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
1407 4.2.1.1 Authority Key Identifier
1409 The authority key identifier extension provides a means of
1410 identifying the public key corresponding to the private key used to
1411 sign a certificate. This extension is used where an issuer has
1412 multiple signing keys (either due to multiple concurrent key pairs or
1413 due to changeover). The identification MAY be based on either the
1414 key identifier (the subject key identifier in the issuer's
1415 certificate) or on the issuer name and serial number.
1417 The keyIdentifier field of the authorityKeyIdentifier extension MUST
1418 be included in all certificates generated by conforming CAs to
1419 facilitate certification path construction. There is one exception;
1420 where a CA distributes its public key in the form of a "self-signed"
1421 certificate, the authority key identifier MAY be omitted. The
1422 signature on a self-signed certificate is generated with the private
1423 key associated with the certificate's subject public key. (This
1424 proves that the issuer possesses both the public and private keys.)
1425 In this case, the subject and authority key identifiers would be
1426 identical, but only the subject key identifier is needed for
1427 certification path building.
1429 The value of the keyIdentifier field SHOULD be derived from the
1430 public key used to verify the certificate's signature or a method
1431 that generates unique values. Two common methods for generating key
1432 identifiers from the public key, and one common method for generating
1433 unique values, are described in section 4.2.1.2. Where a key
1434 identifier has not been previously established, this specification
1435 RECOMMENDS use of one of these methods for generating keyIdentifiers.
1436 Where a key identifier has been previously established, the CA SHOULD
1437 use the previously established identifier.
1439 This profile RECOMMENDS support for the key identifier method by all
1442 This extension MUST NOT be marked critical.
1444 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 }
1446 AuthorityKeyIdentifier ::= SEQUENCE {
1447 keyIdentifier [0] KeyIdentifier OPTIONAL,
1448 authorityCertIssuer [1] GeneralNames OPTIONAL,
1449 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }
1451 KeyIdentifier ::= OCTET STRING
1458 Housley, et. al. Standards Track [Page 26]
1460 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
1463 4.2.1.2 Subject Key Identifier
1465 The subject key identifier extension provides a means of identifying
1466 certificates that contain a particular public key.
1468 To facilitate certification path construction, this extension MUST
1469 appear in all conforming CA certificates, that is, all certificates
1470 including the basic constraints extension (section 4.2.1.10) where
1471 the value of cA is TRUE. The value of the subject key identifier
1472 MUST be the value placed in the key identifier field of the Authority
1473 Key Identifier extension (section 4.2.1.1) of certificates issued by
1474 the subject of this certificate.
1476 For CA certificates, subject key identifiers SHOULD be derived from
1477 the public key or a method that generates unique values. Two common
1478 methods for generating key identifiers from the public key are:
1480 (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
1481 value of the BIT STRING subjectPublicKey (excluding the tag,
1482 length, and number of unused bits).
1484 (2) The keyIdentifier is composed of a four bit type field with
1485 the value 0100 followed by the least significant 60 bits of the
1486 SHA-1 hash of the value of the BIT STRING subjectPublicKey
1487 (excluding the tag, length, and number of unused bit string bits).
1489 One common method for generating unique values is a monotonically
1490 increasing sequence of integers.
1492 For end entity certificates, the subject key identifier extension
1493 provides a means for identifying certificates containing the
1494 particular public key used in an application. Where an end entity
1495 has obtained multiple certificates, especially from multiple CAs, the
1496 subject key identifier provides a means to quickly identify the set
1497 of certificates containing a particular public key. To assist
1498 applications in identifying the appropriate end entity certificate,
1499 this extension SHOULD be included in all end entity certificates.
1501 For end entity certificates, subject key identifiers SHOULD be
1502 derived from the public key. Two common methods for generating key
1503 identifiers from the public key are identified above.
1505 Where a key identifier has not been previously established, this
1506 specification RECOMMENDS use of one of these methods for generating
1507 keyIdentifiers. Where a key identifier has been previously
1508 established, the CA SHOULD use the previously established identifier.
1510 This extension MUST NOT be marked critical.
1514 Housley, et. al. Standards Track [Page 27]
1516 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
1519 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 }
1521 SubjectKeyIdentifier ::= KeyIdentifier
1525 The key usage extension defines the purpose (e.g., encipherment,
1526 signature, certificate signing) of the key contained in the
1527 certificate. The usage restriction might be employed when a key that
1528 could be used for more than one operation is to be restricted. For
1529 example, when an RSA key should be used only to verify signatures on
1530 objects other than public key certificates and CRLs, the
1531 digitalSignature and/or nonRepudiation bits would be asserted.
1532 Likewise, when an RSA key should be used only for key management, the
1533 keyEncipherment bit would be asserted.
1535 This extension MUST appear in certificates that contain public keys
1536 that are used to validate digital signatures on other public key
1537 certificates or CRLs. When this extension appears, it SHOULD be
1540 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 }
1542 KeyUsage ::= BIT STRING {
1543 digitalSignature (0),
1545 keyEncipherment (2),
1546 dataEncipherment (3),
1553 Bits in the KeyUsage type are used as follows:
1555 The digitalSignature bit is asserted when the subject public key
1556 is used with a digital signature mechanism to support security
1557 services other than certificate signing (bit 5), or CRL signing
1558 (bit 6). Digital signature mechanisms are often used for entity
1559 authentication and data origin authentication with integrity.
1561 The nonRepudiation bit is asserted when the subject public key is
1562 used to verify digital signatures used to provide a non-
1563 repudiation service which protects against the signing entity
1564 falsely denying some action, excluding certificate or CRL signing.
1565 In the case of later conflict, a reliable third party may
1566 determine the authenticity of the signed data.
1570 Housley, et. al. Standards Track [Page 28]
1572 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
1575 Further distinctions between the digitalSignature and
1576 nonRepudiation bits may be provided in specific certificate
1579 The keyEncipherment bit is asserted when the subject public key is
1580 used for key transport. For example, when an RSA key is to be
1581 used for key management, then this bit is set.
1583 The dataEncipherment bit is asserted when the subject public key
1584 is used for enciphering user data, other than cryptographic keys.
1586 The keyAgreement bit is asserted when the subject public key is
1587 used for key agreement. For example, when a Diffie-Hellman key is
1588 to be used for key management, then this bit is set.
1590 The keyCertSign bit is asserted when the subject public key is
1591 used for verifying a signature on public key certificates. If the
1592 keyCertSign bit is asserted, then the cA bit in the basic
1593 constraints extension (section 4.2.1.10) MUST also be asserted.
1595 The cRLSign bit is asserted when the subject public key is used
1596 for verifying a signature on certificate revocation list (e.g., a
1597 CRL, delta CRL, or an ARL). This bit MUST be asserted in
1598 certificates that are used to verify signatures on CRLs.
1600 The meaning of the encipherOnly bit is undefined in the absence of
1601 the keyAgreement bit. When the encipherOnly bit is asserted and
1602 the keyAgreement bit is also set, the subject public key may be
1603 used only for enciphering data while performing key agreement.
1605 The meaning of the decipherOnly bit is undefined in the absence of
1606 the keyAgreement bit. When the decipherOnly bit is asserted and
1607 the keyAgreement bit is also set, the subject public key may be
1608 used only for deciphering data while performing key agreement.
1610 This profile does not restrict the combinations of bits that may be
1611 set in an instantiation of the keyUsage extension. However,
1612 appropriate values for keyUsage extensions for particular algorithms
1613 are specified in [PKIXALGS].
1615 4.2.1.4 Private Key Usage Period
1617 This extension SHOULD NOT be used within the Internet PKI. CAs
1618 conforming to this profile MUST NOT generate certificates that
1619 include a critical private key usage period extension.
1626 Housley, et. al. Standards Track [Page 29]
1628 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
1631 The private key usage period extension allows the certificate issuer
1632 to specify a different validity period for the private key than the
1633 certificate. This extension is intended for use with digital
1634 signature keys. This extension consists of two optional components,
1635 notBefore and notAfter. The private key associated with the
1636 certificate SHOULD NOT be used to sign objects before or after the
1637 times specified by the two components, respectively. CAs conforming
1638 to this profile MUST NOT generate certificates with private key usage
1639 period extensions unless at least one of the two components is
1640 present and the extension is non-critical.
1642 Where used, notBefore and notAfter are represented as GeneralizedTime
1643 and MUST be specified and interpreted as defined in section
1646 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 }
1648 PrivateKeyUsagePeriod ::= SEQUENCE {
1649 notBefore [0] GeneralizedTime OPTIONAL,
1650 notAfter [1] GeneralizedTime OPTIONAL }
1652 4.2.1.5 Certificate Policies
1654 The certificate policies extension contains a sequence of one or more
1655 policy information terms, each of which consists of an object
1656 identifier (OID) and optional qualifiers. Optional qualifiers, which
1657 MAY be present, are not expected to change the definition of the
1660 In an end entity certificate, these policy information terms indicate
1661 the policy under which the certificate has been issued and the
1662 purposes for which the certificate may be used. In a CA certificate,
1663 these policy information terms limit the set of policies for
1664 certification paths which include this certificate. When a CA does
1665 not wish to limit the set of policies for certification paths which
1666 include this certificate, it MAY assert the special policy anyPolicy,
1667 with a value of { 2 5 29 32 0 }.
1669 Applications with specific policy requirements are expected to have a
1670 list of those policies which they will accept and to compare the
1671 policy OIDs in the certificate to that list. If this extension is
1672 critical, the path validation software MUST be able to interpret this
1673 extension (including the optional qualifier), or MUST reject the
1676 To promote interoperability, this profile RECOMMENDS that policy
1677 information terms consist of only an OID. Where an OID alone is
1678 insufficient, this profile strongly recommends that use of qualifiers
1682 Housley, et. al. Standards Track [Page 30]
1684 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
1687 be limited to those identified in this section. When qualifiers are
1688 used with the special policy anyPolicy, they MUST be limited to the
1689 qualifiers identified in this section.
1691 This specification defines two policy qualifier types for use by
1692 certificate policy writers and certificate issuers. The qualifier
1693 types are the CPS Pointer and User Notice qualifiers.
1695 The CPS Pointer qualifier contains a pointer to a Certification
1696 Practice Statement (CPS) published by the CA. The pointer is in the
1697 form of a URI. Processing requirements for this qualifier are a
1698 local matter. No action is mandated by this specification regardless
1699 of the criticality value asserted for the extension.
1701 User notice is intended for display to a relying party when a
1702 certificate is used. The application software SHOULD display all
1703 user notices in all certificates of the certification path used,
1704 except that if a notice is duplicated only one copy need be
1705 displayed. To prevent such duplication, this qualifier SHOULD only
1706 be present in end entity certificates and CA certificates issued to
1707 other organizations.
1709 The user notice has two optional fields: the noticeRef field and the
1712 The noticeRef field, if used, names an organization and
1713 identifies, by number, a particular textual statement prepared by
1714 that organization. For example, it might identify the
1715 organization "CertsRUs" and notice number 1. In a typical
1716 implementation, the application software will have a notice file
1717 containing the current set of notices for CertsRUs; the
1718 application will extract the notice text from the file and display
1719 it. Messages MAY be multilingual, allowing the software to select
1720 the particular language message for its own environment.
1722 An explicitText field includes the textual statement directly in
1723 the certificate. The explicitText field is a string with a
1724 maximum size of 200 characters.
1726 If both the noticeRef and explicitText options are included in the
1727 one qualifier and if the application software can locate the notice
1728 text indicated by the noticeRef option, then that text SHOULD be
1729 displayed; otherwise, the explicitText string SHOULD be displayed.
1731 Note: While the explicitText has a maximum size of 200 characters,
1732 some non-conforming CAs exceed this limit. Therefore, certificate
1733 users SHOULD gracefully handle explicitText with more than 200
1738 Housley, et. al. Standards Track [Page 31]
1740 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
1743 id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 }
1745 anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificate-policies 0 }
1747 certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
1749 PolicyInformation ::= SEQUENCE {
1750 policyIdentifier CertPolicyId,
1751 policyQualifiers SEQUENCE SIZE (1..MAX) OF
1752 PolicyQualifierInfo OPTIONAL }
1754 CertPolicyId ::= OBJECT IDENTIFIER
1756 PolicyQualifierInfo ::= SEQUENCE {
1757 policyQualifierId PolicyQualifierId,
1758 qualifier ANY DEFINED BY policyQualifierId }
1760 -- policyQualifierIds for Internet policy qualifiers
1762 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
1763 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 }
1764 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 }
1766 PolicyQualifierId ::=
1767 OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )
1769 Qualifier ::= CHOICE {
1771 userNotice UserNotice }
1773 CPSuri ::= IA5String
1775 UserNotice ::= SEQUENCE {
1776 noticeRef NoticeReference OPTIONAL,
1777 explicitText DisplayText OPTIONAL}
1779 NoticeReference ::= SEQUENCE {
1780 organization DisplayText,
1781 noticeNumbers SEQUENCE OF INTEGER }
1783 DisplayText ::= CHOICE {
1784 ia5String IA5String (SIZE (1..200)),
1785 visibleString VisibleString (SIZE (1..200)),
1786 bmpString BMPString (SIZE (1..200)),
1787 utf8String UTF8String (SIZE (1..200)) }
1794 Housley, et. al. Standards Track [Page 32]
1796 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
1799 4.2.1.6 Policy Mappings
1801 This extension is used in CA certificates. It lists one or more
1802 pairs of OIDs; each pair includes an issuerDomainPolicy and a
1803 subjectDomainPolicy. The pairing indicates the issuing CA considers
1804 its issuerDomainPolicy equivalent to the subject CA's
1805 subjectDomainPolicy.
1807 The issuing CA's users might accept an issuerDomainPolicy for certain
1808 applications. The policy mapping defines the list of policies
1809 associated with the subject CA that may be accepted as comparable to
1810 the issuerDomainPolicy.
1812 Each issuerDomainPolicy named in the policy mapping extension SHOULD
1813 also be asserted in a certificate policies extension in the same
1814 certificate. Policies SHOULD NOT be mapped either to or from the
1815 special value anyPolicy (section 4.2.1.5).
1817 This extension MAY be supported by CAs and/or applications, and it
1818 MUST be non-critical.
1820 id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 }
1822 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
1823 issuerDomainPolicy CertPolicyId,
1824 subjectDomainPolicy CertPolicyId }
1826 4.2.1.7 Subject Alternative Name
1828 The subject alternative names extension allows additional identities
1829 to be bound to the subject of the certificate. Defined options
1830 include an Internet electronic mail address, a DNS name, an IP
1831 address, and a uniform resource identifier (URI). Other options
1832 exist, including completely local definitions. Multiple name forms,
1833 and multiple instances of each name form, MAY be included. Whenever
1834 such identities are to be bound into a certificate, the subject
1835 alternative name (or issuer alternative name) extension MUST be used;
1836 however, a DNS name MAY be represented in the subject field using the
1837 domainComponent attribute as described in section 4.1.2.4.
1839 Because the subject alternative name is considered to be definitively
1840 bound to the public key, all parts of the subject alternative name
1841 MUST be verified by the CA.
1843 Further, if the only subject identity included in the certificate is
1844 an alternative name form (e.g., an electronic mail address), then the
1845 subject distinguished name MUST be empty (an empty sequence), and the
1850 Housley, et. al. Standards Track [Page 33]
1852 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
1855 subjectAltName extension MUST be present. If the subject field
1856 contains an empty sequence, the subjectAltName extension MUST be
1859 When the subjectAltName extension contains an Internet mail address,
1860 the address MUST be included as an rfc822Name. The format of an
1861 rfc822Name is an "addr-spec" as defined in RFC 822 [RFC 822]. An
1862 addr-spec has the form "local-part@domain". Note that an addr-spec
1863 has no phrase (such as a common name) before it, has no comment (text
1864 surrounded in parentheses) after it, and is not surrounded by "<" and
1865 ">". Note that while upper and lower case letters are allowed in an
1866 RFC 822 addr-spec, no significance is attached to the case.
1868 When the subjectAltName extension contains a iPAddress, the address
1869 MUST be stored in the octet string in "network byte order," as
1870 specified in RFC 791 [RFC 791]. The least significant bit (LSB) of
1871 each octet is the LSB of the corresponding byte in the network
1872 address. For IP Version 4, as specified in RFC 791, the octet string
1873 MUST contain exactly four octets. For IP Version 6, as specified in
1874 RFC 1883, the octet string MUST contain exactly sixteen octets [RFC
1877 When the subjectAltName extension contains a domain name system
1878 label, the domain name MUST be stored in the dNSName (an IA5String).
1879 The name MUST be in the "preferred name syntax," as specified by RFC
1880 1034 [RFC 1034]. Note that while upper and lower case letters are
1881 allowed in domain names, no signifigance is attached to the case. In
1882 addition, while the string " " is a legal domain name, subjectAltName
1883 extensions with a dNSName of " " MUST NOT be used. Finally, the use
1884 of the DNS representation for Internet mail addresses (wpolk.nist.gov
1885 instead of wpolk@nist.gov) MUST NOT be used; such identities are to
1886 be encoded as rfc822Name.
1888 Note: work is currently underway to specify domain names in
1889 international character sets. Such names will likely not be
1890 accommodated by IA5String. Once this work is complete, this profile
1891 will be revisited and the appropriate functionality will be added.
1893 When the subjectAltName extension contains a URI, the name MUST be
1894 stored in the uniformResourceIdentifier (an IA5String). The name
1895 MUST NOT be a relative URL, and it MUST follow the URL syntax and
1896 encoding rules specified in [RFC 1738]. The name MUST include both a
1897 scheme (e.g., "http" or "ftp") and a scheme-specific-part. The
1898 scheme-specific-part MUST include a fully qualified domain name or IP
1899 address as the host.
1906 Housley, et. al. Standards Track [Page 34]
1908 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
1911 As specified in [RFC 1738], the scheme name is not case-sensitive
1912 (e.g., "http" is equivalent to "HTTP"). The host part is also not
1913 case-sensitive, but other components of the scheme-specific-part may
1914 be case-sensitive. When comparing URIs, conforming implementations
1915 MUST compare the scheme and host without regard to case, but assume
1916 the remainder of the scheme-specific-part is case sensitive.
1918 When the subjectAltName extension contains a DN in the directoryName,
1919 the DN MUST be unique for each subject entity certified by the one CA
1920 as defined by the issuer name field. A CA MAY issue more than one
1921 certificate with the same DN to the same subject entity.
1923 The subjectAltName MAY carry additional name types through the use of
1924 the otherName field. The format and semantics of the name are
1925 indicated through the OBJECT IDENTIFIER in the type-id field. The
1926 name itself is conveyed as value field in otherName. For example,
1927 Kerberos [RFC 1510] format names can be encoded into the otherName,
1928 using using a Kerberos 5 principal name OID and a SEQUENCE of the
1929 Realm and the PrincipalName.
1931 Subject alternative names MAY be constrained in the same manner as
1932 subject distinguished names using the name constraints extension as
1933 described in section 4.2.1.11.
1935 If the subjectAltName extension is present, the sequence MUST contain
1936 at least one entry. Unlike the subject field, conforming CAs MUST
1937 NOT issue certificates with subjectAltNames containing empty
1938 GeneralName fields. For example, an rfc822Name is represented as an
1939 IA5String. While an empty string is a valid IA5String, such an
1940 rfc822Name is not permitted by this profile. The behavior of clients
1941 that encounter such a certificate when processing a certificication
1942 path is not defined by this profile.
1944 Finally, the semantics of subject alternative names that include
1945 wildcard characters (e.g., as a placeholder for a set of names) are
1946 not addressed by this specification. Applications with specific
1947 requirements MAY use such names, but they must define the semantics.
1949 id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 }
1951 SubjectAltName ::= GeneralNames
1953 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
1962 Housley, et. al. Standards Track [Page 35]
1964 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
1967 GeneralName ::= CHOICE {
1968 otherName [0] OtherName,
1969 rfc822Name [1] IA5String,
1970 dNSName [2] IA5String,
1971 x400Address [3] ORAddress,
1972 directoryName [4] Name,
1973 ediPartyName [5] EDIPartyName,
1974 uniformResourceIdentifier [6] IA5String,
1975 iPAddress [7] OCTET STRING,
1976 registeredID [8] OBJECT IDENTIFIER }
1978 OtherName ::= SEQUENCE {
1979 type-id OBJECT IDENTIFIER,
1980 value [0] EXPLICIT ANY DEFINED BY type-id }
1982 EDIPartyName ::= SEQUENCE {
1983 nameAssigner [0] DirectoryString OPTIONAL,
1984 partyName [1] DirectoryString }
1986 4.2.1.8 Issuer Alternative Names
1988 As with 4.2.1.7, this extension is used to associate Internet style
1989 identities with the certificate issuer. Issuer alternative names
1990 MUST be encoded as in 4.2.1.7.
1992 Where present, this extension SHOULD NOT be marked critical.
1994 id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 }
1996 IssuerAltName ::= GeneralNames
1998 4.2.1.9 Subject Directory Attributes
2000 The subject directory attributes extension is used to convey
2001 identification attributes (e.g., nationality) of the subject. The
2002 extension is defined as a sequence of one or more attributes. This
2003 extension MUST be non-critical.
2005 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 }
2007 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute
2009 4.2.1.10 Basic Constraints
2011 The basic constraints extension identifies whether the subject of the
2012 certificate is a CA and the maximum depth of valid certification
2013 paths that include this certificate.
2018 Housley, et. al. Standards Track [Page 36]
2020 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
2023 The cA boolean indicates whether the certified public key belongs to
2024 a CA. If the cA boolean is not asserted, then the keyCertSign bit in
2025 the key usage extension MUST NOT be asserted.
2027 The pathLenConstraint field is meaningful only if the cA boolean is
2028 asserted and the key usage extension asserts the keyCertSign bit
2029 (section 4.2.1.3). In this case, it gives the maximum number of non-
2030 self-issued intermediate certificates that may follow this
2031 certificate in a valid certification path. A certificate is self-
2032 issued if the DNs that appear in the subject and issuer fields are
2033 identical and are not empty. (Note: The last certificate in the
2034 certification path is not an intermediate certificate, and is not
2035 included in this limit. Usually, the last certificate is an end
2036 entity certificate, but it can be a CA certificate.) A
2037 pathLenConstraint of zero indicates that only one more certificate
2038 may follow in a valid certification path. Where it appears, the
2039 pathLenConstraint field MUST be greater than or equal to zero. Where
2040 pathLenConstraint does not appear, no limit is imposed.
2042 This extension MUST appear as a critical extension in all CA
2043 certificates that contain public keys used to validate digital
2044 signatures on certificates. This extension MAY appear as a critical
2045 or non-critical extension in CA certificates that contain public keys
2046 used exclusively for purposes other than validating digital
2047 signatures on certificates. Such CA certificates include ones that
2048 contain public keys used exclusively for validating digital
2049 signatures on CRLs and ones that contain key management public keys
2050 used with certificate enrollment protocols. This extension MAY
2051 appear as a critical or non-critical extension in end entity
2054 CAs MUST NOT include the pathLenConstraint field unless the cA
2055 boolean is asserted and the key usage extension asserts the
2058 id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 }
2060 BasicConstraints ::= SEQUENCE {
2061 cA BOOLEAN DEFAULT FALSE,
2062 pathLenConstraint INTEGER (0..MAX) OPTIONAL }
2064 4.2.1.11 Name Constraints
2066 The name constraints extension, which MUST be used only in a CA
2067 certificate, indicates a name space within which all subject names in
2068 subsequent certificates in a certification path MUST be located.
2069 Restrictions apply to the subject distinguished name and apply to
2070 subject alternative names. Restrictions apply only when the
2074 Housley, et. al. Standards Track [Page 37]
2076 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
2079 specified name form is present. If no name of the type is in the
2080 certificate, the certificate is acceptable.
2082 Name constraints are not applied to certificates whose issuer and
2083 subject are identical (unless the certificate is the final
2084 certificate in the path). (This could prevent CAs that use name
2085 constraints from employing self-issued certificates to implement key
2088 Restrictions are defined in terms of permitted or excluded name
2089 subtrees. Any name matching a restriction in the excludedSubtrees
2090 field is invalid regardless of information appearing in the
2091 permittedSubtrees. This extension MUST be critical.
2093 Within this profile, the minimum and maximum fields are not used with
2094 any name forms, thus minimum MUST be zero, and maximum MUST be
2097 For URIs, the constraint applies to the host part of the name. The
2098 constraint MAY specify a host or a domain. Examples would be
2099 "foo.bar.com"; and ".xyz.com". When the the constraint begins with
2100 a period, it MAY be expanded with one or more subdomains. That is,
2101 the constraint ".xyz.com" is satisfied by both abc.xyz.com and
2102 abc.def.xyz.com. However, the constraint ".xyz.com" is not satisfied
2103 by "xyz.com". When the constraint does not begin with a period, it
2106 A name constraint for Internet mail addresses MAY specify a
2107 particular mailbox, all addresses at a particular host, or all
2108 mailboxes in a domain. To indicate a particular mailbox, the
2109 constraint is the complete mail address. For example, "root@xyz.com"
2110 indicates the root mailbox on the host "xyz.com". To indicate all
2111 Internet mail addresses on a particular host, the constraint is
2112 specified as the host name. For example, the constraint "xyz.com" is
2113 satisfied by any mail address at the host "xyz.com". To specify any
2114 address within a domain, the constraint is specified with a leading
2115 period (as with URIs). For example, ".xyz.com" indicates all the
2116 Internet mail addresses in the domain "xyz.com", but not Internet
2117 mail addresses on the host "xyz.com".
2119 DNS name restrictions are expressed as foo.bar.com. Any DNS name
2120 that can be constructed by simply adding to the left hand side of the
2121 name satisfies the name constraint. For example, www.foo.bar.com
2122 would satisfy the constraint but foo1.bar.com would not.
2124 Legacy implementations exist where an RFC 822 name is embedded in the
2125 subject distinguished name in an attribute of type EmailAddress
2126 (section 4.1.2.6). When rfc822 names are constrained, but the
2130 Housley, et. al. Standards Track [Page 38]
2132 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
2135 certificate does not include a subject alternative name, the rfc822
2136 name constraint MUST be applied to the attribute of type EmailAddress
2137 in the subject distinguished name. The ASN.1 syntax for EmailAddress
2138 and the corresponding OID are supplied in Appendix A.
2140 Restrictions of the form directoryName MUST be applied to the subject
2141 field in the certificate and to the subjectAltName extensions of type
2142 directoryName. Restrictions of the form x400Address MUST be applied
2143 to subjectAltName extensions of type x400Address.
2145 When applying restrictions of the form directoryName, an
2146 implementation MUST compare DN attributes. At a minimum,
2147 implementations MUST perform the DN comparison rules specified in
2148 Section 4.1.2.4. CAs issuing certificates with a restriction of the
2149 form directoryName SHOULD NOT rely on implementation of the full ISO
2150 DN name comparison algorithm. This implies name restrictions MUST be
2151 stated identically to the encoding used in the subject field or
2152 subjectAltName extension.
2154 The syntax of iPAddress MUST be as described in section 4.2.1.7 with
2155 the following additions specifically for Name Constraints. For IPv4
2156 addresses, the ipAddress field of generalName MUST contain eight (8)
2157 octets, encoded in the style of RFC 1519 (CIDR) to represent an
2158 address range [RFC 1519]. For IPv6 addresses, the ipAddress field
2159 MUST contain 32 octets similarly encoded. For example, a name
2160 constraint for "class C" subnet 10.9.8.0 is represented as the octets
2161 0A 09 08 00 FF FF FF 00, representing the CIDR notation
2162 10.9.8.0/255.255.255.0.
2164 The syntax and semantics for name constraints for otherName,
2165 ediPartyName, and registeredID are not defined by this specification.
2167 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 }
2169 NameConstraints ::= SEQUENCE {
2170 permittedSubtrees [0] GeneralSubtrees OPTIONAL,
2171 excludedSubtrees [1] GeneralSubtrees OPTIONAL }
2173 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
2175 GeneralSubtree ::= SEQUENCE {
2177 minimum [0] BaseDistance DEFAULT 0,
2178 maximum [1] BaseDistance OPTIONAL }
2180 BaseDistance ::= INTEGER (0..MAX)
2186 Housley, et. al. Standards Track [Page 39]
2188 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
2191 4.2.1.12 Policy Constraints
2193 The policy constraints extension can be used in certificates issued
2194 to CAs. The policy constraints extension constrains path validation
2195 in two ways. It can be used to prohibit policy mapping or require
2196 that each certificate in a path contain an acceptable policy
2199 If the inhibitPolicyMapping field is present, the value indicates the
2200 number of additional certificates that may appear in the path before
2201 policy mapping is no longer permitted. For example, a value of one
2202 indicates that policy mapping may be processed in certificates issued
2203 by the subject of this certificate, but not in additional
2204 certificates in the path.
2206 If the requireExplicitPolicy field is present, the value of
2207 requireExplicitPolicy indicates the number of additional certificates
2208 that may appear in the path before an explicit policy is required for
2209 the entire path. When an explicit policy is required, it is
2210 necessary for all certificates in the path to contain an acceptable
2211 policy identifier in the certificate policies extension. An
2212 acceptable policy identifier is the identifier of a policy required
2213 by the user of the certification path or the identifier of a policy
2214 which has been declared equivalent through policy mapping.
2216 Conforming CAs MUST NOT issue certificates where policy constraints
2217 is a empty sequence. That is, at least one of the
2218 inhibitPolicyMapping field or the requireExplicitPolicy field MUST be
2219 present. The behavior of clients that encounter a empty policy
2220 constraints field is not addressed in this profile.
2222 This extension MAY be critical or non-critical.
2224 id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 }
2226 PolicyConstraints ::= SEQUENCE {
2227 requireExplicitPolicy [0] SkipCerts OPTIONAL,
2228 inhibitPolicyMapping [1] SkipCerts OPTIONAL }
2230 SkipCerts ::= INTEGER (0..MAX)
2232 4.2.1.13 Extended Key Usage
2234 This extension indicates one or more purposes for which the certified
2235 public key may be used, in addition to or in place of the basic
2236 purposes indicated in the key usage extension. In general, this
2237 extension will appear only in end entity certificates. This
2238 extension is defined as follows:
2242 Housley, et. al. Standards Track [Page 40]
2244 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
2247 id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 }
2249 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
2251 KeyPurposeId ::= OBJECT IDENTIFIER
2253 Key purposes may be defined by any organization with a need. Object
2254 identifiers used to identify key purposes MUST be assigned in
2255 accordance with IANA or ITU-T Recommendation X.660 [X.660].
2257 This extension MAY, at the option of the certificate issuer, be
2258 either critical or non-critical.
2260 If the extension is present, then the certificate MUST only be used
2261 for one of the purposes indicated. If multiple purposes are
2262 indicated the application need not recognize all purposes indicated,
2263 as long as the intended purpose is present. Certificate using
2264 applications MAY require that a particular purpose be indicated in
2265 order for the certificate to be acceptable to that application.
2267 If a CA includes extended key usages to satisfy such applications,
2268 but does not wish to restrict usages of the key, the CA can include
2269 the special keyPurposeID anyExtendedKeyUsage. If the
2270 anyExtendedKeyUsage keyPurposeID is present, the extension SHOULD NOT
2273 If a certificate contains both a key usage extension and an extended
2274 key usage extension, then both extensions MUST be processed
2275 independently and the certificate MUST only be used for a purpose
2276 consistent with both extensions. If there is no purpose consistent
2277 with both extensions, then the certificate MUST NOT be used for any
2280 The following key usage purposes are defined:
2282 anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 }
2284 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
2286 id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
2287 -- TLS WWW server authentication
2288 -- Key usage bits that may be consistent: digitalSignature,
2289 -- keyEncipherment or keyAgreement
2291 id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 }
2292 -- TLS WWW client authentication
2293 -- Key usage bits that may be consistent: digitalSignature
2294 -- and/or keyAgreement
2298 Housley, et. al. Standards Track [Page 41]
2300 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
2303 id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 }
2304 -- Signing of downloadable executable code
2305 -- Key usage bits that may be consistent: digitalSignature
2307 id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 }
2308 -- E-mail protection
2309 -- Key usage bits that may be consistent: digitalSignature,
2310 -- nonRepudiation, and/or (keyEncipherment or keyAgreement)
2312 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }
2313 -- Binding the hash of an object to a time
2314 -- Key usage bits that may be consistent: digitalSignature
2315 -- and/or nonRepudiation
2317 id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }
2318 -- Signing OCSP responses
2319 -- Key usage bits that may be consistent: digitalSignature
2320 -- and/or nonRepudiation
2322 4.2.1.14 CRL Distribution Points
2324 The CRL distribution points extension identifies how CRL information
2325 is obtained. The extension SHOULD be non-critical, but this profile
2326 RECOMMENDS support for this extension by CAs and applications.
2327 Further discussion of CRL management is contained in section 5.
2329 The cRLDistributionPoints extension is a SEQUENCE of
2330 DistributionPoint. A DistributionPoint consists of three fields,
2331 each of which is optional: distributionPoint, reasons, and cRLIssuer.
2332 While each of these fields is optional, a DistributionPoint MUST NOT
2333 consist of only the reasons field; either distributionPoint or
2334 cRLIssuer MUST be present. If the certificate issuer is not the CRL
2335 issuer, then the cRLIssuer field MUST be present and contain the Name
2336 of the CRL issuer. If the certificate issuer is also the CRL issuer,
2337 then the cRLIssuer field MUST be omitted and the distributionPoint
2338 field MUST be present. If the distributionPoint field is omitted,
2339 cRLIssuer MUST be present and include a Name corresponding to an
2340 X.500 or LDAP directory entry where the CRL is located.
2342 When the distributionPoint field is present, it contains either a
2343 SEQUENCE of general names or a single value, nameRelativeToCRLIssuer.
2344 If the cRLDistributionPoints extension contains a general name of
2345 type URI, the following semantics MUST be assumed: the URI is a
2346 pointer to the current CRL for the associated reasons and will be
2347 issued by the associated cRLIssuer. The expected values for the URI
2348 are those defined in 4.2.1.7. Processing rules for other values are
2349 not defined by this specification.
2354 Housley, et. al. Standards Track [Page 42]
2356 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
2359 If the DistributionPointName contains multiple values, each name
2360 describes a different mechanism to obtain the same CRL. For example,
2361 the same CRL could be available for retrieval through both LDAP and
2364 If the DistributionPointName contains the single value
2365 nameRelativeToCRLIssuer, the value provides a distinguished name
2366 fragment. The fragment is appended to the X.500 distinguished name
2367 of the CRL issuer to obtain the distribution point name. If the
2368 cRLIssuer field in the DistributionPoint is present, then the name
2369 fragment is appended to the distinguished name that it contains;
2370 otherwise, the name fragment is appended to the certificate issuer
2371 distinguished name. The DistributionPointName MUST NOT use the
2372 nameRealtiveToCRLIssuer alternative when cRLIssuer contains more than
2373 one distinguished name.
2375 If the DistributionPoint omits the reasons field, the CRL MUST
2376 include revocation information for all reasons.
2378 The cRLIssuer identifies the entity who signs and issues the CRL. If
2379 present, the cRLIssuer MUST contain at least one an X.500
2380 distinguished name (DN), and MAY also contain other name forms.
2381 Since the cRLIssuer is compared to the CRL issuer name, the X.501
2382 type Name MUST follow the encoding rules for the issuer name field in
2383 the certificate (section 4.1.2.4).
2385 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 }
2387 CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
2389 DistributionPoint ::= SEQUENCE {
2390 distributionPoint [0] DistributionPointName OPTIONAL,
2391 reasons [1] ReasonFlags OPTIONAL,
2392 cRLIssuer [2] GeneralNames OPTIONAL }
2394 DistributionPointName ::= CHOICE {
2395 fullName [0] GeneralNames,
2396 nameRelativeToCRLIssuer [1] RelativeDistinguishedName }
2410 Housley, et. al. Standards Track [Page 43]
2412 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
2415 ReasonFlags ::= BIT STRING {
2419 affiliationChanged (3),
2421 cessationOfOperation (5),
2422 certificateHold (6),
2423 privilegeWithdrawn (7),
2426 4.2.1.15 Inhibit Any-Policy
2428 The inhibit any-policy extension can be used in certificates issued
2429 to CAs. The inhibit any-policy indicates that the special anyPolicy
2430 OID, with the value { 2 5 29 32 0 }, is not considered an explicit
2431 match for other certificate policies. The value indicates the number
2432 of additional certificates that may appear in the path before
2433 anyPolicy is no longer permitted. For example, a value of one
2434 indicates that anyPolicy may be processed in certificates issued by
2435 the subject of this certificate, but not in additional certificates
2438 This extension MUST be critical.
2440 id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 }
2442 InhibitAnyPolicy ::= SkipCerts
2444 SkipCerts ::= INTEGER (0..MAX)
2446 4.2.1.16 Freshest CRL (a.k.a. Delta CRL Distribution Point)
2448 The freshest CRL extension identifies how delta CRL information is
2449 obtained. The extension MUST be non-critical. Further discussion of
2450 CRL management is contained in section 5.
2452 The same syntax is used for this extension and the
2453 cRLDistributionPoints extension, and is described in section
2454 4.2.1.14. The same conventions apply to both extensions.
2456 id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 }
2458 FreshestCRL ::= CRLDistributionPoints
2466 Housley, et. al. Standards Track [Page 44]
2468 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
2471 4.2.2 Private Internet Extensions
2473 This section defines two extensions for use in the Internet Public
2474 Key Infrastructure. These extensions may be used to direct
2475 applications to on-line information about the issuing CA or the
2476 subject. As the information may be available in multiple forms, each
2477 extension is a sequence of IA5String values, each of which represents
2478 a URI. The URI implicitly specifies the location and format of the
2479 information and the method for obtaining the information.
2481 An object identifier is defined for the private extension. The
2482 object identifier associated with the private extension is defined
2483 under the arc id-pe within the arc id-pkix. Any future extensions
2484 defined for the Internet PKI are also expected to be defined under
2487 id-pkix OBJECT IDENTIFIER ::=
2488 { iso(1) identified-organization(3) dod(6) internet(1)
2489 security(5) mechanisms(5) pkix(7) }
2491 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
2493 4.2.2.1 Authority Information Access
2495 The authority information access extension indicates how to access CA
2496 information and services for the issuer of the certificate in which
2497 the extension appears. Information and services may include on-line
2498 validation services and CA policy data. (The location of CRLs is not
2499 specified in this extension; that information is provided by the
2500 cRLDistributionPoints extension.) This extension may be included in
2501 end entity or CA certificates, and it MUST be non-critical.
2503 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }
2505 AuthorityInfoAccessSyntax ::=
2506 SEQUENCE SIZE (1..MAX) OF AccessDescription
2508 AccessDescription ::= SEQUENCE {
2509 accessMethod OBJECT IDENTIFIER,
2510 accessLocation GeneralName }
2512 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
2514 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }
2516 id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }
2522 Housley, et. al. Standards Track [Page 45]
2524 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
2527 Each entry in the sequence AuthorityInfoAccessSyntax describes the
2528 format and location of additional information provided by the CA that
2529 issued the certificate in which this extension appears. The type and
2530 format of the information is specified by the accessMethod field; the
2531 accessLocation field specifies the location of the information. The
2532 retrieval mechanism may be implied by the accessMethod or specified
2535 This profile defines two accessMethod OIDs: id-ad-caIssuers and
2538 The id-ad-caIssuers OID is used when the additional information lists
2539 CAs that have issued certificates superior to the CA that issued the
2540 certificate containing this extension. The referenced CA issuers
2541 description is intended to aid certificate users in the selection of
2542 a certification path that terminates at a point trusted by the
2545 When id-ad-caIssuers appears as accessMethod, the accessLocation
2546 field describes the referenced description server and the access
2547 protocol to obtain the referenced description. The accessLocation
2548 field is defined as a GeneralName, which can take several forms.
2549 Where the information is available via http, ftp, or ldap,
2550 accessLocation MUST be a uniformResourceIdentifier. Where the
2551 information is available via the Directory Access Protocol (DAP),
2552 accessLocation MUST be a directoryName. The entry for that
2553 directoryName contains CA certificates in the crossCertificatePair
2554 attribute. When the information is available via electronic mail,
2555 accessLocation MUST be an rfc822Name. The semantics of other
2556 id-ad-caIssuers accessLocation name forms are not defined.
2558 The id-ad-ocsp OID is used when revocation information for the
2559 certificate containing this extension is available using the Online
2560 Certificate Status Protocol (OCSP) [RFC 2560].
2562 When id-ad-ocsp appears as accessMethod, the accessLocation field is
2563 the location of the OCSP responder, using the conventions defined in
2566 Additional access descriptors may be defined in other PKIX
2569 4.2.2.2 Subject Information Access
2571 The subject information access extension indicates how to access
2572 information and services for the subject of the certificate in which
2573 the extension appears. When the subject is a CA, information and
2574 services may include certificate validation services and CA policy
2578 Housley, et. al. Standards Track [Page 46]
2580 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
2583 data. When the subject is an end entity, the information describes
2584 the type of services offered and how to access them. In this case,
2585 the contents of this extension are defined in the protocol
2586 specifications for the suported services. This extension may be
2587 included in subject or CA certificates, and it MUST be non-critical.
2589 id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 }
2591 SubjectInfoAccessSyntax ::=
2592 SEQUENCE SIZE (1..MAX) OF AccessDescription
2594 AccessDescription ::= SEQUENCE {
2595 accessMethod OBJECT IDENTIFIER,
2596 accessLocation GeneralName }
2598 Each entry in the sequence SubjectInfoAccessSyntax describes the
2599 format and location of additional information provided by the subject
2600 of the certificate in which this extension appears. The type and
2601 format of the information is specified by the accessMethod field; the
2602 accessLocation field specifies the location of the information. The
2603 retrieval mechanism may be implied by the accessMethod or specified
2606 This profile defines one access method to be used when the subject is
2607 a CA, and one access method to be used when the subject is an end
2608 entity. Additional access methods may be defined in the future in
2609 the protocol specifications for other services.
2611 The id-ad-caRepository OID is used when the subject is a CA, and
2612 publishes its certificates and CRLs (if issued) in a repository. The
2613 accessLocation field is defined as a GeneralName, which can take
2614 several forms. Where the information is available via http, ftp, or
2615 ldap, accessLocation MUST be a uniformResourceIdentifier. Where the
2616 information is available via the directory access protocol (dap),
2617 accessLocation MUST be a directoryName. When the information is
2618 available via electronic mail, accessLocation MUST be an rfc822Name.
2619 The semantics of other name forms of of accessLocation (when
2620 accessMethod is id-ad-caRepository) are not defined by this
2623 The id-ad-timeStamping OID is used when the subject offers
2624 timestamping services using the Time Stamp Protocol defined in
2625 [PKIXTSA]. Where the timestamping services are available via http or
2626 ftp, accessLocation MUST be a uniformResourceIdentifier. Where the
2627 timestamping services are available via electronic mail,
2628 accessLocation MUST be an rfc822Name. Where timestamping services
2634 Housley, et. al. Standards Track [Page 47]
2636 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
2639 are available using TCP/IP, the dNSName or ipAddress name forms may
2640 be used. The semantics of other name forms of accessLocation (when
2641 accessMethod is id-ad-timeStamping) are not defined by this
2644 Additional access descriptors may be defined in other PKIX
2647 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
2649 id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 }
2651 id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 }
2653 5 CRL and CRL Extensions Profile
2655 As discussed above, one goal of this X.509 v2 CRL profile is to
2656 foster the creation of an interoperable and reusable Internet PKI.
2657 To achieve this goal, guidelines for the use of extensions are
2658 specified, and some assumptions are made about the nature of
2659 information included in the CRL.
2661 CRLs may be used in a wide range of applications and environments
2662 covering a broad spectrum of interoperability goals and an even
2663 broader spectrum of operational and assurance requirements. This
2664 profile establishes a common baseline for generic applications
2665 requiring broad interoperability. The profile defines a set of
2666 information that can be expected in every CRL. Also, the profile
2667 defines common locations within the CRL for frequently used
2668 attributes as well as common representations for these attributes.
2670 CRL issuers issue CRLs. In general, the CRL issuer is the CA. CAs
2671 publish CRLs to provide status information about the certificates
2672 they issued. However, a CA may delegate this responsibility to
2673 another trusted authority. Whenever the CRL issuer is not the CA
2674 that issued the certificates, the CRL is referred to as an indirect
2677 Each CRL has a particular scope. The CRL scope is the set of
2678 certificates that could appear on a given CRL. For example, the
2679 scope could be "all certificates issued by CA X", "all CA
2680 certificates issued by CA X", "all certificates issued by CA X that
2681 have been revoked for reasons of key compromise and CA compromise",
2682 or could be a set of certificates based on arbitrary local
2683 information, such as "all certificates issued to the NIST employees
2684 located in Boulder".
2690 Housley, et. al. Standards Track [Page 48]
2692 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
2695 A complete CRL lists all unexpired certificates, within its scope,
2696 that have been revoked for one of the revocation reasons covered by
2697 the CRL scope. The CRL issuer MAY also generate delta CRLs. A delta
2698 CRL only lists those certificates, within its scope, whose revocation
2699 status has changed since the issuance of a referenced complete CRL.
2700 The referenced complete CRL is referred to as a base CRL. The scope
2701 of a delta CRL MUST be the same as the base CRL that it references.
2703 This profile does not define any private Internet CRL extensions or
2704 CRL entry extensions.
2706 Environments with additional or special purpose requirements may
2707 build on this profile or may replace it.
2709 Conforming CAs are not required to issue CRLs if other revocation or
2710 certificate status mechanisms are provided. When CRLs are issued,
2711 the CRLs MUST be version 2 CRLs, include the date by which the next
2712 CRL will be issued in the nextUpdate field (section 5.1.2.5), include
2713 the CRL number extension (section 5.2.3), and include the authority
2714 key identifier extension (section 5.2.1). Conforming applications
2715 that support CRLs are REQUIRED to process both version 1 and version
2716 2 complete CRLs that provide revocation information for all
2717 certificates issued by one CA. Conforming applications are NOT
2718 REQUIRED to support processing of delta CRLs, indirect CRLs, or CRLs
2719 with a scope other than all certificates issued by one CA.
2723 The X.509 v2 CRL syntax is as follows. For signature calculation,
2724 the data that is to be signed is ASN.1 DER encoded. ASN.1 DER
2725 encoding is a tag, length, value encoding system for each element.
2727 CertificateList ::= SEQUENCE {
2728 tbsCertList TBSCertList,
2729 signatureAlgorithm AlgorithmIdentifier,
2730 signatureValue BIT STRING }
2746 Housley, et. al. Standards Track [Page 49]
2748 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
2751 TBSCertList ::= SEQUENCE {
2752 version Version OPTIONAL,
2753 -- if present, MUST be v2
2754 signature AlgorithmIdentifier,
2757 nextUpdate Time OPTIONAL,
2758 revokedCertificates SEQUENCE OF SEQUENCE {
2759 userCertificate CertificateSerialNumber,
2760 revocationDate Time,
2761 crlEntryExtensions Extensions OPTIONAL
2762 -- if present, MUST be v2
2764 crlExtensions [0] EXPLICIT Extensions OPTIONAL
2765 -- if present, MUST be v2
2768 -- Version, Time, CertificateSerialNumber, and Extensions
2769 -- are all defined in the ASN.1 in section 4.1
2771 -- AlgorithmIdentifier is defined in section 4.1.1.2
2773 The following items describe the use of the X.509 v2 CRL in the
2776 5.1.1 CertificateList Fields
2778 The CertificateList is a SEQUENCE of three required fields. The
2779 fields are described in detail in the following subsections.
2783 The first field in the sequence is the tbsCertList. This field is
2784 itself a sequence containing the name of the issuer, issue date,
2785 issue date of the next list, the optional list of revoked
2786 certificates, and optional CRL extensions. When there are no revoked
2787 certificates, the revoked certificates list is absent. When one or
2788 more certificates are revoked, each entry on the revoked certificate
2789 list is defined by a sequence of user certificate serial number,
2790 revocation date, and optional CRL entry extensions.
2792 5.1.1.2 signatureAlgorithm
2794 The signatureAlgorithm field contains the algorithm identifier for
2795 the algorithm used by the CRL issuer to sign the CertificateList.
2796 The field is of type AlgorithmIdentifier, which is defined in section
2797 4.1.1.2. [PKIXALGS] lists the supported algorithms for this
2798 specification, but other signature algorithms MAY also be supported.
2802 Housley, et. al. Standards Track [Page 50]
2804 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
2807 This field MUST contain the same algorithm identifier as the
2808 signature field in the sequence tbsCertList (section 5.1.2.2).
2810 5.1.1.3 signatureValue
2812 The signatureValue field contains a digital signature computed upon
2813 the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded tbsCertList
2814 is used as the input to the signature function. This signature value
2815 is encoded as a BIT STRING and included in the CRL signatureValue
2816 field. The details of this process are specified for each of the
2817 supported algorithms in [PKIXALGS].
2819 CAs that are also CRL issuers MAY use one private key to digitally
2820 sign certificates and CRLs, or MAY use separate private keys to
2821 digitally sign certificates and CRLs. When separate private keys are
2822 employed, each of the public keys associated with these private keys
2823 is placed in a separate certificate, one with the keyCertSign bit set
2824 in the key usage extension, and one with the cRLSign bit set in the
2825 key usage extension (section 4.2.1.3). When separate private keys
2826 are employed, certificates issued by the CA contain one authority key
2827 identifier, and the corresponding CRLs contain a different authority
2828 key identifier. The use of separate CA certificates for validation
2829 of certificate signatures and CRL signatures can offer improved
2830 security characteristics; however, it imposes a burden on
2831 applications, and it might limit interoperability. Many applications
2832 construct a certification path, and then validate the certification
2833 path (section 6). CRL checking in turn requires a separate
2834 certification path to be constructed and validated for the CA's CRL
2835 signature validation certificate. Applications that perform CRL
2836 checking MUST support certification path validation when certificates
2837 and CRLs are digitally signed with the same CA private key. These
2838 applications SHOULD support certification path validation when
2839 certificates and CRLs are digitally signed with different CA private
2842 5.1.2 Certificate List "To Be Signed"
2844 The certificate list to be signed, or TBSCertList, is a sequence of
2845 required and optional fields. The required fields identify the CRL
2846 issuer, the algorithm used to sign the CRL, the date and time the CRL
2847 was issued, and the date and time by which the CRL issuer will issue
2850 Optional fields include lists of revoked certificates and CRL
2851 extensions. The revoked certificate list is optional to support the
2852 case where a CA has not revoked any unexpired certificates that it
2858 Housley, et. al. Standards Track [Page 51]
2860 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
2863 has issued. The profile requires conforming CRL issuers to use the
2864 CRL number and authority key identifier CRL extensions in all CRLs
2869 This optional field describes the version of the encoded CRL. When
2870 extensions are used, as required by this profile, this field MUST be
2871 present and MUST specify version 2 (the integer value is 1).
2875 This field contains the algorithm identifier for the algorithm used
2876 to sign the CRL. [PKIXALGS] lists OIDs for the most popular
2877 signature algorithms used in the Internet PKI.
2879 This field MUST contain the same algorithm identifier as the
2880 signatureAlgorithm field in the sequence CertificateList (section
2885 The issuer name identifies the entity who has signed and issued the
2886 CRL. The issuer identity is carried in the issuer name field.
2887 Alternative name forms may also appear in the issuerAltName extension
2888 (section 5.2.2). The issuer name field MUST contain an X.500
2889 distinguished name (DN). The issuer name field is defined as the
2890 X.501 type Name, and MUST follow the encoding rules for the issuer
2891 name field in the certificate (section 4.1.2.4).
2895 This field indicates the issue date of this CRL. ThisUpdate may be
2896 encoded as UTCTime or GeneralizedTime.
2898 CRL issuers conforming to this profile MUST encode thisUpdate as
2899 UTCTime for dates through the year 2049. CRL issuers conforming to
2900 this profile MUST encode thisUpdate as GeneralizedTime for dates in
2901 the year 2050 or later.
2903 Where encoded as UTCTime, thisUpdate MUST be specified and
2904 interpreted as defined in section 4.1.2.5.1. Where encoded as
2905 GeneralizedTime, thisUpdate MUST be specified and interpreted as
2906 defined in section 4.1.2.5.2.
2914 Housley, et. al. Standards Track [Page 52]
2916 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
2921 This field indicates the date by which the next CRL will be issued.
2922 The next CRL could be issued before the indicated date, but it will
2923 not be issued any later than the indicated date. CRL issuers SHOULD
2924 issue CRLs with a nextUpdate time equal to or later than all previous
2925 CRLs. nextUpdate may be encoded as UTCTime or GeneralizedTime.
2927 This profile requires inclusion of nextUpdate in all CRLs issued by
2928 conforming CRL issuers. Note that the ASN.1 syntax of TBSCertList
2929 describes this field as OPTIONAL, which is consistent with the ASN.1
2930 structure defined in [X.509]. The behavior of clients processing
2931 CRLs which omit nextUpdate is not specified by this profile.
2933 CRL issuers conforming to this profile MUST encode nextUpdate as
2934 UTCTime for dates through the year 2049. CRL issuers conforming to
2935 this profile MUST encode nextUpdate as GeneralizedTime for dates in
2936 the year 2050 or later.
2938 Where encoded as UTCTime, nextUpdate MUST be specified and
2939 interpreted as defined in section 4.1.2.5.1. Where encoded as
2940 GeneralizedTime, nextUpdate MUST be specified and interpreted as
2941 defined in section 4.1.2.5.2.
2943 5.1.2.6 Revoked Certificates
2945 When there are no revoked certificates, the revoked certificates list
2946 MUST be absent. Otherwise, revoked certificates are listed by their
2947 serial numbers. Certificates revoked by the CA are uniquely
2948 identified by the certificate serial number. The date on which the
2949 revocation occurred is specified. The time for revocationDate MUST
2950 be expressed as described in section 5.1.2.4. Additional information
2951 may be supplied in CRL entry extensions; CRL entry extensions are
2952 discussed in section 5.3.
2956 This field may only appear if the version is 2 (section 5.1.2.1). If
2957 present, this field is a sequence of one or more CRL extensions. CRL
2958 extensions are discussed in section 5.2.
2962 The extensions defined by ANSI X9, ISO/IEC, and ITU-T for X.509 v2
2963 CRLs [X.509] [X9.55] provide methods for associating additional
2964 attributes with CRLs. The X.509 v2 CRL format also allows
2965 communities to define private extensions to carry information unique
2966 to those communities. Each extension in a CRL may be designated as
2970 Housley, et. al. Standards Track [Page 53]
2972 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
2975 critical or non-critical. A CRL validation MUST fail if it
2976 encounters a critical extension which it does not know how to
2977 process. However, an unrecognized non-critical extension may be
2978 ignored. The following subsections present those extensions used
2979 within Internet CRLs. Communities may elect to include extensions in
2980 CRLs which are not defined in this specification. However, caution
2981 should be exercised in adopting any critical extensions in CRLs which
2982 might be used in a general context.
2984 Conforming CRL issuers are REQUIRED to include the authority key
2985 identifier (section 5.2.1) and the CRL number (section 5.2.3)
2986 extensions in all CRLs issued.
2988 5.2.1 Authority Key Identifier
2990 The authority key identifier extension provides a means of
2991 identifying the public key corresponding to the private key used to
2992 sign a CRL. The identification can be based on either the key
2993 identifier (the subject key identifier in the CRL signer's
2994 certificate) or on the issuer name and serial number. This extension
2995 is especially useful where an issuer has more than one signing key,
2996 either due to multiple concurrent key pairs or due to changeover.
2998 Conforming CRL issuers MUST use the key identifier method, and MUST
2999 include this extension in all CRLs issued.
3001 The syntax for this CRL extension is defined in section 4.2.1.1.
3003 5.2.2 Issuer Alternative Name
3005 The issuer alternative names extension allows additional identities
3006 to be associated with the issuer of the CRL. Defined options include
3007 an rfc822 name (electronic mail address), a DNS name, an IP address,
3008 and a URI. Multiple instances of a name and multiple name forms may
3009 be included. Whenever such identities are used, the issuer
3010 alternative name extension MUST be used; however, a DNS name MAY be
3011 represented in the issuer field using the domainComponent attribute
3012 as described in section 4.1.2.4.
3014 The issuerAltName extension SHOULD NOT be marked critical.
3016 The OID and syntax for this CRL extension are defined in section
3026 Housley, et. al. Standards Track [Page 54]
3028 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
3033 The CRL number is a non-critical CRL extension which conveys a
3034 monotonically increasing sequence number for a given CRL scope and
3035 CRL issuer. This extension allows users to easily determine when a
3036 particular CRL supersedes another CRL. CRL numbers also support the
3037 identification of complementary complete CRLs and delta CRLs. CRL
3038 issuers conforming to this profile MUST include this extension in all
3041 If a CRL issuer generates delta CRLs in addition to complete CRLs for
3042 a given scope, the complete CRLs and delta CRLs MUST share one
3043 numbering sequence. If a delta CRL and a complete CRL that cover the
3044 same scope are issued at the same time, they MUST have the same CRL
3045 number and provide the same revocation information. That is, the
3046 combination of the delta CRL and an acceptable complete CRL MUST
3047 provide the same revocation information as the simultaneously issued
3050 If a CRL issuer generates two CRLs (two complete CRLs, two delta
3051 CRLs, or a complete CRL and a delta CRL) for the same scope at
3052 different times, the two CRLs MUST NOT have the same CRL number.
3053 That is, if the this update field (section 5.1.2.4) in the two CRLs
3054 are not identical, the CRL numbers MUST be different.
3056 Given the requirements above, CRL numbers can be expected to contain
3057 long integers. CRL verifiers MUST be able to handle CRLNumber values
3058 up to 20 octets. Conformant CRL issuers MUST NOT use CRLNumber
3059 values longer than 20 octets.
3061 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }
3063 CRLNumber ::= INTEGER (0..MAX)
3065 5.2.4 Delta CRL Indicator
3067 The delta CRL indicator is a critical CRL extension that identifies a
3068 CRL as being a delta CRL. Delta CRLs contain updates to revocation
3069 information previously distributed, rather than all the information
3070 that would appear in a complete CRL. The use of delta CRLs can
3071 significantly reduce network load and processing time in some
3072 environments. Delta CRLs are generally smaller than the CRLs they
3073 update, so applications that obtain delta CRLs consume less network
3074 bandwidth than applications that obtain the corresponding complete
3075 CRLs. Applications which store revocation information in a format
3076 other than the CRL structure can add new revocation information to
3077 the local database without reprocessing information.
3082 Housley, et. al. Standards Track [Page 55]
3084 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
3087 The delta CRL indicator extension contains the single value of type
3088 BaseCRLNumber. The CRL number identifies the CRL, complete for a
3089 given scope, that was used as the starting point in the generation of
3090 this delta CRL. A conforming CRL issuer MUST publish the referenced
3091 base CRL as a complete CRL. The delta CRL contains all updates to
3092 the revocation status for that same scope. The combination of a
3093 delta CRL plus the referenced base CRL is equivalent to a complete
3094 CRL, for the applicable scope, at the time of publication of the
3097 When a conforming CRL issuer generates a delta CRL, the delta CRL
3098 MUST include a critical delta CRL indicator extension.
3100 When a delta CRL is issued, it MUST cover the same set of reasons and
3101 the same set of certificates that were covered by the base CRL it
3102 references. That is, the scope of the delta CRL MUST be the same as
3103 the scope of the complete CRL referenced as the base. The referenced
3104 base CRL and the delta CRL MUST omit the issuing distribution point
3105 extension or contain identical issuing distribution point extensions.
3106 Further, the CRL issuer MUST use the same private key to sign the
3107 delta CRL and any complete CRL that it can be used to update.
3109 An application that supports delta CRLs can construct a CRL that is
3110 complete for a given scope by combining a delta CRL for that scope
3111 with either an issued CRL that is complete for that scope or a
3112 locally constructed CRL that is complete for that scope.
3114 When a delta CRL is combined with a complete CRL or a locally
3115 constructed CRL, the resulting locally constructed CRL has the CRL
3116 number specified in the CRL number extension found in the delta CRL
3117 used in its construction. In addition, the resulting locally
3118 constructed CRL has the thisUpdate and nextUpdate times specified in
3119 the corresponding fields of the delta CRL used in its construction.
3120 In addition, the locally constructed CRL inherits the issuing
3121 distribution point from the delta CRL.
3123 A complete CRL and a delta CRL MAY be combined if the following four
3124 conditions are satisfied:
3126 (a) The complete CRL and delta CRL have the same issuer.
3128 (b) The complete CRL and delta CRL have the same scope. The two
3129 CRLs have the same scope if either of the following conditions are
3132 (1) The issuingDistributionPoint extension is omitted from
3133 both the complete CRL and the delta CRL.
3138 Housley, et. al. Standards Track [Page 56]
3140 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
3143 (2) The issuingDistributionPoint extension is present in both
3144 the complete CRL and the delta CRL, and the values for each of
3145 the fields in the extensions are the same in both CRLs.
3147 (c) The CRL number of the complete CRL is equal to or greater
3148 than the BaseCRLNumber specified in the delta CRL. That is, the
3149 complete CRL contains (at a minimum) all the revocation
3150 information held by the referenced base CRL.
3152 (d) The CRL number of the complete CRL is less than the CRL
3153 number of the delta CRL. That is, the delta CRL follows the
3154 complete CRL in the numbering sequence.
3156 CRL issuers MUST ensure that the combination of a delta CRL and any
3157 appropriate complete CRL accurately reflects the current revocation
3158 status. The CRL issuer MUST include an entry in the delta CRL for
3159 each certificate within the scope of the delta CRL whose status has
3160 changed since the generation of the referenced base CRL:
3162 (a) If the certificate is revoked for a reason included in the
3163 scope of the CRL, list the certificate as revoked.
3165 (b) If the certificate is valid and was listed on the referenced
3166 base CRL or any subsequent CRL with reason code certificateHold,
3167 and the reason code certificateHold is included in the scope of
3168 the CRL, list the certificate with the reason code removeFromCRL.
3170 (c) If the certificate is revoked for a reason outside the scope
3171 of the CRL, but the certificate was listed on the referenced base
3172 CRL or any subsequent CRL with a reason code included in the scope
3173 of this CRL, list the certificate as revoked but omit the reason
3176 (d) If the certificate is revoked for a reason outside the scope
3177 of the CRL and the certificate was neither listed on the
3178 referenced base CRL nor any subsequent CRL with a reason code
3179 included in the scope of this CRL, do not list the certificate on
3182 The status of a certificate is considered to have changed if it is
3183 revoked, placed on hold, released from hold, or if its revocation
3186 It is appropriate to list a certificate with reason code
3187 removeFromCRL on a delta CRL even if the certificate was not on hold
3188 in the referenced base CRL. If the certificate was placed on hold in
3194 Housley, et. al. Standards Track [Page 57]
3196 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
3199 any CRL issued after the base but before this delta CRL and then
3200 released from hold, it MUST be listed on the delta CRL with
3201 revocation reason removeFromCRL.
3203 A CRL issuer MAY optionally list a certificate on a delta CRL with
3204 reason code removeFromCRL if the notAfter time specified in the
3205 certificate precedes the thisUpdate time specified in the delta CRL
3206 and the certificate was listed on the referenced base CRL or in any
3207 CRL issued after the base but before this delta CRL.
3209 If a certificate revocation notice first appears on a delta CRL, then
3210 it is possible for the certificate validity period to expire before
3211 the next complete CRL for the same scope is issued. In this case,
3212 the revocation notice MUST be included in all subsequent delta CRLs
3213 until the revocation notice is included on at least one explicitly
3214 issued complete CRL for this scope.
3216 An application that supports delta CRLs MUST be able to construct a
3217 current complete CRL by combining a previously issued complete CRL
3218 and the most current delta CRL. An application that supports delta
3219 CRLs MAY also be able to construct a current complete CRL by
3220 combining a previously locally constructed complete CRL and the
3221 current delta CRL. A delta CRL is considered to be the current one
3222 if the current time is between the times contained in the thisUpdate
3223 and nextUpdate fields. Under some circumstances, the CRL issuer may
3224 publish one or more delta CRLs before indicated by the nextUpdate
3225 field. If more than one current delta CRL for a given scope is
3226 encountered, the application SHOULD consider the one with the latest
3227 value in thisUpdate to be the most current one.
3229 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }
3231 BaseCRLNumber ::= CRLNumber
3233 5.2.5 Issuing Distribution Point
3235 The issuing distribution point is a critical CRL extension that
3236 identifies the CRL distribution point and scope for a particular CRL,
3237 and it indicates whether the CRL covers revocation for end entity
3238 certificates only, CA certificates only, attribute certificates only,
3240 or a limited set of reason codes. Although the extension is
3241 critical, conforming implementations are not required to support this
3250 Housley, et. al. Standards Track [Page 58]
3252 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
3255 The CRL is signed using the CRL issuer's private key. CRL
3256 Distribution Points do not have their own key pairs. If the CRL is
3257 stored in the X.500 Directory, it is stored in the Directory entry
3258 corresponding to the CRL distribution point, which may be different
3259 than the Directory entry of the CRL issuer.
3261 The reason codes associated with a distribution point MUST be
3262 specified in onlySomeReasons. If onlySomeReasons does not appear,
3263 the distribution point MUST contain revocations for all reason codes.
3264 CAs may use CRL distribution points to partition the CRL on the basis
3265 of compromise and routine revocation. In this case, the revocations
3266 with reason code keyCompromise (1), cACompromise (2), and
3267 aACompromise (8) appear in one distribution point, and the
3268 revocations with other reason codes appear in another distribution
3271 If the distributionPoint field is present and contains a URI, the
3272 following semantics MUST be assumed: the object is a pointer to the
3273 most current CRL issued by this CRL issuer. The URI schemes ftp,
3274 http, mailto [RFC1738] and ldap [RFC1778] are defined for this
3275 purpose. The URI MUST be an absolute pathname, not a relative
3276 pathname, and MUST specify the host.
3278 If the distributionPoint field is absent, the CRL MUST contain
3279 entries for all revoked unexpired certificates issued by the CRL
3280 issuer, if any, within the scope of the CRL.
3282 The CRL issuer MUST assert the indirectCRL boolean, if the scope of
3283 the CRL includes certificates issued by authorities other than the
3284 CRL issuer. The authority responsible for each entry is indicated by
3285 the certificate issuer CRL entry extension (section 5.3.4).
3287 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 }
3289 issuingDistributionPoint ::= SEQUENCE {
3290 distributionPoint [0] DistributionPointName OPTIONAL,
3291 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE,
3292 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE,
3293 onlySomeReasons [3] ReasonFlags OPTIONAL,
3294 indirectCRL [4] BOOLEAN DEFAULT FALSE,
3295 onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
3297 5.2.6 Freshest CRL (a.k.a. Delta CRL Distribution Point)
3299 The freshest CRL extension identifies how delta CRL information for
3300 this complete CRL is obtained. The extension MUST be non-critical.
3301 This extension MUST NOT appear in delta CRLs.
3306 Housley, et. al. Standards Track [Page 59]
3308 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
3311 The same syntax is used for this extension as the
3312 cRLDistributionPoints certificate extension, and is described in
3313 section 4.2.1.14. However, only the distribution point field is
3314 meaningful in this context. The reasons and CRLIssuer fields MUST be
3315 omitted from this CRL extension.
3317 Each distribution point name provides the location at which a delta
3318 CRL for this complete CRL can be found. The scope of these delta
3319 CRLs MUST be the same as the scope of this complete CRL. The
3320 contents of this CRL extension are only used to locate delta CRLs;
3321 the contents are not used to validate the CRL or the referenced delta
3322 CRLs. The encoding conventions defined for distribution points in
3323 section 4.2.1.14 apply to this extension.
3325 id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 }
3327 FreshestCRL ::= CRLDistributionPoints
3329 5.3 CRL Entry Extensions
3331 The CRL entry extensions defined by ISO/IEC, ITU-T, and ANSI X9 for
3332 X.509 v2 CRLs provide methods for associating additional attributes
3333 with CRL entries [X.509] [X9.55]. The X.509 v2 CRL format also
3334 allows communities to define private CRL entry extensions to carry
3335 information unique to those communities. Each extension in a CRL
3336 entry may be designated as critical or non-critical. A CRL
3337 validation MUST fail if it encounters a critical CRL entry extension
3338 which it does not know how to process. However, an unrecognized non-
3339 critical CRL entry extension may be ignored. The following
3340 subsections present recommended extensions used within Internet CRL
3341 entries and standard locations for information. Communities may
3342 elect to use additional CRL entry extensions; however, caution should
3343 be exercised in adopting any critical extensions in CRL entries which
3344 might be used in a general context.
3346 All CRL entry extensions used in this specification are non-critical.
3347 Support for these extensions is optional for conforming CRL issuers
3348 and applications. However, CRL issuers SHOULD include reason codes
3349 (section 5.3.1) and invalidity dates (section 5.3.3) whenever this
3350 information is available.
3354 The reasonCode is a non-critical CRL entry extension that identifies
3355 the reason for the certificate revocation. CRL issuers are strongly
3356 encouraged to include meaningful reason codes in CRL entries;
3357 however, the reason code CRL entry extension SHOULD be absent instead
3358 of using the unspecified (0) reasonCode value.
3362 Housley, et. al. Standards Track [Page 60]
3364 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
3367 id-ce-cRLReason OBJECT IDENTIFIER ::= { id-ce 21 }
3369 -- reasonCode ::= { CRLReason }
3371 CRLReason ::= ENUMERATED {
3375 affiliationChanged (3),
3377 cessationOfOperation (5),
3378 certificateHold (6),
3380 privilegeWithdrawn (9),
3383 5.3.2 Hold Instruction Code
3385 The hold instruction code is a non-critical CRL entry extension that
3386 provides a registered instruction identifier which indicates the
3387 action to be taken after encountering a certificate that has been
3390 id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 }
3392 holdInstructionCode ::= OBJECT IDENTIFIER
3394 The following instruction codes have been defined. Conforming
3395 applications that process this extension MUST recognize the following
3398 holdInstruction OBJECT IDENTIFIER ::=
3399 { iso(1) member-body(2) us(840) x9-57(10040) 2 }
3401 id-holdinstruction-none OBJECT IDENTIFIER ::= {holdInstruction 1}
3402 id-holdinstruction-callissuer
3403 OBJECT IDENTIFIER ::= {holdInstruction 2}
3404 id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3}
3406 Conforming applications which encounter an id-holdinstruction-
3407 callissuer MUST call the certificate issuer or reject the
3408 certificate. Conforming applications which encounter an id-
3409 holdinstruction-reject MUST reject the certificate. The hold
3410 instruction id-holdinstruction-none is semantically equivalent to the
3411 absence of a holdInstructionCode, and its use is strongly deprecated
3412 for the Internet PKI.
3418 Housley, et. al. Standards Track [Page 61]
3420 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
3423 5.3.3 Invalidity Date
3425 The invalidity date is a non-critical CRL entry extension that
3426 provides the date on which it is known or suspected that the private
3427 key was compromised or that the certificate otherwise became invalid.
3428 This date may be earlier than the revocation date in the CRL entry,
3429 which is the date at which the CA processed the revocation. When a
3430 revocation is first posted by a CRL issuer in a CRL, the invalidity
3431 date may precede the date of issue of earlier CRLs, but the
3432 revocation date SHOULD NOT precede the date of issue of earlier CRLs.
3433 Whenever this information is available, CRL issuers are strongly
3434 encouraged to share it with CRL users.
3436 The GeneralizedTime values included in this field MUST be expressed
3437 in Greenwich Mean Time (Zulu), and MUST be specified and interpreted
3438 as defined in section 4.1.2.5.2.
3440 id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 }
3442 invalidityDate ::= GeneralizedTime
3444 5.3.4 Certificate Issuer
3446 This CRL entry extension identifies the certificate issuer associated
3447 with an entry in an indirect CRL, that is, a CRL that has the
3448 indirectCRL indicator set in its issuing distribution point
3449 extension. If this extension is not present on the first entry in an
3450 indirect CRL, the certificate issuer defaults to the CRL issuer. On
3451 subsequent entries in an indirect CRL, if this extension is not
3452 present, the certificate issuer for the entry is the same as that for
3453 the preceding entry. This field is defined as follows:
3455 id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 }
3457 certificateIssuer ::= GeneralNames
3459 If used by conforming CRL issuers, this extension MUST always be
3460 critical. If an implementation ignored this extension it could not
3461 correctly attribute CRL entries to certificates. This specification
3462 RECOMMENDS that implementations recognize this extension.
3464 6 Certification Path Validation
3466 Certification path validation procedures for the Internet PKI are
3467 based on the algorithm supplied in [X.509]. Certification path
3468 processing verifies the binding between the subject distinguished
3469 name and/or subject alternative name and subject public key. The
3470 binding is limited by constraints which are specified in the
3474 Housley, et. al. Standards Track [Page 62]
3476 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
3479 certificates which comprise the path and inputs which are specified
3480 by the relying party. The basic constraints and policy constraints
3481 extensions allow the certification path processing logic to automate
3482 the decision making process.
3484 This section describes an algorithm for validating certification
3485 paths. Conforming implementations of this specification are not
3486 required to implement this algorithm, but MUST provide functionality
3487 equivalent to the external behavior resulting from this procedure.
3488 Any algorithm may be used by a particular implementation so long as
3489 it derives the correct result.
3491 In section 6.1, the text describes basic path validation. Valid
3492 paths begin with certificates issued by a trust anchor. The
3493 algorithm requires the public key of the CA, the CA's name, and any
3494 constraints upon the set of paths which may be validated using this
3497 The selection of a trust anchor is a matter of policy: it could be
3498 the top CA in a hierarchical PKI; the CA that issued the verifier's
3499 own certificate(s); or any other CA in a network PKI. The path
3500 validation procedure is the same regardless of the choice of trust
3501 anchor. In addition, different applications may rely on different
3502 trust anchor, or may accept paths that begin with any of a set of
3505 Section 6.2 describes methods for using the path validation algorithm
3506 in specific implementations. Two specific cases are discussed: the
3507 case where paths may begin with one of several trusted CAs; and where
3508 compatibility with the PEM architecture is required.
3510 Section 6.3 describes the steps necessary to determine if a
3511 certificate is revoked or on hold status when CRLs are the revocation
3512 mechanism used by the certificate issuer.
3514 6.1 Basic Path Validation
3516 This text describes an algorithm for X.509 path processing. A
3517 conformant implementation MUST include an X.509 path processing
3518 procedure that is functionally equivalent to the external behavior of
3519 this algorithm. However, support for some of the certificate
3520 extensions processed in this algorithm are OPTIONAL for compliant
3521 implementations. Clients that do not support these extensions MAY
3522 omit the corresponding steps in the path validation algorithm.
3530 Housley, et. al. Standards Track [Page 63]
3532 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
3535 For example, clients are NOT REQUIRED to support the policy mapping
3536 extension. Clients that do not support this extension MAY omit the
3537 path validation steps where policy mappings are processed. Note that
3538 clients MUST reject the certificate if it contains an unsupported
3541 The algorithm presented in this section validates the certificate
3542 with respect to the current date and time. A conformant
3543 implementation MAY also support validation with respect to some point
3544 in the past. Note that mechanisms are not available for validating a
3545 certificate with respect to a time outside the certificate validity
3548 The trust anchor is an input to the algorithm. There is no
3549 requirement that the same trust anchor be used to validate all
3550 certification paths. Different trust anchors MAY be used to validate
3551 different paths, as discussed further in Section 6.2.
3553 The primary goal of path validation is to verify the binding between
3554 a subject distinguished name or a subject alternative name and
3555 subject public key, as represented in the end entity certificate,
3556 based on the public key of the trust anchor. This requires obtaining
3557 a sequence of certificates that support that binding. The procedure
3558 performed to obtain this sequence of certificates is outside the
3559 scope of this specification.
3561 To meet this goal, the path validation process verifies, among other
3562 things, that a prospective certification path (a sequence of n
3563 certificates) satisfies the following conditions:
3565 (a) for all x in {1, ..., n-1}, the subject of certificate x is
3566 the issuer of certificate x+1;
3568 (b) certificate 1 is issued by the trust anchor;
3570 (c) certificate n is the certificate to be validated; and
3572 (d) for all x in {1, ..., n}, the certificate was valid at the
3575 When the trust anchor is provided in the form of a self-signed
3576 certificate, this self-signed certificate is not included as part of
3577 the prospective certification path. Information about trust anchors
3578 are provided as inputs to the certification path validation algorithm
3586 Housley, et. al. Standards Track [Page 64]
3588 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
3591 A particular certification path may not, however, be appropriate for
3592 all applications. Therefore, an application MAY augment this
3593 algorithm to further limit the set of valid paths. The path
3594 validation process also determines the set of certificate policies
3595 that are valid for this path, based on the certificate policies
3596 extension, policy mapping extension, policy constraints extension,
3597 and inhibit any-policy extension. To achieve this, the path
3598 validation algorithm constructs a valid policy tree. If the set of
3599 certificate policies that are valid for this path is not empty, then
3600 the result will be a valid policy tree of depth n, otherwise the
3601 result will be a null valid policy tree.
3603 A certificate is self-issued if the DNs that appear in the subject
3604 and issuer fields are identical and are not empty. In general, the
3605 issuer and subject of the certificates that make up a path are
3606 different for each certificate. However, a CA may issue a
3607 certificate to itself to support key rollover or changes in
3608 certificate policies. These self-issued certificates are not counted
3609 when evaluating path length or name constraints.
3611 This section presents the algorithm in four basic steps: (1)
3612 initialization, (2) basic certificate processing, (3) preparation for
3613 the next certificate, and (4) wrap-up. Steps (1) and (4) are
3614 performed exactly once. Step (2) is performed for all certificates
3615 in the path. Step (3) is performed for all certificates in the path
3616 except the final certificate. Figure 2 provides a high-level
3617 flowchart of this algorithm.
3642 Housley, et. al. Standards Track [Page 65]
3644 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
3656 +<--------------------+
3659 +----------------+ |
3661 +----------------+ |
3664 +================+ |
3667 +================+ |
3671 +----------------+ +----------------+ |
3672 | Wrap up | | Prepare for | |
3673 +----------------+ | Next Cert | |
3674 | +----------------+ |
3676 +-------+ +--------------+
3681 Figure 2. Certification Path Processing Flowchart
3685 This algorithm assumes the following seven inputs are provided to the
3686 path processing logic:
3688 (a) a prospective certification path of length n.
3690 (b) the current date/time.
3698 Housley, et. al. Standards Track [Page 66]
3700 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
3703 (c) user-initial-policy-set: A set of certificate policy
3704 identifiers naming the policies that are acceptable to the
3705 certificate user. The user-initial-policy-set contains the
3706 special value any-policy if the user is not concerned about
3709 (d) trust anchor information, describing a CA that serves as a
3710 trust anchor for the certification path. The trust anchor
3711 information includes:
3713 (1) the trusted issuer name,
3715 (2) the trusted public key algorithm,
3717 (3) the trusted public key, and
3719 (4) optionally, the trusted public key parameters associated
3720 with the public key.
3722 The trust anchor information may be provided to the path
3723 processing procedure in the form of a self-signed certificate.
3724 The trusted anchor information is trusted because it was delivered
3725 to the path processing procedure by some trustworthy out-of-band
3726 procedure. If the trusted public key algorithm requires
3727 parameters, then the parameters are provided along with the
3730 (e) initial-policy-mapping-inhibit, which indicates if policy
3731 mapping is allowed in the certification path.
3733 (f) initial-explicit-policy, which indicates if the path must be
3734 valid for at least one of the certificate policies in the user-
3737 (g) initial-any-policy-inhibit, which indicates whether the
3738 anyPolicy OID should be processed if it is included in a
3741 6.1.2 Initialization
3743 This initialization phase establishes eleven state variables based
3744 upon the seven inputs:
3746 (a) valid_policy_tree: A tree of certificate policies with their
3747 optional qualifiers; each of the leaves of the tree represents a
3748 valid policy at this stage in the certification path validation.
3749 If valid policies exist at this stage in the certification path
3750 validation, the depth of the tree is equal to the number of
3754 Housley, et. al. Standards Track [Page 67]
3756 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
3759 certificates in the chain that have been processed. If valid
3760 policies do not exist at this stage in the certification path
3761 validation, the tree is set to NULL. Once the tree is set to
3762 NULL, policy processing ceases.
3764 Each node in the valid_policy_tree includes four data objects: the
3765 valid policy, a set of associated policy qualifiers, a set of one
3766 or more expected policy values, and a criticality indicator. If
3767 the node is at depth x, the components of the node have the
3768 following semantics:
3770 (1) The valid_policy is a single policy OID representing a
3771 valid policy for the path of length x.
3773 (2) The qualifier_set is a set of policy qualifiers associated
3774 with the valid policy in certificate x.
3776 (3) The criticality_indicator indicates whether the
3777 certificate policy extension in certificate x was marked as
3780 (4) The expected_policy_set contains one or more policy OIDs
3781 that would satisfy this policy in the certificate x+1.
3783 The initial value of the valid_policy_tree is a single node with
3784 valid_policy anyPolicy, an empty qualifier_set, an
3785 expected_policy_set with the single value anyPolicy, and a
3786 criticality_indicator of FALSE. This node is considered to be at
3789 Figure 3 is a graphic representation of the initial state of the
3790 valid_policy_tree. Additional figures will use this format to
3791 describe changes in the valid_policy_tree during path processing.
3794 | anyPolicy | <---- valid_policy
3796 | {} | <---- qualifier_set
3798 | FALSE | <---- criticality_indicator
3800 | {anyPolicy} | <---- expected_policy_set
3803 Figure 3. Initial value of the valid_policy_tree state variable
3810 Housley, et. al. Standards Track [Page 68]
3812 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
3815 (b) permitted_subtrees: A set of root names for each name type
3816 (e.g., X.500 distinguished names, email addresses, or ip
3817 addresses) defining a set of subtrees within which all subject
3818 names in subsequent certificates in the certification path MUST
3819 fall. This variable includes a set for each name type: the
3820 initial value for the set for Distinguished Names is the set of
3821 all Distinguished names; the initial value for the set of RFC822
3822 names is the set of all RFC822 names, etc.
3824 (c) excluded_subtrees: A set of root names for each name type
3825 (e.g., X.500 distinguished names, email addresses, or ip
3826 addresses) defining a set of subtrees within which no subject name
3827 in subsequent certificates in the certification path may fall.
3828 This variable includes a set for each name type, and the initial
3829 value for each set is empty.
3831 (d) explicit_policy: an integer which indicates if a non-NULL
3832 valid_policy_tree is required. The integer indicates the number of
3833 non-self-issued certificates to be processed before this
3834 requirement is imposed. Once set, this variable may be decreased,
3835 but may not be increased. That is, if a certificate in the path
3836 requires a non-NULL valid_policy_tree, a later certificate can not
3837 remove this requirement. If initial-explicit-policy is set, then
3838 the initial value is 0, otherwise the initial value is n+1.
3840 (e) inhibit_any-policy: an integer which indicates whether the
3841 anyPolicy policy identifier is considered a match. The integer
3842 indicates the number of non-self-issued certificates to be
3843 processed before the anyPolicy OID, if asserted in a certificate,
3844 is ignored. Once set, this variable may be decreased, but may not
3845 be increased. That is, if a certificate in the path inhibits
3846 processing of anyPolicy, a later certificate can not permit it.
3847 If initial-any-policy-inhibit is set, then the initial value is 0,
3848 otherwise the initial value is n+1.
3850 (f) policy_mapping: an integer which indicates if policy mapping
3851 is permitted. The integer indicates the number of non-self-issued
3852 certificates to be processed before policy mapping is inhibited.
3853 Once set, this variable may be decreased, but may not be
3854 increased. That is, if a certificate in the path specifies policy
3855 mapping is not permitted, it can not be overridden by a later
3856 certificate. If initial-policy-mapping-inhibit is set, then the
3857 initial value is 0, otherwise the initial value is n+1.
3859 (g) working_public_key_algorithm: the digital signature algorithm
3860 used to verify the signature of a certificate. The
3861 working_public_key_algorithm is initialized from the trusted
3862 public key algorithm provided in the trust anchor information.
3866 Housley, et. al. Standards Track [Page 69]
3868 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
3871 (h) working_public_key: the public key used to verify the
3872 signature of a certificate. The working_public_key is initialized
3873 from the trusted public key provided in the trust anchor
3876 (i) working_public_key_parameters: parameters associated with the
3877 current public key, that may be required to verify a signature
3878 (depending upon the algorithm). The working_public_key_parameters
3879 variable is initialized from the trusted public key parameters
3880 provided in the trust anchor information.
3882 (j) working_issuer_name: the issuer distinguished name expected
3883 in the next certificate in the chain. The working_issuer_name is
3884 initialized to the trusted issuer provided in the trust anchor
3887 (k) max_path_length: this integer is initialized to n, is
3888 decremented for each non-self-issued certificate in the path, and
3889 may be reduced to the value in the path length constraint field
3890 within the basic constraints extension of a CA certificate.
3892 Upon completion of the initialization steps, perform the basic
3893 certificate processing steps specified in 6.1.3.
3895 6.1.3 Basic Certificate Processing
3897 The basic path processing actions to be performed for certificate i
3898 (for all i in [1..n]) are listed below.
3900 (a) Verify the basic certificate information. The certificate
3901 MUST satisfy each of the following:
3903 (1) The certificate was signed with the
3904 working_public_key_algorithm using the working_public_key and
3905 the working_public_key_parameters.
3907 (2) The certificate validity period includes the current time.
3909 (3) At the current time, the certificate is not revoked and is
3910 not on hold status. This may be determined by obtaining the
3911 appropriate CRL (section 6.3), status information, or by out-
3914 (4) The certificate issuer name is the working_issuer_name.
3922 Housley, et. al. Standards Track [Page 70]
3924 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
3927 (b) If certificate i is self-issued and it is not the final
3928 certificate in the path, skip this step for certificate i.
3929 Otherwise, verify that the subject name is within one of the
3930 permitted_subtrees for X.500 distinguished names, and verify that
3931 each of the alternative names in the subjectAltName extension
3932 (critical or non-critical) is within one of the permitted_subtrees
3935 (c) If certificate i is self-issued and it is not the final
3936 certificate in the path, skip this step for certificate i.
3937 Otherwise, verify that the subject name is not within one of the
3938 excluded_subtrees for X.500 distinguished names, and verify that
3939 each of the alternative names in the subjectAltName extension
3940 (critical or non-critical) is not within one of the
3941 excluded_subtrees for that name type.
3943 (d) If the certificate policies extension is present in the
3944 certificate and the valid_policy_tree is not NULL, process the
3945 policy information by performing the following steps in order:
3947 (1) For each policy P not equal to anyPolicy in the
3948 certificate policies extension, let P-OID denote the OID in
3949 policy P and P-Q denote the qualifier set for policy P.
3950 Perform the following steps in order:
3952 (i) If the valid_policy_tree includes a node of depth i-1
3953 where P-OID is in the expected_policy_set, create a child
3954 node as follows: set the valid_policy to OID-P; set the
3955 qualifier_set to P-Q, and set the expected_policy_set to
3958 For example, consider a valid_policy_tree with a node of
3959 depth i-1 where the expected_policy_set is {Gold, White}.
3960 Assume the certificate policies Gold and Silver appear in
3961 the certificate policies extension of certificate i. The
3962 Gold policy is matched but the Silver policy is not. This
3963 rule will generate a child node of depth i for the Gold
3964 policy. The result is shown as Figure 4.
3978 Housley, et. al. Standards Track [Page 71]
3980 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
3987 +-----------------+ node of depth i-1
4000 +-----------------+ node of depth i
4006 Figure 4. Processing an exact match
4008 (ii) If there was no match in step (i) and the
4009 valid_policy_tree includes a node of depth i-1 with the
4010 valid policy anyPolicy, generate a child node with the
4011 following values: set the valid_policy to P-OID; set the
4012 qualifier_set to P-Q, and set the expected_policy_set to
4015 For example, consider a valid_policy_tree with a node of
4016 depth i-1 where the valid_policy is anyPolicy. Assume the
4017 certificate policies Gold and Silver appear in the
4018 certificate policies extension of certificate i. The Gold
4019 policy does not have a qualifier, but the Silver policy has
4020 the qualifier Q-Silver. If Gold and Silver were not matched
4021 in (i) above, this rule will generate two child nodes of
4022 depth i, one for each policy. The result is shown as Figure
4034 Housley, et. al. Standards Track [Page 72]
4036 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
4043 +-----------------+ node of depth i-1
4052 +-----------------+ +-----------------+
4054 +-----------------+ +-----------------+
4055 | {} | | {Q-Silver} |
4056 +-----------------+ nodes of +-----------------+
4057 | uninitialized | depth i | uninitialized |
4058 +-----------------+ +-----------------+
4059 | {Gold} | | {Silver} |
4060 +-----------------+ +-----------------+
4062 Figure 5. Processing unmatched policies when a leaf node
4065 (2) If the certificate policies extension includes the policy
4066 anyPolicy with the qualifier set AP-Q and either (a)
4067 inhibit_any-policy is greater than 0 or (b) i<n and the
4068 certificate is self-issued, then:
4070 For each node in the valid_policy_tree of depth i-1, for each
4071 value in the expected_policy_set (including anyPolicy) that
4072 does not appear in a child node, create a child node with the
4073 following values: set the valid_policy to the value from the
4074 expected_policy_set in the parent node; set the qualifier_set
4075 to AP-Q, and set the expected_policy_set to the value in the
4076 valid_policy from this node.
4078 For example, consider a valid_policy_tree with a node of depth
4079 i-1 where the expected_policy_set is {Gold, Silver}. Assume
4080 anyPolicy appears in the certificate policies extension of
4081 certificate i, but Gold and Silver do not. This rule will
4082 generate two child nodes of depth i, one for each policy. The
4083 result is shown below as Figure 6.
4090 Housley, et. al. Standards Track [Page 73]
4092 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
4099 +-----------------+ node of depth i-1
4108 +-----------------+ +-----------------+
4110 +-----------------+ +-----------------+
4112 +-----------------+ nodes of +-----------------+
4113 | uninitialized | depth i | uninitialized |
4114 +-----------------+ +-----------------+
4115 | {Gold} | | {Silver} |
4116 +-----------------+ +-----------------+
4118 Figure 6. Processing unmatched policies when the certificate
4119 policies extension specifies anyPolicy
4121 (3) If there is a node in the valid_policy_tree of depth i-1
4122 or less without any child nodes, delete that node. Repeat this
4123 step until there are no nodes of depth i-1 or less without
4126 For example, consider the valid_policy_tree shown in Figure 7
4127 below. The two nodes at depth i-1 that are marked with an 'X'
4128 have no children, and are deleted. Applying this rule to the
4129 resulting tree will cause the node at depth i-2 that is marked
4130 with an 'Y' to be deleted. The following application of the
4131 rule does not cause any nodes to be deleted, and this step is
4146 Housley, et. al. Standards Track [Page 74]
4148 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
4152 | | node of depth i-3
4157 +-----------+ +-----------+ +-----------+
4158 | | | | | Y | nodes of
4159 +-----------+ +-----------+ +-----------+ depth i-2
4163 +-----------+ +-----------+ +-----------+ +-----------+ nodes of
4164 | | | X | | | | X | depth
4165 +-----------+ +-----------+ +-----------+ +-----------+ i-1
4169 +-----------+ +-----------+ +-----------+ +-----------+ nodes of
4170 | | | | | | | | depth
4171 +-----------+ +-----------+ +-----------+ +-----------+ i
4173 Figure 7. Pruning the valid_policy_tree
4175 (4) If the certificate policies extension was marked as
4176 critical, set the criticality_indicator in all nodes of depth i
4177 to TRUE. If the certificate policies extension was not marked
4178 critical, set the criticality_indicator in all nodes of depth i
4181 (e) If the certificate policies extension is not present, set the
4182 valid_policy_tree to NULL.
4184 (f) Verify that either explicit_policy is greater than 0 or the
4185 valid_policy_tree is not equal to NULL;
4187 If any of steps (a), (b), (c), or (f) fails, the procedure
4188 terminates, returning a failure indication and an appropriate reason.
4190 If i is not equal to n, continue by performing the preparatory steps
4191 listed in 6.1.4. If i is equal to n, perform the wrap-up steps
4194 6.1.4 Preparation for Certificate i+1
4196 To prepare for processing of certificate i+1, perform the following
4197 steps for certificate i:
4202 Housley, et. al. Standards Track [Page 75]
4204 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
4207 (a) If a policy mapping extension is present, verify that the
4208 special value anyPolicy does not appear as an issuerDomainPolicy
4209 or a subjectDomainPolicy.
4211 (b) If a policy mapping extension is present, then for each
4212 issuerDomainPolicy ID-P in the policy mapping extension:
4214 (1) If the policy_mapping variable is greater than 0, for each
4215 node in the valid_policy_tree of depth i where ID-P is the
4216 valid_policy, set expected_policy_set to the set of
4217 subjectDomainPolicy values that are specified as equivalent to
4218 ID-P by the policy mapping extension.
4220 If no node of depth i in the valid_policy_tree has a
4221 valid_policy of ID-P but there is a node of depth i with a
4222 valid_policy of anyPolicy, then generate a child node of the
4223 node of depth i-1 that has a valid_policy of anyPolicy as
4226 (i) set the valid_policy to ID-P;
4228 (ii) set the qualifier_set to the qualifier set of the
4229 policy anyPolicy in the certificate policies extension of
4232 (iii) set the criticality_indicator to the criticality of
4233 the certificate policies extension of certificate i;
4235 (iv) and set the expected_policy_set to the set of
4236 subjectDomainPolicy values that are specified as equivalent
4237 to ID-P by the policy mappings extension.
4239 (2) If the policy_mapping variable is equal to 0:
4241 (i) delete each node of depth i in the valid_policy_tree
4242 where ID-P is the valid_policy.
4244 (ii) If there is a node in the valid_policy_tree of depth
4245 i-1 or less without any child nodes, delete that node.
4246 Repeat this step until there are no nodes of depth i-1 or
4247 less without children.
4249 (c) Assign the certificate subject name to working_issuer_name.
4251 (d) Assign the certificate subjectPublicKey to
4258 Housley, et. al. Standards Track [Page 76]
4260 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
4263 (e) If the subjectPublicKeyInfo field of the certificate contains
4264 an algorithm field with non-null parameters, assign the parameters
4265 to the working_public_key_parameters variable.
4267 If the subjectPublicKeyInfo field of the certificate contains an
4268 algorithm field with null parameters or parameters are omitted,
4269 compare the certificate subjectPublicKey algorithm to the
4270 working_public_key_algorithm. If the certificate subjectPublicKey
4271 algorithm and the working_public_key_algorithm are different, set
4272 the working_public_key_parameters to null.
4274 (f) Assign the certificate subjectPublicKey algorithm to the
4275 working_public_key_algorithm variable.
4277 (g) If a name constraints extension is included in the
4278 certificate, modify the permitted_subtrees and excluded_subtrees
4279 state variables as follows:
4281 (1) If permittedSubtrees is present in the certificate, set
4282 the permitted_subtrees state variable to the intersection of
4283 its previous value and the value indicated in the extension
4284 field. If permittedSubtrees does not include a particular name
4285 type, the permitted_subtrees state variable is unchanged for
4286 that name type. For example, the intersection of nist.gov and
4287 csrc.nist.gov is csrc.nist.gov. And, the intersection of
4288 nist.gov and rsasecurity.com is the empty set.
4290 (2) If excludedSubtrees is present in the certificate, set the
4291 excluded_subtrees state variable to the union of its previous
4292 value and the value indicated in the extension field. If
4293 excludedSubtrees does not include a particular name type, the
4294 excluded_subtrees state variable is unchanged for that name
4295 type. For example, the union of the name spaces nist.gov and
4296 csrc.nist.gov is nist.gov. And, the union of nist.gov and
4297 rsasecurity.com is both name spaces.
4299 (h) If the issuer and subject names are not identical:
4301 (1) If explicit_policy is not 0, decrement explicit_policy by
4304 (2) If policy_mapping is not 0, decrement policy_mapping by 1.
4306 (3) If inhibit_any-policy is not 0, decrement inhibit_any-
4314 Housley, et. al. Standards Track [Page 77]
4316 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
4319 (i) If a policy constraints extension is included in the
4320 certificate, modify the explicit_policy and policy_mapping state
4321 variables as follows:
4323 (1) If requireExplicitPolicy is present and is less than
4324 explicit_policy, set explicit_policy to the value of
4325 requireExplicitPolicy.
4327 (2) If inhibitPolicyMapping is present and is less than
4328 policy_mapping, set policy_mapping to the value of
4329 inhibitPolicyMapping.
4331 (j) If the inhibitAnyPolicy extension is included in the
4332 certificate and is less than inhibit_any-policy, set inhibit_any-
4333 policy to the value of inhibitAnyPolicy.
4335 (k) Verify that the certificate is a CA certificate (as specified
4336 in a basicConstraints extension or as verified out-of-band).
4338 (l) If the certificate was not self-issued, verify that
4339 max_path_length is greater than zero and decrement max_path_length
4342 (m) If pathLengthConstraint is present in the certificate and is
4343 less than max_path_length, set max_path_length to the value of
4344 pathLengthConstraint.
4346 (n) If a key usage extension is present, verify that the
4347 keyCertSign bit is set.
4349 (o) Recognize and process any other critical extension present in
4350 the certificate. Process any other recognized non-critical
4351 extension present in the certificate.
4353 If check (a), (k), (l), (n) or (o) fails, the procedure terminates,
4354 returning a failure indication and an appropriate reason.
4356 If (a), (k), (l), (n) and (o) have completed successfully, increment
4357 i and perform the basic certificate processing specified in 6.1.3.
4359 6.1.5 Wrap-up procedure
4361 To complete the processing of the end entity certificate, perform the
4362 following steps for certificate n:
4364 (a) If certificate n was not self-issued and explicit_policy is
4365 not 0, decrement explicit_policy by 1.
4370 Housley, et. al. Standards Track [Page 78]
4372 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
4375 (b) If a policy constraints extension is included in the
4376 certificate and requireExplicitPolicy is present and has a value
4377 of 0, set the explicit_policy state variable to 0.
4379 (c) Assign the certificate subjectPublicKey to
4382 (d) If the subjectPublicKeyInfo field of the certificate contains
4383 an algorithm field with non-null parameters, assign the parameters
4384 to the working_public_key_parameters variable.
4386 If the subjectPublicKeyInfo field of the certificate contains an
4387 algorithm field with null parameters or parameters are omitted,
4388 compare the certificate subjectPublicKey algorithm to the
4389 working_public_key_algorithm. If the certificate subjectPublicKey
4390 algorithm and the working_public_key_algorithm are different, set
4391 the working_public_key_parameters to null.
4393 (e) Assign the certificate subjectPublicKey algorithm to the
4394 working_public_key_algorithm variable.
4396 (f) Recognize and process any other critical extension present in
4397 the certificate n. Process any other recognized non-critical
4398 extension present in certificate n.
4400 (g) Calculate the intersection of the valid_policy_tree and the
4401 user-initial-policy-set, as follows:
4403 (i) If the valid_policy_tree is NULL, the intersection is
4406 (ii) If the valid_policy_tree is not NULL and the user-
4407 initial-policy-set is any-policy, the intersection is the
4408 entire valid_policy_tree.
4410 (iii) If the valid_policy_tree is not NULL and the user-
4411 initial-policy-set is not any-policy, calculate the
4412 intersection of the valid_policy_tree and the user-initial-
4413 policy-set as follows:
4415 1. Determine the set of policy nodes whose parent nodes
4416 have a valid_policy of anyPolicy. This is the
4417 valid_policy_node_set.
4419 2. If the valid_policy of any node in the
4420 valid_policy_node_set is not in the user-initial-policy-set
4421 and is not anyPolicy, delete this node and all its children.
4426 Housley, et. al. Standards Track [Page 79]
4428 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
4431 3. If the valid_policy_tree includes a node of depth n with
4432 the valid_policy anyPolicy and the user-initial-policy-set
4433 is not any-policy perform the following steps:
4435 a. Set P-Q to the qualifier_set in the node of depth n
4436 with valid_policy anyPolicy.
4438 b. For each P-OID in the user-initial-policy-set that is
4439 not the valid_policy of a node in the
4440 valid_policy_node_set, create a child node whose parent
4441 is the node of depth n-1 with the valid_policy anyPolicy.
4442 Set the values in the child node as follows: set the
4443 valid_policy to P-OID; set the qualifier_set to P-Q; copy
4444 the criticality_indicator from the node of depth n with
4445 the valid_policy anyPolicy; and set the
4446 expected_policy_set to {P-OID}.
4448 c. Delete the node of depth n with the valid_policy
4451 4. If there is a node in the valid_policy_tree of depth n-1
4452 or less without any child nodes, delete that node. Repeat
4453 this step until there are no nodes of depth n-1 or less
4456 If either (1) the value of explicit_policy variable is greater than
4457 zero, or (2) the valid_policy_tree is not NULL, then path processing
4462 If path processing succeeds, the procedure terminates, returning a
4463 success indication together with final value of the
4464 valid_policy_tree, the working_public_key, the
4465 working_public_key_algorithm, and the working_public_key_parameters.
4467 6.2 Using the Path Validation Algorithm
4469 The path validation algorithm describes the process of validating a
4470 single certification path. While each certification path begins with
4471 a specific trust anchor, there is no requirement that all
4472 certification paths validated by a particular system share a single
4473 trust anchor. An implementation that supports multiple trust anchors
4474 MAY augment the algorithm presented in section 6.1 to further limit
4475 the set of valid certification paths which begin with a particular
4476 trust anchor. For example, an implementation MAY modify the
4477 algorithm to apply name constraints to a specific trust anchor during
4478 the initialization phase, or the application MAY require the presence
4482 Housley, et. al. Standards Track [Page 80]
4484 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
4487 of a particular alternative name form in the end entity certificate,
4488 or the application MAY impose requirements on application-specific
4489 extensions. Thus, the path validation algorithm presented in section
4490 6.1 defines the minimum conditions for a path to be considered valid.
4492 The selection of one or more trusted CAs is a local decision. A
4493 system may provide any one of its trusted CAs as the trust anchor for
4494 a particular path. The inputs to the path validation algorithm may
4495 be different for each path. The inputs used to process a path may
4496 reflect application-specific requirements or limitations in the trust
4497 accorded a particular trust anchor. For example, a trusted CA may
4498 only be trusted for a particular certificate policy. This
4499 restriction can be expressed through the inputs to the path
4500 validation procedure.
4502 It is also possible to specify an extended version of the above
4503 certification path processing procedure which results in default
4504 behavior identical to the rules of PEM [RFC 1422]. In this extended
4505 version, additional inputs to the procedure are a list of one or more
4506 Policy Certification Authority (PCA) names and an indicator of the
4507 position in the certification path where the PCA is expected. At the
4508 nominated PCA position, the CA name is compared against this list.
4509 If a recognized PCA name is found, then a constraint of
4510 SubordinateToCA is implicitly assumed for the remainder of the
4511 certification path and processing continues. If no valid PCA name is
4512 found, and if the certification path cannot be validated on the basis
4513 of identified policies, then the certification path is considered
4518 This section describes the steps necessary to determine if a
4519 certificate is revoked or on hold status when CRLs are the revocation
4520 mechanism used by the certificate issuer. Conforming implementations
4521 that support CRLs are not required to implement this algorithm, but
4522 they MUST be functionally equivalent to the external behavior
4523 resulting from this procedure. Any algorithm may be used by a
4524 particular implementation so long as it derives the correct result.
4526 This algorithm assumes that all of the needed CRLs are available in a
4527 local cache. Further, if the next update time of a CRL has passed,
4528 the algorithm assumes a mechanism to fetch a current CRL and place it
4529 in the local CRL cache.
4531 This algorithm defines a set of inputs, a set of state variables, and
4532 processing steps that are performed for each certificate in the path.
4533 The algorithm output is the revocation status of the certificate.
4538 Housley, et. al. Standards Track [Page 81]
4540 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
4543 6.3.1 Revocation Inputs
4545 To support revocation processing, the algorithm requires two inputs:
4547 (a) certificate: The algorithm requires the certificate serial
4548 number and issuer name to determine whether a certificate is on a
4549 particular CRL. The basicConstraints extension is used to
4550 determine whether the supplied certificate is associated with a CA
4551 or an end entity. If present, the algorithm uses the
4552 cRLDistributionsPoint and freshestCRL extensions to determine
4555 (b) use-deltas: This boolean input determines whether delta CRLs
4556 are applied to CRLs.
4558 Note that implementations supporting legacy PKIs, such as RFC 1422
4559 and X.509 version 1, will need an additional input indicating
4560 whether the supplied certificate is associated with a CA or an end
4563 6.3.2 Initialization and Revocation State Variables
4565 To support CRL processing, the algorithm requires the following state
4568 (a) reasons_mask: This variable contains the set of revocation
4569 reasons supported by the CRLs and delta CRLs processed so far.
4570 The legal members of the set are the possible revocation reason
4571 values: unspecified, keyCompromise, caCompromise,
4572 affiliationChanged, superseded, cessationOfOperation,
4573 certificateHold, privilegeWithdrawn, and aACompromise. The
4574 special value all-reasons is used to denote the set of all legal
4575 members. This variable is initialized to the empty set.
4577 (b) cert_status: This variable contains the status of the
4578 certificate. This variable may be assigned one of the following
4579 values: unspecified, keyCompromise, caCompromise,
4580 affiliationChanged, superseded, cessationOfOperation,
4581 certificateHold, removeFromCRL, privilegeWithdrawn, aACompromise,
4582 the special value UNREVOKED, or the special value UNDETERMINED.
4583 This variable is initialized to the special value UNREVOKED.
4585 (c) interim_reasons_mask: This contains the set of revocation
4586 reasons supported by the CRL or delta CRL currently being
4594 Housley, et. al. Standards Track [Page 82]
4596 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
4599 Note: In some environments, it is not necessary to check all reason
4600 codes. For example, some environments are only concerned with
4601 caCompromise and keyCompromise for CA certificates. This algorithm
4602 checks all reason codes. Additional processing and state variables
4603 may be necessary to limit the checking to a subset of the reason
4606 6.3.3 CRL Processing
4608 This algorithm begins by assuming the certificate is not revoked.
4609 The algorithm checks one or more CRLs until either the certificate
4610 status is determined to be revoked or sufficient CRLs have been
4611 checked to cover all reason codes.
4613 For each distribution point (DP) in the certificate CRL distribution
4614 points extension, for each corresponding CRL in the local CRL cache,
4615 while ((reasons_mask is not all-reasons) and (cert_status is
4616 UNREVOKED)) perform the following:
4618 (a) Update the local CRL cache by obtaining a complete CRL, a
4619 delta CRL, or both, as required:
4621 (1) If the current time is after the value of the CRL next
4622 update field, then do one of the following:
4624 (i) If use-deltas is set and either the certificate or the
4625 CRL contains the freshest CRL extension, obtain a delta CRL
4626 with the a next update value that is after the current time
4627 and can be used to update the locally cached CRL as
4628 specified in section 5.2.4.
4630 (ii) Update the local CRL cache with a current complete
4631 CRL, verify that the current time is before the next update
4632 value in the new CRL, and continue processing with the new
4633 CRL. If use-deltas is set, then obtain the current delta
4634 CRL that can be used to update the new locally cached
4635 complete CRL as specified in section 5.2.4.
4637 (2) If the current time is before the value of the next update
4638 field and use-deltas is set, then obtain the current delta CRL
4639 that can be used to update the locally cached complete CRL as
4640 specified in section 5.2.4.
4642 (b) Verify the issuer and scope of the complete CRL as follows:
4650 Housley, et. al. Standards Track [Page 83]
4652 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
4655 (1) If the DP includes cRLIssuer, then verify that the issuer
4656 field in the complete CRL matches cRLIssuer in the DP and that
4657 the complete CRL contains an issuing distribution point
4658 extension with the indrectCRL boolean asserted. Otherwise,
4659 verify that the CRL issuer matches the certificate issuer.
4661 (2) If the complete CRL includes an issuing distribution point
4662 (IDP) CRL extension check the following:
4664 (i) If the distribution point name is present in the IDP
4665 CRL extension and the distribution field is present in the
4666 DP, then verify that one of the names in the IDP matches one
4667 of the names in the DP. If the distribution point name is
4668 present in the IDP CRL extension and the distribution field
4669 is omitted from the DP, then verify that one of the names in
4670 the IDP matches one of the names in the cRLIssuer field of
4673 (ii) If the onlyContainsUserCerts boolean is asserted in
4674 the IDP CRL extension, verify that the certificate does not
4675 include the basic constraints extension with the cA boolean
4678 (iii) If the onlyContainsCACerts boolean is asserted in the
4679 IDP CRL extension, verify that the certificate includes the
4680 basic constraints extension with the cA boolean asserted.
4682 (iv) Verify that the onlyContainsAttributeCerts boolean is
4685 (c) If use-deltas is set, verify the issuer and scope of the
4686 delta CRL as follows:
4688 (1) Verify that the delta CRL issuer matches complete CRL
4691 (2) If the complete CRL includes an issuing distribution point
4692 (IDP) CRL extension, verify that the delta CRL contains a
4693 matching IDP CRL extension. If the complete CRL omits an IDP
4694 CRL extension, verify that the delta CRL also omits an IDP CRL
4697 (3) Verify that the delta CRL authority key identifier
4698 extension matches complete CRL authority key identifier
4706 Housley, et. al. Standards Track [Page 84]
4708 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
4711 (d) Compute the interim_reasons_mask for this CRL as follows:
4713 (1) If the issuing distribution point (IDP) CRL extension is
4714 present and includes onlySomeReasons and the DP includes
4715 reasons, then set interim_reasons_mask to the intersection of
4716 reasons in the DP and onlySomeReasons in IDP CRL extension.
4718 (2) If the IDP CRL extension includes onlySomeReasons but the
4719 DP omits reasons, then set interim_reasons_mask to the value of
4720 onlySomeReasons in IDP CRL extension.
4722 (3) If the IDP CRL extension is not present or omits
4723 onlySomeReasons but the DP includes reasons, then set
4724 interim_reasons_mask to the value of DP reasons.
4726 (4) If the IDP CRL extension is not present or omits
4727 onlySomeReasons and the DP omits reasons, then set
4728 interim_reasons_mask to the special value all-reasons.
4730 (e) Verify that interim_reasons_mask includes one or more reasons
4731 that is not included in the reasons_mask.
4733 (f) Obtain and validate the certification path for the complete CRL
4734 issuer. If a key usage extension is present in the CRL issuer's
4735 certificate, verify that the cRLSign bit is set.
4737 (g) Validate the signature on the complete CRL using the public key
4738 validated in step (f).
4740 (h) If use-deltas is set, then validate the signature on the delta
4741 CRL using the public key validated in step (f).
4743 (i) If use-deltas is set, then search for the certificate on the
4744 delta CRL. If an entry is found that matches the certificate issuer
4745 and serial number as described in section 5.3.4, then set the
4746 cert_status variable to the indicated reason as follows:
4748 (1) If the reason code CRL entry extension is present, set the
4749 cert_status variable to the value of the reason code CRL entry
4752 (2) If the reason code CRL entry extension is not present, set
4753 the cert_status variable to the value unspecified.
4762 Housley, et. al. Standards Track [Page 85]
4764 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
4767 (j) If (cert_status is UNREVOKED), then search for the
4768 certificate on the complete CRL. If an entry is found that
4769 matches the certificate issuer and serial number as described in
4770 section 5.3.4, then set the cert_status variable to the indicated
4771 reason as described in step (i).
4773 (k) If (cert_status is removeFromCRL), then set cert_status to
4776 If ((reasons_mask is all-reasons) OR (cert_status is not UNREVOKED)),
4777 then the revocation status has been determined, so return
4780 If the revocation status has not been determined, repeat the process
4781 above with any available CRLs not specified in a distribution point
4782 but issued by the certificate issuer. For the processing of such a
4783 CRL, assume a DP with both the reasons and the cRLIssuer fields
4784 omitted and a distribution point name of the certificate issuer.
4785 That is, the sequence of names in fullName is generated from the
4786 certificate issuer field as well as the certificate issuerAltName
4787 extension. If the revocation status remains undetermined, then
4788 return the cert_status UNDETERMINED.
4792 [ISO 10646] ISO/IEC 10646-1:1993. International Standard --
4793 Information technology -- Universal Multiple-Octet Coded
4794 Character Set (UCS) -- Part 1: Architecture and Basic
4797 [RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791,
4800 [RFC 822] Crocker, D., "Standard for the format of ARPA Internet
4801 text messages", STD 11, RFC 822, August 1982.
4803 [RFC 1034] Mockapetris, P., "Domain Names - Concepts and
4804 Facilities", STD 13, RFC 1034, November 1987.
4806 [RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic
4807 Mail: Part II: Certificate-Based Key Management," RFC
4808 1422, February 1993.
4810 [RFC 1423] Balenson, D., "Privacy Enhancement for Internet
4811 Electronic Mail: Part III: Algorithms, Modes, and
4812 Identifiers," RFC 1423, February 1993.
4818 Housley, et. al. Standards Track [Page 86]
4820 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
4823 [RFC 1510] Kohl, J. and C. Neuman, "The Kerberos Network
4824 Authentication Service (V5)," RFC 1510, September 1993.
4826 [RFC 1519] Fuller, V., T. Li, J. Yu and K. Varadhan, "Classless
4827 Inter-Domain Routing (CIDR): An Address Assignment and
4828 Aggregation Strategy", RFC 1519, September 1993.
4830 [RFC 1738] Berners-Lee, T., L. Masinter and M. McCahill, "Uniform
4831 Resource Locators (URL)", RFC 1738, December 1994.
4833 [RFC 1778] Howes, T., S. Kille, W. Yeong and C. Robbins, "The String
4834 Representation of Standard Attribute Syntaxes," RFC 1778,
4837 [RFC 1883] Deering, S. and R. Hinden. "Internet Protocol, Version 6
4838 (IPv6) Specification", RFC 1883, December 1995.
4840 [RFC 2044] F. Yergeau, F., "UTF-8, a transformation format of
4841 Unicode and ISO 10646", RFC 2044, October 1996.
4843 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
4844 Requirement Levels", BCP 14, RFC 2119, March 1997.
4846 [RFC 2247] Kille, S., M. Wahl, A. Grimstad, R. Huber and S.
4847 Sataluri, "Using Domains in LDAP/X.500 Distinguished
4848 Names", RFC 2247, January 1998.
4850 [RFC 2252] Wahl, M., A. Coulbeck, T. Howes and S. Kille,
4851 "Lightweight Directory Access Protocol (v3): Attribute
4852 Syntax Definitions", RFC 2252, December 1997.
4854 [RFC 2277] Alvestrand, H., "IETF Policy on Character Sets and
4855 Languages", BCP 18, RFC 2277, January 1998.
4857 [RFC 2279] Yergeau, F., "UTF-8, a transformation format of ISO
4858 10646", RFC 2279, January 1998.
4860 [RFC 2459] Housley, R., W. Ford, W. Polk and D. Solo, "Internet
4861 X.509 Public Key Infrastructure: Certificate and CRL
4862 Profile", RFC 2459, January 1999.
4864 [RFC 2560] Myers, M., R. Ankney, A. Malpani, S. Galperin and C.
4865 Adams, "Online Certificate Status Protocal - OCSP", June
4868 [SDN.701] SDN.701, "Message Security Protocol 4.0", Revision A,
4874 Housley, et. al. Standards Track [Page 87]
4876 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
4879 [X.501] ITU-T Recommendation X.501: Information Technology - Open
4880 Systems Interconnection - The Directory: Models, 1993.
4882 [X.509] ITU-T Recommendation X.509 (1997 E): Information
4883 Technology - Open Systems Interconnection - The
4884 Directory: Authentication Framework, June 1997.
4886 [X.520] ITU-T Recommendation X.520: Information Technology - Open
4887 Systems Interconnection - The Directory: Selected
4888 Attribute Types, 1993.
4890 [X.660] ITU-T Recommendation X.660 Information Technology - ASN.1
4891 encoding rules: Specification of Basic Encoding Rules
4892 (BER), Canonical Encoding Rules (CER) and Distinguished
4893 Encoding Rules (DER), 1997.
4895 [X.690] ITU-T Recommendation X.690 Information Technology - Open
4896 Systems Interconnection - Procedures for the operation of
4897 OSI Registration Authorities: General procedures, 1992.
4899 [X9.55] ANSI X9.55-1995, Public Key Cryptography For The
4900 Financial Services Industry: Extensions To Public Key
4901 Certificates And Certificate Revocation Lists, 8
4904 [PKIXALGS] Bassham, L., Polk, W. and R. Housley, "Algorithms and
4905 Identifiers for the Internet X.509 Public Key
4906 Infrastructure Certificate and Certificate Revocation
4907 Lists (CRL) Profile", RFC 3279, April 2002.
4909 [PKIXTSA] Adams, C., Cain, P., Pinkas, D. and R. Zuccherato,
4910 "Internet X.509 Public Key Infrastructure Time-Stamp
4911 Protocol (TSP)", RFC 3161, August 2001.
4913 8 Intellectual Property Rights
4915 The IETF has been notified of intellectual property rights claimed in
4916 regard to some or all of the specification contained in this
4917 document. For more information consult the online list of claimed
4918 rights (see http://www.ietf.org/ipr.html).
4920 The IETF takes no position regarding the validity or scope of any
4921 intellectual property or other rights that might be claimed to
4922 pertain to the implementation or use of the technology described in
4923 this document or the extent to which any license under such rights
4924 might or might not be available; neither does it represent that it
4925 has made any effort to identify any such rights. Information on the
4926 IETF's procedures with respect to rights in standards-track and
4930 Housley, et. al. Standards Track [Page 88]
4932 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
4935 standards-related documentation can be found in BCP 11. Copies of
4936 claims of rights made available for publication and any assurances of
4937 licenses to be made available, or the result of an attempt made to
4938 obtain a general license or permission for the use of such
4939 proprietary rights by implementors or users of this specification can
4940 be obtained from the IETF Secretariat.
4942 9 Security Considerations
4944 The majority of this specification is devoted to the format and
4945 content of certificates and CRLs. Since certificates and CRLs are
4946 digitally signed, no additional integrity service is necessary.
4947 Neither certificates nor CRLs need be kept secret, and unrestricted
4948 and anonymous access to certificates and CRLs has no security
4951 However, security factors outside the scope of this specification
4952 will affect the assurance provided to certificate users. This
4953 section highlights critical issues to be considered by implementers,
4954 administrators, and users.
4956 The procedures performed by CAs and RAs to validate the binding of
4957 the subject's identity to their public key greatly affect the
4958 assurance that ought to be placed in the certificate. Relying
4959 parties might wish to review the CA's certificate practice statement.
4960 This is particularly important when issuing certificates to other
4963 The use of a single key pair for both signature and other purposes is
4964 strongly discouraged. Use of separate key pairs for signature and
4965 key management provides several benefits to the users. The
4966 ramifications associated with loss or disclosure of a signature key
4967 are different from loss or disclosure of a key management key. Using
4968 separate key pairs permits a balanced and flexible response.
4969 Similarly, different validity periods or key lengths for each key
4970 pair may be appropriate in some application environments.
4971 Unfortunately, some legacy applications (e.g., SSL) use a single key
4972 pair for signature and key management.
4974 The protection afforded private keys is a critical security factor.
4975 On a small scale, failure of users to protect their private keys will
4976 permit an attacker to masquerade as them, or decrypt their personal
4977 information. On a larger scale, compromise of a CA's private signing
4978 key may have a catastrophic effect. If an attacker obtains the
4979 private key unnoticed, the attacker may issue bogus certificates and
4980 CRLs. Existence of bogus certificates and CRLs will undermine
4981 confidence in the system. If such a compromise is detected, all
4982 certificates issued to the compromised CA MUST be revoked, preventing
4986 Housley, et. al. Standards Track [Page 89]
4988 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
4991 services between its users and users of other CAs. Rebuilding after
4992 such a compromise will be problematic, so CAs are advised to
4993 implement a combination of strong technical measures (e.g., tamper-
4994 resistant cryptographic modules) and appropriate management
4995 procedures (e.g., separation of duties) to avoid such an incident.
4997 Loss of a CA's private signing key may also be problematic. The CA
4998 would not be able to produce CRLs or perform normal key rollover.
4999 CAs SHOULD maintain secure backup for signing keys. The security of
5000 the key backup procedures is a critical factor in avoiding key
5003 The availability and freshness of revocation information affects the
5004 degree of assurance that ought to be placed in a certificate. While
5005 certificates expire naturally, events may occur during its natural
5006 lifetime which negate the binding between the subject and public key.
5007 If revocation information is untimely or unavailable, the assurance
5008 associated with the binding is clearly reduced. Relying parties
5009 might not be able to process every critical extension that can appear
5010 in a CRL. CAs SHOULD take extra care when making revocation
5011 information available only through CRLs that contain critical
5012 extensions, particularly if support for those extensions is not
5013 mandated by this profile. For example, if revocation information is
5014 supplied using a combination of delta CRLs and full CRLs, and the
5015 delta CRLs are issued more frequently than the full CRLs, then
5016 relying parties that cannot handle the critical extensions related to
5017 delta CRL processing will not be able to obtain the most recent
5018 revocation information. Alternatively, if a full CRL is issued
5019 whenever a delta CRL is issued, then timely revocation information
5020 will be available to all relying parties. Similarly, implementations
5021 of the certification path validation mechanism described in section 6
5022 that omit revocation checking provide less assurance than those that
5025 The certification path validation algorithm depends on the certain
5026 knowledge of the public keys (and other information) about one or
5027 more trusted CAs. The decision to trust a CA is an important
5028 decision as it ultimately determines the trust afforded a
5029 certificate. The authenticated distribution of trusted CA public
5030 keys (usually in the form of a "self-signed" certificate) is a
5031 security critical out-of-band process that is beyond the scope of
5034 In addition, where a key compromise or CA failure occurs for a
5035 trusted CA, the user will need to modify the information provided to
5036 the path validation routine. Selection of too many trusted CAs makes
5042 Housley, et. al. Standards Track [Page 90]
5044 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
5047 the trusted CA information difficult to maintain. On the other hand,
5048 selection of only one trusted CA could limit users to a closed
5051 The quality of implementations that process certificates also affects
5052 the degree of assurance provided. The path validation algorithm
5053 described in section 6 relies upon the integrity of the trusted CA
5054 information, and especially the integrity of the public keys
5055 associated with the trusted CAs. By substituting public keys for
5056 which an attacker has the private key, an attacker could trick the
5057 user into accepting false certificates.
5059 The binding between a key and certificate subject cannot be stronger
5060 than the cryptographic module implementation and algorithms used to
5061 generate the signature. Short key lengths or weak hash algorithms
5062 will limit the utility of a certificate. CAs are encouraged to note
5063 advances in cryptology so they can employ strong cryptographic
5064 techniques. In addition, CAs SHOULD decline to issue certificates to
5065 CAs or end entities that generate weak signatures.
5067 Inconsistent application of name comparison rules can result in
5068 acceptance of invalid X.509 certification paths, or rejection of
5069 valid ones. The X.500 series of specifications defines rules for
5070 comparing distinguished names that require comparison of strings
5071 without regard to case, character set, multi-character white space
5072 substring, or leading and trailing white space. This specification
5073 relaxes these requirements, requiring support for binary comparison
5076 CAs MUST encode the distinguished name in the subject field of a CA
5077 certificate identically to the distinguished name in the issuer field
5078 in certificates issued by that CA. If CAs use different encodings,
5079 implementations might fail to recognize name chains for paths that
5080 include this certificate. As a consequence, valid paths could be
5083 In addition, name constraints for distinguished names MUST be stated
5084 identically to the encoding used in the subject field or
5085 subjectAltName extension. If not, then name constraints stated as
5086 excludedSubTrees will not match and invalid paths will be accepted
5087 and name constraints expressed as permittedSubtrees will not match
5088 and valid paths will be rejected. To avoid acceptance of invalid
5089 paths, CAs SHOULD state name constraints for distinguished names as
5090 permittedSubtrees wherever possible.
5098 Housley, et. al. Standards Track [Page 91]
5100 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
5103 Appendix A. Psuedo-ASN.1 Structures and OIDs
5105 This section describes data objects used by conforming PKI components
5106 in an "ASN.1-like" syntax. This syntax is a hybrid of the 1988 and
5107 1993 ASN.1 syntaxes. The 1988 ASN.1 syntax is augmented with 1993
5108 UNIVERSAL Types UniversalString, BMPString and UTF8String.
5110 The ASN.1 syntax does not permit the inclusion of type statements in
5111 the ASN.1 module, and the 1993 ASN.1 standard does not permit use of
5112 the new UNIVERSAL types in modules using the 1988 syntax. As a
5113 result, this module does not conform to either version of the ASN.1
5116 This appendix may be converted into 1988 ASN.1 by replacing the
5117 definitions for the UNIVERSAL Types with the 1988 catch-all "ANY".
5119 A.1 Explicitly Tagged Module, 1988 Syntax
5121 PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1)
5122 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) }
5124 DEFINITIONS EXPLICIT TAGS ::=
5132 -- UNIVERSAL Types defined in 1993 and 1998 ASN.1
5133 -- and required by this specification
5135 UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING
5136 -- UniversalString is defined in ASN.1:1993
5138 BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING
5139 -- BMPString is the subtype of UniversalString and models
5140 -- the Basic Multilingual Plane of ISO/IEC/ITU 10646-1
5142 UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
5143 -- The content of this type conforms to RFC 2279.
5145 -- PKIX specific OIDs
5147 id-pkix OBJECT IDENTIFIER ::=
5148 { iso(1) identified-organization(3) dod(6) internet(1)
5149 security(5) mechanisms(5) pkix(7) }
5154 Housley, et. al. Standards Track [Page 92]
5156 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
5161 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
5162 -- arc for private certificate extensions
5163 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
5164 -- arc for policy qualifier types
5165 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
5166 -- arc for extended key purpose OIDS
5167 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
5168 -- arc for access descriptors
5170 -- policyQualifierIds for Internet policy qualifiers
5172 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 }
5173 -- OID for CPS qualifier
5174 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 }
5175 -- OID for user notice qualifier
5177 -- access descriptor definitions
5179 id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }
5180 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }
5181 id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 }
5182 id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 }
5184 -- attribute data types
5186 Attribute ::= SEQUENCE {
5188 values SET OF AttributeValue }
5189 -- at least one value is required
5191 AttributeType ::= OBJECT IDENTIFIER
5193 AttributeValue ::= ANY
5195 AttributeTypeAndValue ::= SEQUENCE {
5197 value AttributeValue }
5199 -- suggested naming attributes: Definition of the following
5200 -- information object set may be augmented to meet local
5201 -- requirements. Note that deleting members of the set may
5202 -- prevent interoperability with conforming implementations.
5203 -- presented in pairs: the AttributeType followed by the
5204 -- type definition for the corresponding AttributeValue
5205 --Arc for standard naming attributes
5206 id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 }
5210 Housley, et. al. Standards Track [Page 93]
5212 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
5215 -- Naming attributes of type X520name
5217 id-at-name AttributeType ::= { id-at 41 }
5218 id-at-surname AttributeType ::= { id-at 4 }
5219 id-at-givenName AttributeType ::= { id-at 42 }
5220 id-at-initials AttributeType ::= { id-at 43 }
5221 id-at-generationQualifier AttributeType ::= { id-at 44 }
5223 X520name ::= CHOICE {
5224 teletexString TeletexString (SIZE (1..ub-name)),
5225 printableString PrintableString (SIZE (1..ub-name)),
5226 universalString UniversalString (SIZE (1..ub-name)),
5227 utf8String UTF8String (SIZE (1..ub-name)),
5228 bmpString BMPString (SIZE (1..ub-name)) }
5230 -- Naming attributes of type X520CommonName
5232 id-at-commonName AttributeType ::= { id-at 3 }
5234 X520CommonName ::= CHOICE {
5235 teletexString TeletexString (SIZE (1..ub-common-name)),
5236 printableString PrintableString (SIZE (1..ub-common-name)),
5237 universalString UniversalString (SIZE (1..ub-common-name)),
5238 utf8String UTF8String (SIZE (1..ub-common-name)),
5239 bmpString BMPString (SIZE (1..ub-common-name)) }
5241 -- Naming attributes of type X520LocalityName
5243 id-at-localityName AttributeType ::= { id-at 7 }
5245 X520LocalityName ::= CHOICE {
5246 teletexString TeletexString (SIZE (1..ub-locality-name)),
5247 printableString PrintableString (SIZE (1..ub-locality-name)),
5248 universalString UniversalString (SIZE (1..ub-locality-name)),
5249 utf8String UTF8String (SIZE (1..ub-locality-name)),
5250 bmpString BMPString (SIZE (1..ub-locality-name)) }
5252 -- Naming attributes of type X520StateOrProvinceName
5254 id-at-stateOrProvinceName AttributeType ::= { id-at 8 }
5256 X520StateOrProvinceName ::= CHOICE {
5257 teletexString TeletexString (SIZE (1..ub-state-name)),
5258 printableString PrintableString (SIZE (1..ub-state-name)),
5259 universalString UniversalString (SIZE (1..ub-state-name)),
5260 utf8String UTF8String (SIZE (1..ub-state-name)),
5261 bmpString BMPString (SIZE(1..ub-state-name)) }
5266 Housley, et. al. Standards Track [Page 94]
5268 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
5271 -- Naming attributes of type X520OrganizationName
5273 id-at-organizationName AttributeType ::= { id-at 10 }
5275 X520OrganizationName ::= CHOICE {
5276 teletexString TeletexString
5277 (SIZE (1..ub-organization-name)),
5278 printableString PrintableString
5279 (SIZE (1..ub-organization-name)),
5280 universalString UniversalString
5281 (SIZE (1..ub-organization-name)),
5282 utf8String UTF8String
5283 (SIZE (1..ub-organization-name)),
5285 (SIZE (1..ub-organization-name)) }
5287 -- Naming attributes of type X520OrganizationalUnitName
5289 id-at-organizationalUnitName AttributeType ::= { id-at 11 }
5291 X520OrganizationalUnitName ::= CHOICE {
5292 teletexString TeletexString
5293 (SIZE (1..ub-organizational-unit-name)),
5294 printableString PrintableString
5295 (SIZE (1..ub-organizational-unit-name)),
5296 universalString UniversalString
5297 (SIZE (1..ub-organizational-unit-name)),
5298 utf8String UTF8String
5299 (SIZE (1..ub-organizational-unit-name)),
5301 (SIZE (1..ub-organizational-unit-name)) }
5303 -- Naming attributes of type X520Title
5305 id-at-title AttributeType ::= { id-at 12 }
5307 X520Title ::= CHOICE {
5308 teletexString TeletexString (SIZE (1..ub-title)),
5309 printableString PrintableString (SIZE (1..ub-title)),
5310 universalString UniversalString (SIZE (1..ub-title)),
5311 utf8String UTF8String (SIZE (1..ub-title)),
5312 bmpString BMPString (SIZE (1..ub-title)) }
5314 -- Naming attributes of type X520dnQualifier
5316 id-at-dnQualifier AttributeType ::= { id-at 46 }
5318 X520dnQualifier ::= PrintableString
5322 Housley, et. al. Standards Track [Page 95]
5324 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
5327 -- Naming attributes of type X520countryName (digraph from IS 3166)
5329 id-at-countryName AttributeType ::= { id-at 6 }
5331 X520countryName ::= PrintableString (SIZE (2))
5333 -- Naming attributes of type X520SerialNumber
5335 id-at-serialNumber AttributeType ::= { id-at 5 }
5337 X520SerialNumber ::= PrintableString (SIZE (1..ub-serial-number))
5339 -- Naming attributes of type X520Pseudonym
5341 id-at-pseudonym AttributeType ::= { id-at 65 }
5343 X520Pseudonym ::= CHOICE {
5344 teletexString TeletexString (SIZE (1..ub-pseudonym)),
5345 printableString PrintableString (SIZE (1..ub-pseudonym)),
5346 universalString UniversalString (SIZE (1..ub-pseudonym)),
5347 utf8String UTF8String (SIZE (1..ub-pseudonym)),
5348 bmpString BMPString (SIZE (1..ub-pseudonym)) }
5350 -- Naming attributes of type DomainComponent (from RFC 2247)
5352 id-domainComponent AttributeType ::=
5353 { 0 9 2342 19200300 100 1 25 }
5355 DomainComponent ::= IA5String
5357 -- Legacy attributes
5359 pkcs-9 OBJECT IDENTIFIER ::=
5360 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 }
5362 id-emailAddress AttributeType ::= { pkcs-9 1 }
5364 EmailAddress ::= IA5String (SIZE (1..ub-emailaddress-length))
5366 -- naming data types --
5368 Name ::= CHOICE { -- only one possibility for now --
5369 rdnSequence RDNSequence }
5371 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
5373 DistinguishedName ::= RDNSequence
5378 Housley, et. al. Standards Track [Page 96]
5380 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
5383 RelativeDistinguishedName ::=
5384 SET SIZE (1 .. MAX) OF AttributeTypeAndValue
5386 -- Directory string type --
5388 DirectoryString ::= CHOICE {
5389 teletexString TeletexString (SIZE (1..MAX)),
5390 printableString PrintableString (SIZE (1..MAX)),
5391 universalString UniversalString (SIZE (1..MAX)),
5392 utf8String UTF8String (SIZE (1..MAX)),
5393 bmpString BMPString (SIZE (1..MAX)) }
5395 -- certificate and CRL specific structures begin here
5397 Certificate ::= SEQUENCE {
5398 tbsCertificate TBSCertificate,
5399 signatureAlgorithm AlgorithmIdentifier,
5400 signature BIT STRING }
5402 TBSCertificate ::= SEQUENCE {
5403 version [0] Version DEFAULT v1,
5404 serialNumber CertificateSerialNumber,
5405 signature AlgorithmIdentifier,
5409 subjectPublicKeyInfo SubjectPublicKeyInfo,
5410 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
5411 -- If present, version MUST be v2 or v3
5412 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
5413 -- If present, version MUST be v2 or v3
5414 extensions [3] Extensions OPTIONAL
5415 -- If present, version MUST be v3 -- }
5417 Version ::= INTEGER { v1(0), v2(1), v3(2) }
5419 CertificateSerialNumber ::= INTEGER
5421 Validity ::= SEQUENCE {
5427 generalTime GeneralizedTime }
5429 UniqueIdentifier ::= BIT STRING
5434 Housley, et. al. Standards Track [Page 97]
5436 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
5439 SubjectPublicKeyInfo ::= SEQUENCE {
5440 algorithm AlgorithmIdentifier,
5441 subjectPublicKey BIT STRING }
5443 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
5445 Extension ::= SEQUENCE {
5446 extnID OBJECT IDENTIFIER,
5447 critical BOOLEAN DEFAULT FALSE,
5448 extnValue OCTET STRING }
5452 CertificateList ::= SEQUENCE {
5453 tbsCertList TBSCertList,
5454 signatureAlgorithm AlgorithmIdentifier,
5455 signature BIT STRING }
5457 TBSCertList ::= SEQUENCE {
5458 version Version OPTIONAL,
5459 -- if present, MUST be v2
5460 signature AlgorithmIdentifier,
5463 nextUpdate Time OPTIONAL,
5464 revokedCertificates SEQUENCE OF SEQUENCE {
5465 userCertificate CertificateSerialNumber,
5466 revocationDate Time,
5467 crlEntryExtensions Extensions OPTIONAL
5468 -- if present, MUST be v2
5470 crlExtensions [0] Extensions OPTIONAL }
5471 -- if present, MUST be v2
5473 -- Version, Time, CertificateSerialNumber, and Extensions were
5474 -- defined earlier for use in the certificate structure
5476 AlgorithmIdentifier ::= SEQUENCE {
5477 algorithm OBJECT IDENTIFIER,
5478 parameters ANY DEFINED BY algorithm OPTIONAL }
5479 -- contains a value of the type
5480 -- registered for use with the
5481 -- algorithm object identifier value
5483 -- X.400 address syntax starts here
5490 Housley, et. al. Standards Track [Page 98]
5492 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
5495 ORAddress ::= SEQUENCE {
5496 built-in-standard-attributes BuiltInStandardAttributes,
5497 built-in-domain-defined-attributes
5498 BuiltInDomainDefinedAttributes OPTIONAL,
5499 -- see also teletex-domain-defined-attributes
5500 extension-attributes ExtensionAttributes OPTIONAL }
5502 -- Built-in Standard Attributes
5504 BuiltInStandardAttributes ::= SEQUENCE {
5505 country-name CountryName OPTIONAL,
5506 administration-domain-name AdministrationDomainName OPTIONAL,
5507 network-address [0] IMPLICIT NetworkAddress OPTIONAL,
5508 -- see also extended-network-address
5509 terminal-identifier [1] IMPLICIT TerminalIdentifier OPTIONAL,
5510 private-domain-name [2] PrivateDomainName OPTIONAL,
5511 organization-name [3] IMPLICIT OrganizationName OPTIONAL,
5512 -- see also teletex-organization-name
5513 numeric-user-identifier [4] IMPLICIT NumericUserIdentifier
5515 personal-name [5] IMPLICIT PersonalName OPTIONAL,
5516 -- see also teletex-personal-name
5517 organizational-unit-names [6] IMPLICIT OrganizationalUnitNames
5519 -- see also teletex-organizational-unit-names
5521 CountryName ::= [APPLICATION 1] CHOICE {
5522 x121-dcc-code NumericString
5523 (SIZE (ub-country-name-numeric-length)),
5524 iso-3166-alpha2-code PrintableString
5525 (SIZE (ub-country-name-alpha-length)) }
5527 AdministrationDomainName ::= [APPLICATION 2] CHOICE {
5528 numeric NumericString (SIZE (0..ub-domain-name-length)),
5529 printable PrintableString (SIZE (0..ub-domain-name-length)) }
5531 NetworkAddress ::= X121Address -- see also extended-network-address
5533 X121Address ::= NumericString (SIZE (1..ub-x121-address-length))
5535 TerminalIdentifier ::= PrintableString (SIZE
5536 (1..ub-terminal-id-length))
5538 PrivateDomainName ::= CHOICE {
5539 numeric NumericString (SIZE (1..ub-domain-name-length)),
5540 printable PrintableString (SIZE (1..ub-domain-name-length)) }
5546 Housley, et. al. Standards Track [Page 99]
5548 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
5551 OrganizationName ::= PrintableString
5552 (SIZE (1..ub-organization-name-length))
5553 -- see also teletex-organization-name
5555 NumericUserIdentifier ::= NumericString
5556 (SIZE (1..ub-numeric-user-id-length))
5558 PersonalName ::= SET {
5559 surname [0] IMPLICIT PrintableString
5560 (SIZE (1..ub-surname-length)),
5561 given-name [1] IMPLICIT PrintableString
5562 (SIZE (1..ub-given-name-length)) OPTIONAL,
5563 initials [2] IMPLICIT PrintableString
5564 (SIZE (1..ub-initials-length)) OPTIONAL,
5565 generation-qualifier [3] IMPLICIT PrintableString
5566 (SIZE (1..ub-generation-qualifier-length))
5568 -- see also teletex-personal-name
5570 OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units)
5571 OF OrganizationalUnitName
5572 -- see also teletex-organizational-unit-names
5574 OrganizationalUnitName ::= PrintableString (SIZE
5575 (1..ub-organizational-unit-name-length))
5577 -- Built-in Domain-defined Attributes
5579 BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE
5580 (1..ub-domain-defined-attributes) OF
5581 BuiltInDomainDefinedAttribute
5583 BuiltInDomainDefinedAttribute ::= SEQUENCE {
5584 type PrintableString (SIZE
5585 (1..ub-domain-defined-attribute-type-length)),
5586 value PrintableString (SIZE
5587 (1..ub-domain-defined-attribute-value-length)) }
5589 -- Extension Attributes
5591 ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) OF
5594 ExtensionAttribute ::= SEQUENCE {
5595 extension-attribute-type [0] IMPLICIT INTEGER
5596 (0..ub-extension-attributes),
5597 extension-attribute-value [1]
5598 ANY DEFINED BY extension-attribute-type }
5602 Housley, et. al. Standards Track [Page 100]
5604 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
5607 -- Extension types and attribute values
5609 common-name INTEGER ::= 1
5611 CommonName ::= PrintableString (SIZE (1..ub-common-name-length))
5613 teletex-common-name INTEGER ::= 2
5615 TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length))
5617 teletex-organization-name INTEGER ::= 3
5619 TeletexOrganizationName ::=
5620 TeletexString (SIZE (1..ub-organization-name-length))
5622 teletex-personal-name INTEGER ::= 4
5624 TeletexPersonalName ::= SET {
5625 surname [0] IMPLICIT TeletexString
5626 (SIZE (1..ub-surname-length)),
5627 given-name [1] IMPLICIT TeletexString
5628 (SIZE (1..ub-given-name-length)) OPTIONAL,
5629 initials [2] IMPLICIT TeletexString
5630 (SIZE (1..ub-initials-length)) OPTIONAL,
5631 generation-qualifier [3] IMPLICIT TeletexString
5632 (SIZE (1..ub-generation-qualifier-length))
5635 teletex-organizational-unit-names INTEGER ::= 5
5637 TeletexOrganizationalUnitNames ::= SEQUENCE SIZE
5638 (1..ub-organizational-units) OF TeletexOrganizationalUnitName
5640 TeletexOrganizationalUnitName ::= TeletexString
5641 (SIZE (1..ub-organizational-unit-name-length))
5643 pds-name INTEGER ::= 7
5645 PDSName ::= PrintableString (SIZE (1..ub-pds-name-length))
5647 physical-delivery-country-name INTEGER ::= 8
5649 PhysicalDeliveryCountryName ::= CHOICE {
5650 x121-dcc-code NumericString (SIZE
5651 (ub-country-name-numeric-length)),
5652 iso-3166-alpha2-code PrintableString
5653 (SIZE (ub-country-name-alpha-length)) }
5658 Housley, et. al. Standards Track [Page 101]
5660 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
5663 postal-code INTEGER ::= 9
5665 PostalCode ::= CHOICE {
5666 numeric-code NumericString (SIZE (1..ub-postal-code-length)),
5667 printable-code PrintableString (SIZE (1..ub-postal-code-length)) }
5669 physical-delivery-office-name INTEGER ::= 10
5671 PhysicalDeliveryOfficeName ::= PDSParameter
5673 physical-delivery-office-number INTEGER ::= 11
5675 PhysicalDeliveryOfficeNumber ::= PDSParameter
5677 extension-OR-address-components INTEGER ::= 12
5679 ExtensionORAddressComponents ::= PDSParameter
5681 physical-delivery-personal-name INTEGER ::= 13
5683 PhysicalDeliveryPersonalName ::= PDSParameter
5685 physical-delivery-organization-name INTEGER ::= 14
5687 PhysicalDeliveryOrganizationName ::= PDSParameter
5689 extension-physical-delivery-address-components INTEGER ::= 15
5691 ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter
5693 unformatted-postal-address INTEGER ::= 16
5695 UnformattedPostalAddress ::= SET {
5696 printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines)
5697 OF PrintableString (SIZE (1..ub-pds-parameter-length))
5699 teletex-string TeletexString
5700 (SIZE (1..ub-unformatted-address-length)) OPTIONAL }
5702 street-address INTEGER ::= 17
5704 StreetAddress ::= PDSParameter
5706 post-office-box-address INTEGER ::= 18
5708 PostOfficeBoxAddress ::= PDSParameter
5710 poste-restante-address INTEGER ::= 19
5714 Housley, et. al. Standards Track [Page 102]
5716 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
5719 PosteRestanteAddress ::= PDSParameter
5721 unique-postal-name INTEGER ::= 20
5723 UniquePostalName ::= PDSParameter
5725 local-postal-attributes INTEGER ::= 21
5727 LocalPostalAttributes ::= PDSParameter
5729 PDSParameter ::= SET {
5730 printable-string PrintableString
5731 (SIZE(1..ub-pds-parameter-length)) OPTIONAL,
5732 teletex-string TeletexString
5733 (SIZE(1..ub-pds-parameter-length)) OPTIONAL }
5735 extended-network-address INTEGER ::= 22
5737 ExtendedNetworkAddress ::= CHOICE {
5738 e163-4-address SEQUENCE {
5739 number [0] IMPLICIT NumericString
5740 (SIZE (1..ub-e163-4-number-length)),
5741 sub-address [1] IMPLICIT NumericString
5742 (SIZE (1..ub-e163-4-sub-address-length))
5744 psap-address [0] IMPLICIT PresentationAddress }
5746 PresentationAddress ::= SEQUENCE {
5747 pSelector [0] EXPLICIT OCTET STRING OPTIONAL,
5748 sSelector [1] EXPLICIT OCTET STRING OPTIONAL,
5749 tSelector [2] EXPLICIT OCTET STRING OPTIONAL,
5750 nAddresses [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING }
5752 terminal-type INTEGER ::= 23
5754 TerminalType ::= INTEGER {
5760 videotex (8) } (0..ub-integer-options)
5762 -- Extension Domain-defined Attributes
5764 teletex-domain-defined-attributes INTEGER ::= 6
5770 Housley, et. al. Standards Track [Page 103]
5772 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
5775 TeletexDomainDefinedAttributes ::= SEQUENCE SIZE
5776 (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute
5778 TeletexDomainDefinedAttribute ::= SEQUENCE {
5780 (SIZE (1..ub-domain-defined-attribute-type-length)),
5782 (SIZE (1..ub-domain-defined-attribute-value-length)) }
5784 -- specifications of Upper Bounds MUST be regarded as mandatory
5785 -- from Annex B of ITU-T X.411 Reference Definition of MTS Parameter
5789 ub-name INTEGER ::= 32768
5790 ub-common-name INTEGER ::= 64
5791 ub-locality-name INTEGER ::= 128
5792 ub-state-name INTEGER ::= 128
5793 ub-organization-name INTEGER ::= 64
5794 ub-organizational-unit-name INTEGER ::= 64
5795 ub-title INTEGER ::= 64
5796 ub-serial-number INTEGER ::= 64
5797 ub-match INTEGER ::= 128
5798 ub-emailaddress-length INTEGER ::= 128
5799 ub-common-name-length INTEGER ::= 64
5800 ub-country-name-alpha-length INTEGER ::= 2
5801 ub-country-name-numeric-length INTEGER ::= 3
5802 ub-domain-defined-attributes INTEGER ::= 4
5803 ub-domain-defined-attribute-type-length INTEGER ::= 8
5804 ub-domain-defined-attribute-value-length INTEGER ::= 128
5805 ub-domain-name-length INTEGER ::= 16
5806 ub-extension-attributes INTEGER ::= 256
5807 ub-e163-4-number-length INTEGER ::= 15
5808 ub-e163-4-sub-address-length INTEGER ::= 40
5809 ub-generation-qualifier-length INTEGER ::= 3
5810 ub-given-name-length INTEGER ::= 16
5811 ub-initials-length INTEGER ::= 5
5812 ub-integer-options INTEGER ::= 256
5813 ub-numeric-user-id-length INTEGER ::= 32
5814 ub-organization-name-length INTEGER ::= 64
5815 ub-organizational-unit-name-length INTEGER ::= 32
5816 ub-organizational-units INTEGER ::= 4
5817 ub-pds-name-length INTEGER ::= 16
5818 ub-pds-parameter-length INTEGER ::= 30
5819 ub-pds-physical-address-lines INTEGER ::= 6
5820 ub-postal-code-length INTEGER ::= 16
5821 ub-pseudonym INTEGER ::= 128
5822 ub-surname-length INTEGER ::= 40
5826 Housley, et. al. Standards Track [Page 104]
5828 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
5831 ub-terminal-id-length INTEGER ::= 24
5832 ub-unformatted-address-length INTEGER ::= 180
5833 ub-x121-address-length INTEGER ::= 16
5835 -- Note - upper bounds on string types, such as TeletexString, are
5836 -- measured in characters. Excepting PrintableString or IA5String, a
5837 -- significantly greater number of octets will be required to hold
5838 -- such a value. As a minimum, 16 octets, or twice the specified
5839 -- upper bound, whichever is the larger, should be allowed for
5840 -- TeletexString. For UTF8String or UniversalString at least four
5841 -- times the upper bound should be allowed.
5845 A.2 Implicitly Tagged Module, 1988 Syntax
5847 PKIX1Implicit88 { iso(1) identified-organization(3) dod(6) internet(1)
5848 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19) }
5850 DEFINITIONS IMPLICIT TAGS ::=
5857 id-pe, id-kp, id-qt-unotice, id-qt-cps,
5858 -- delete following line if "new" types are supported --
5859 BMPString, UTF8String, -- end "new" types --
5860 ORAddress, Name, RelativeDistinguishedName,
5861 CertificateSerialNumber, Attribute, DirectoryString
5862 FROM PKIX1Explicit88 { iso(1) identified-organization(3)
5863 dod(6) internet(1) security(5) mechanisms(5) pkix(7)
5864 id-mod(0) id-pkix1-explicit(18) };
5867 -- ISO arc for standard certificate and CRL extensions
5869 id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29}
5871 -- authority key identifier OID and syntax
5873 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 }
5882 Housley, et. al. Standards Track [Page 105]
5884 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
5887 AuthorityKeyIdentifier ::= SEQUENCE {
5888 keyIdentifier [0] KeyIdentifier OPTIONAL,
5889 authorityCertIssuer [1] GeneralNames OPTIONAL,
5890 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }
5891 -- authorityCertIssuer and authorityCertSerialNumber MUST both
5892 -- be present or both be absent
5894 KeyIdentifier ::= OCTET STRING
5896 -- subject key identifier OID and syntax
5898 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 }
5900 SubjectKeyIdentifier ::= KeyIdentifier
5902 -- key usage extension OID and syntax
5904 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 }
5906 KeyUsage ::= BIT STRING {
5907 digitalSignature (0),
5909 keyEncipherment (2),
5910 dataEncipherment (3),
5917 -- private key usage period extension OID and syntax
5919 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 }
5921 PrivateKeyUsagePeriod ::= SEQUENCE {
5922 notBefore [0] GeneralizedTime OPTIONAL,
5923 notAfter [1] GeneralizedTime OPTIONAL }
5924 -- either notBefore or notAfter MUST be present
5926 -- certificate policies extension OID and syntax
5928 id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 }
5930 anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificatePolicies 0 }
5932 CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
5934 PolicyInformation ::= SEQUENCE {
5938 Housley, et. al. Standards Track [Page 106]
5940 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
5943 policyIdentifier CertPolicyId,
5944 policyQualifiers SEQUENCE SIZE (1..MAX) OF
5945 PolicyQualifierInfo OPTIONAL }
5947 CertPolicyId ::= OBJECT IDENTIFIER
5949 PolicyQualifierInfo ::= SEQUENCE {
5950 policyQualifierId PolicyQualifierId,
5951 qualifier ANY DEFINED BY policyQualifierId }
5953 -- Implementations that recognize additional policy qualifiers MUST
5954 -- augment the following definition for PolicyQualifierId
5956 PolicyQualifierId ::=
5957 OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )
5959 -- CPS pointer qualifier
5961 CPSuri ::= IA5String
5963 -- user notice qualifier
5965 UserNotice ::= SEQUENCE {
5966 noticeRef NoticeReference OPTIONAL,
5967 explicitText DisplayText OPTIONAL}
5969 NoticeReference ::= SEQUENCE {
5970 organization DisplayText,
5971 noticeNumbers SEQUENCE OF INTEGER }
5973 DisplayText ::= CHOICE {
5974 ia5String IA5String (SIZE (1..200)),
5975 visibleString VisibleString (SIZE (1..200)),
5976 bmpString BMPString (SIZE (1..200)),
5977 utf8String UTF8String (SIZE (1..200)) }
5979 -- policy mapping extension OID and syntax
5981 id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 }
5983 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
5984 issuerDomainPolicy CertPolicyId,
5985 subjectDomainPolicy CertPolicyId }
5987 -- subject alternative name extension OID and syntax
5989 id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 }
5994 Housley, et. al. Standards Track [Page 107]
5996 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
5999 SubjectAltName ::= GeneralNames
6001 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
6003 GeneralName ::= CHOICE {
6004 otherName [0] AnotherName,
6005 rfc822Name [1] IA5String,
6006 dNSName [2] IA5String,
6007 x400Address [3] ORAddress,
6008 directoryName [4] Name,
6009 ediPartyName [5] EDIPartyName,
6010 uniformResourceIdentifier [6] IA5String,
6011 iPAddress [7] OCTET STRING,
6012 registeredID [8] OBJECT IDENTIFIER }
6014 -- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as
6015 -- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax
6017 AnotherName ::= SEQUENCE {
6018 type-id OBJECT IDENTIFIER,
6019 value [0] EXPLICIT ANY DEFINED BY type-id }
6021 EDIPartyName ::= SEQUENCE {
6022 nameAssigner [0] DirectoryString OPTIONAL,
6023 partyName [1] DirectoryString }
6025 -- issuer alternative name extension OID and syntax
6027 id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 }
6029 IssuerAltName ::= GeneralNames
6031 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 }
6033 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute
6035 -- basic constraints extension OID and syntax
6037 id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 }
6039 BasicConstraints ::= SEQUENCE {
6040 cA BOOLEAN DEFAULT FALSE,
6041 pathLenConstraint INTEGER (0..MAX) OPTIONAL }
6043 -- name constraints extension OID and syntax
6045 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 }
6050 Housley, et. al. Standards Track [Page 108]
6052 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
6055 NameConstraints ::= SEQUENCE {
6056 permittedSubtrees [0] GeneralSubtrees OPTIONAL,
6057 excludedSubtrees [1] GeneralSubtrees OPTIONAL }
6059 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
6061 GeneralSubtree ::= SEQUENCE {
6063 minimum [0] BaseDistance DEFAULT 0,
6064 maximum [1] BaseDistance OPTIONAL }
6066 BaseDistance ::= INTEGER (0..MAX)
6068 -- policy constraints extension OID and syntax
6070 id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 }
6072 PolicyConstraints ::= SEQUENCE {
6073 requireExplicitPolicy [0] SkipCerts OPTIONAL,
6074 inhibitPolicyMapping [1] SkipCerts OPTIONAL }
6076 SkipCerts ::= INTEGER (0..MAX)
6078 -- CRL distribution points extension OID and syntax
6080 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31}
6082 CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
6084 DistributionPoint ::= SEQUENCE {
6085 distributionPoint [0] DistributionPointName OPTIONAL,
6086 reasons [1] ReasonFlags OPTIONAL,
6087 cRLIssuer [2] GeneralNames OPTIONAL }
6089 DistributionPointName ::= CHOICE {
6090 fullName [0] GeneralNames,
6091 nameRelativeToCRLIssuer [1] RelativeDistinguishedName }
6093 ReasonFlags ::= BIT STRING {
6097 affiliationChanged (3),
6099 cessationOfOperation (5),
6100 certificateHold (6),
6101 privilegeWithdrawn (7),
6106 Housley, et. al. Standards Track [Page 109]
6108 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
6111 -- extended key usage extension OID and syntax
6113 id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37}
6115 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
6118 KeyPurposeId ::= OBJECT IDENTIFIER
6120 -- permit unspecified key uses
6122 anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 }
6124 -- extended key purpose OIDs
6126 id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
6127 id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 }
6128 id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 }
6129 id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 }
6130 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }
6131 id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }
6133 -- inhibit any policy OID and syntax
6135 id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 }
6137 InhibitAnyPolicy ::= SkipCerts
6139 -- freshest (delta)CRL extension OID and syntax
6141 id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 }
6143 FreshestCRL ::= CRLDistributionPoints
6145 -- authority info access
6147 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }
6149 AuthorityInfoAccessSyntax ::=
6150 SEQUENCE SIZE (1..MAX) OF AccessDescription
6152 AccessDescription ::= SEQUENCE {
6153 accessMethod OBJECT IDENTIFIER,
6154 accessLocation GeneralName }
6156 -- subject info access
6158 id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 }
6162 Housley, et. al. Standards Track [Page 110]
6164 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
6167 SubjectInfoAccessSyntax ::=
6168 SEQUENCE SIZE (1..MAX) OF AccessDescription
6170 -- CRL number extension OID and syntax
6172 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }
6174 CRLNumber ::= INTEGER (0..MAX)
6176 -- issuing distribution point extension OID and syntax
6178 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 }
6180 IssuingDistributionPoint ::= SEQUENCE {
6181 distributionPoint [0] DistributionPointName OPTIONAL,
6182 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE,
6183 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE,
6184 onlySomeReasons [3] ReasonFlags OPTIONAL,
6185 indirectCRL [4] BOOLEAN DEFAULT FALSE,
6186 onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
6188 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }
6190 BaseCRLNumber ::= CRLNumber
6192 -- CRL reasons extension OID and syntax
6194 id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 }
6196 CRLReason ::= ENUMERATED {
6200 affiliationChanged (3),
6202 cessationOfOperation (5),
6203 certificateHold (6),
6205 privilegeWithdrawn (9),
6208 -- certificate issuer CRL entry extension OID and syntax
6210 id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 }
6212 CertificateIssuer ::= GeneralNames
6214 -- hold instruction extension OID and syntax
6218 Housley, et. al. Standards Track [Page 111]
6220 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
6223 id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 }
6225 HoldInstructionCode ::= OBJECT IDENTIFIER
6227 -- ANSI x9 holdinstructions
6229 -- ANSI x9 arc holdinstruction arc
6231 holdInstruction OBJECT IDENTIFIER ::=
6232 {joint-iso-itu-t(2) member-body(2) us(840) x9cm(10040) 2}
6234 -- ANSI X9 holdinstructions referenced by this standard
6236 id-holdinstruction-none OBJECT IDENTIFIER ::=
6237 {holdInstruction 1} -- deprecated
6239 id-holdinstruction-callissuer OBJECT IDENTIFIER ::=
6242 id-holdinstruction-reject OBJECT IDENTIFIER ::=
6245 -- invalidity date CRL entry extension OID and syntax
6247 id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 }
6249 InvalidityDate ::= GeneralizedTime
6253 Appendix B. ASN.1 Notes
6255 CAs MUST force the serialNumber to be a non-negative integer, that
6256 is, the sign bit in the DER encoding of the INTEGER value MUST be
6257 zero - this can be done by adding a leading (leftmost) `00'H octet if
6258 necessary. This removes a potential ambiguity in mapping between a
6259 string of octets and an integer value.
6261 As noted in section 4.1.2.2, serial numbers can be expected to
6262 contain long integers. Certificate users MUST be able to handle
6263 serialNumber values up to 20 octets in length. Conformant CAs MUST
6264 NOT use serialNumber values longer than 20 octets.
6266 As noted in section 5.2.3, CRL numbers can be expected to contain
6267 long integers. CRL validators MUST be able to handle cRLNumber
6268 values up to 20 octets in length. Conformant CRL issuers MUST NOT
6269 use cRLNumber values longer than 20 octets.
6274 Housley, et. al. Standards Track [Page 112]
6276 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
6279 The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1
6280 constructs. A valid ASN.1 sequence will have zero or more entries.
6281 The SIZE (1..MAX) construct constrains the sequence to have at least
6282 one entry. MAX indicates the upper bound is unspecified.
6283 Implementations are free to choose an upper bound that suits their
6286 The construct "positiveInt ::= INTEGER (0..MAX)" defines positiveInt
6287 as a subtype of INTEGER containing integers greater than or equal to
6288 zero. The upper bound is unspecified. Implementations are free to
6289 select an upper bound that suits their environment.
6291 The character string type PrintableString supports a very basic Latin
6292 character set: the lower case letters 'a' through 'z', upper case
6293 letters 'A' through 'Z', the digits '0' through '9', eleven special
6294 characters ' = ( ) + , - . / : ? and space.
6296 Implementers should note that the at sign ('@') and underscore ('_')
6297 characters are not supported by the ASN.1 type PrintableString.
6298 These characters often appear in internet addresses. Such addresses
6299 MUST be encoded using an ASN.1 type that supports them. They are
6300 usually encoded as IA5String in either the emailAddress attribute
6301 within a distinguished name or the rfc822Name field of GeneralName.
6302 Conforming implementations MUST NOT encode strings which include
6303 either the at sign or underscore character as PrintableString.
6305 The character string type TeletexString is a superset of
6306 PrintableString. TeletexString supports a fairly standard (ASCII-
6307 like) Latin character set, Latin characters with non-spacing accents
6308 and Japanese characters.
6310 Named bit lists are BIT STRINGs where the values have been assigned
6311 names. This specification makes use of named bit lists in the
6312 definitions for the key usage, CRL distribution points and freshest
6313 CRL certificate extensions, as well as the freshest CRL and issuing
6314 distribution point CRL extensions. When DER encoding a named bit
6315 list, trailing zeroes MUST be omitted. That is, the encoded value
6316 ends with the last named bit that is set to one.
6318 The character string type UniversalString supports any of the
6319 characters allowed by ISO 10646-1 [ISO 10646]. ISO 10646-1 is the
6320 Universal multiple-octet coded Character Set (UCS). ISO 10646-1
6321 specifies the architecture and the "basic multilingual plane" -- a
6322 large standard character set which includes all major world character
6330 Housley, et. al. Standards Track [Page 113]
6332 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
6335 The character string type UTF8String was introduced in the 1997
6336 version of ASN.1, and UTF8String was added to the list of choices for
6337 DirectoryString in the 2001 version of X.520 [X.520]. UTF8String is
6338 a universal type and has been assigned tag number 12. The content of
6339 UTF8String was defined by RFC 2044 [RFC 2044] and updated in RFC 2279
6342 In anticipation of these changes, and in conformance with IETF Best
6343 Practices codified in RFC 2277 [RFC 2277], IETF Policy on Character
6344 Sets and Languages, this document includes UTF8String as a choice in
6345 DirectoryString and the CPS qualifier extensions.
6347 Implementers should note that the DER encoding of the SET OF values
6348 requires ordering of the encodings of the values. In particular,
6349 this issue arises with respect to distinguished names.
6351 Implementers should note that the DER encoding of SET or SEQUENCE
6352 components whose value is the DEFAULT omit the component from the
6353 encoded certificate or CRL. For example, a BasicConstraints
6354 extension whose cA value is FALSE would omit the cA boolean from the
6355 encoded certificate.
6357 Object Identifiers (OIDs) are used throughout this specification to
6358 identify certificate policies, public key and signature algorithms,
6359 certificate extensions, etc. There is no maximum size for OIDs.
6360 This specification mandates support for OIDs which have arc elements
6361 with values that are less than 2^28, that is, they MUST be between 0
6362 and 268,435,455, inclusive. This allows each arc element to be
6363 represented within a single 32 bit word. Implementations MUST also
6364 support OIDs where the length of the dotted decimal (see [RFC 2252],
6365 section 4.1) string representation can be up to 100 bytes
6366 (inclusive). Implementations MUST be able to handle OIDs with up to
6367 20 elements (inclusive). CAs SHOULD NOT issue certificates which
6368 contain OIDs that exceed these requirements. Likewise, CRL issuers
6369 SHOULD NOT issue CRLs which contain OIDs that exceed these
6372 Implementors are warned that the X.500 standards community has
6373 developed a series of extensibility rules. These rules determine
6374 when an ASN.1 definition can be changed without assigning a new
6375 object identifier (OID). For example, at least two extension
6376 definitions included in RFC 2459 [RFC 2459], the predecessor to this
6377 profile document, have different ASN.1 definitions in this
6378 specification, but the same OID is used. If unknown elements appear
6379 within an extension, and the extension is not marked critical, those
6380 unknown elements ought to be ignored, as follows:
6382 (a) ignore all unknown bit name assignments within a bit string;
6386 Housley, et. al. Standards Track [Page 114]
6388 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
6391 (b) ignore all unknown named numbers in an ENUMERATED type or
6392 INTEGER type that is being used in the enumerated style, provided
6393 the number occurs as an optional element of a SET or SEQUENCE; and
6395 (c) ignore all unknown elements in SETs, at the end of SEQUENCEs,
6396 or in CHOICEs where the CHOICE is itself an optional element of a
6399 If an extension containing unexpected values is marked critical, the
6400 implementation MUST reject the certificate or CRL containing the
6401 unrecognized extension.
6403 Appendix C. Examples
6405 This section contains four examples: three certificates and a CRL.
6406 The first two certificates and the CRL comprise a minimal
6409 Section C.1 contains an annotated hex dump of a "self-signed"
6410 certificate issued by a CA whose distinguished name is
6411 cn=us,o=gov,ou=nist. The certificate contains a DSA public key with
6412 parameters, and is signed by the corresponding DSA private key.
6414 Section C.2 contains an annotated hex dump of an end entity
6415 certificate. The end entity certificate contains a DSA public key,
6416 and is signed by the private key corresponding to the "self-signed"
6417 certificate in section C.1.
6419 Section C.3 contains a dump of an end entity certificate which
6420 contains an RSA public key and is signed with RSA and MD5. This
6421 certificate is not part of the minimal certification path.
6423 Section C.4 contains an annotated hex dump of a CRL. The CRL is
6424 issued by the CA whose distinguished name is cn=us,o=gov,ou=nist and
6425 the list of revoked certificates includes the end entity certificate
6428 The certificates were processed using Peter Gutman's dumpasn1 utility
6429 to generate the output. The source for the dumpasn1 utility is
6430 available at <http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c>. The
6431 binaries for the certificates and CRLs are available at
6432 <http://csrc.nist.gov/pki/pkixtools>.
6436 This section contains an annotated hex dump of a 699 byte version 3
6437 certificate. The certificate contains the following information:
6438 (a) the serial number is 23 (17 hex);
6442 Housley, et. al. Standards Track [Page 115]
6444 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
6447 (b) the certificate is signed with DSA and the SHA-1 hash algorithm;
6448 (c) the issuer's distinguished name is OU=NIST; O=gov; C=US
6449 (d) and the subject's distinguished name is OU=NIST; O=gov; C=US
6450 (e) the certificate was issued on June 30, 1997 and will expire on
6452 (f) the certificate contains a 1024 bit DSA public key with
6454 (g) the certificate contains a subject key identifier extension
6455 generated using method (1) of section 4.2.1.2; and
6456 (h) the certificate is a CA certificate (as indicated through the
6457 basic constraints extension.)
6459 0 30 699: SEQUENCE {
6460 4 30 635: SEQUENCE {
6466 18 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
6468 27 30 42: SEQUENCE {
6471 33 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
6472 38 13 2: PrintableString 'US'
6476 44 30 10: SEQUENCE {
6477 46 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
6478 51 13 3: PrintableString 'gov'
6482 58 30 11: SEQUENCE {
6483 60 06 3: OBJECT IDENTIFIER
6484 : organizationalUnitName (2 5 4 11)
6485 65 13 4: PrintableString 'NIST'
6489 71 30 30: SEQUENCE {
6490 73 17 13: UTCTime '970630000000Z'
6491 88 17 13: UTCTime '971231000000Z'
6493 103 30 42: SEQUENCE {
6498 Housley, et. al. Standards Track [Page 116]
6500 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
6503 107 30 9: SEQUENCE {
6504 109 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
6505 114 13 2: PrintableString 'US'
6509 120 30 10: SEQUENCE {
6510 122 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
6511 127 13 3: PrintableString 'gov'
6515 134 30 11: SEQUENCE {
6516 136 06 3: OBJECT IDENTIFIER
6517 : organizationalUnitName (2 5 4 11)
6518 141 13 4: PrintableString 'NIST'
6522 147 30 440: SEQUENCE {
6523 151 30 300: SEQUENCE {
6524 155 06 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1)
6525 164 30 287: SEQUENCE {
6527 : 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC
6528 : FB 95 32 AC 01 12 33 B9 E0 1C AD 90 9B BC
6529 : 48 54 9E F3 94 77 3C 2C 71 35 55 E6 FE 4F
6530 : 22 CB D5 D8 3E 89 93 33 4D FC BD 4F 41 64
6531 : 3E A2 98 70 EC 31 B4 50 DE EB F1 98 28 0A
6532 : C9 3E 44 B3 FD 22 97 96 83 D0 18 A3 E3 BD
6533 : 35 5B FF EE A3 21 72 6A 7B 96 DA B9 3F 1E
6534 : 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A
6535 : FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48
6538 : 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA
6539 : 55 F7 7D 57 74 81 E5
6541 : 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91
6542 : C0 8E 47 F1 0A C3 01 47 C2 44 42 36 A9 92
6543 : 81 DE 57 C5 E0 68 86 58 00 7B 1F F9 9B 77
6544 : A1 C5 10 A5 80 91 78 51 51 3C F6 FC FC CC
6545 : 46 C6 81 78 92 84 3D F4 93 3D 0C 38 7E 1A
6546 : 5B 99 4E AB 14 64 F6 0C 21 22 4E 28 08 9C
6547 : 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 39 A2
6548 : 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF
6549 : F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE
6554 Housley, et. al. Standards Track [Page 117]
6556 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
6561 455 03 133: BIT STRING 0 unused bits, encapsulates {
6563 : 00 B5 9E 1F 49 04 47 D1 DB F5 3A DD CA 04
6564 : 75 E8 DD 75 F6 9B 8A B1 97 D6 59 69 82 D3
6565 : 03 4D FD 3B 36 5F 4A F2 D1 4E C1 07 F5 D1
6566 : 2A D3 78 77 63 56 EA 96 61 4D 42 0B 7A 1D
6567 : FB AB 91 A4 CE DE EF 77 C8 E5 EF 20 AE A6
6568 : 28 48 AF BE 69 C3 6A A5 30 F2 C2 B9 D9 82
6569 : 2B 7D D9 C4 84 1F DE 0D E8 54 D7 1B 99 2E
6570 : B3 D0 88 F6 D6 63 9B A7 E2 0E 82 D4 3B 8A
6571 : 68 1B 06 56 31 59 0B 49 EB 99 A5 D5 81 41
6576 593 30 48: SEQUENCE {
6577 595 30 29: SEQUENCE {
6578 597 06 3: OBJECT IDENTIFIER
6579 : subjectKeyIdentifier (2 5 29 14)
6580 602 04 22: OCTET STRING, encapsulates {
6581 604 04 20: OCTET STRING
6582 : 86 CA A5 22 81 62 EF AD 0A 89 BC AD 72 41
6586 626 30 15: SEQUENCE {
6587 628 06 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19)
6588 633 01 1: BOOLEAN TRUE
6589 636 04 5: OCTET STRING, encapsulates {
6590 638 30 3: SEQUENCE {
6591 640 01 1: BOOLEAN TRUE
6598 643 30 9: SEQUENCE {
6599 645 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
6601 654 03 47: BIT STRING 0 unused bits, encapsulates {
6602 657 30 44: SEQUENCE {
6604 : 43 1B CF 29 25 45 C0 4E 52 E7 7D D6 FC B1
6610 Housley, et. al. Standards Track [Page 118]
6612 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
6615 : 0B 5B 9A 24 11 98 E8 F3 86 90 04 F6 08 A9
6623 This section contains an annotated hex dump of a 730 byte version 3
6624 certificate. The certificate contains the following information:
6625 (a) the serial number is 18 (12 hex);
6626 (b) the certificate is signed with DSA and the SHA-1 hash algorithm;
6627 (c) the issuer's distinguished name is OU=nist; O=gov; C=US
6628 (d) and the subject's distinguished name is CN=Tim Polk; OU=nist;
6630 (e) the certificate was valid from July 30, 1997 through December 1,
6632 (f) the certificate contains a 1024 bit DSA public key;
6633 (g) the certificate is an end entity certificate, as the basic
6634 constraints extension is not present;
6635 (h) the certificate contains an authority key identifier extension
6636 matching the subject key identifier of the certificate in Appendix
6638 (i) the certificate includes one alternative name - an RFC 822
6639 address of "wpolk@nist.gov".
6641 0 30 730: SEQUENCE {
6642 4 30 665: SEQUENCE {
6648 18 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
6650 27 30 42: SEQUENCE {
6653 33 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
6654 38 13 2: PrintableString 'US'
6658 44 30 10: SEQUENCE {
6659 46 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
6660 51 13 3: PrintableString 'gov'
6666 Housley, et. al. Standards Track [Page 119]
6668 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
6672 58 30 11: SEQUENCE {
6673 60 06 3: OBJECT IDENTIFIER
6674 : organizationalUnitName (2 5 4 11)
6675 65 13 4: PrintableString 'NIST'
6679 71 30 30: SEQUENCE {
6680 73 17 13: UTCTime '970730000000Z'
6681 88 17 13: UTCTime '971201000000Z'
6683 103 30 61: SEQUENCE {
6685 107 30 9: SEQUENCE {
6686 109 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
6687 114 13 2: PrintableString 'US'
6691 120 30 10: SEQUENCE {
6692 122 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
6693 127 13 3: PrintableString 'gov'
6697 134 30 11: SEQUENCE {
6698 136 06 3: OBJECT IDENTIFIER
6699 : organizationalUnitName (2 5 4 11)
6700 141 13 4: PrintableString 'NIST'
6704 149 30 15: SEQUENCE {
6705 151 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
6706 156 13 8: PrintableString 'Tim Polk'
6710 166 30 439: SEQUENCE {
6711 170 30 300: SEQUENCE {
6712 174 06 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1)
6713 183 30 287: SEQUENCE {
6715 : 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC
6716 : FB 95 32 AC 01 12 33 B9 E0 1C AD 90 9B BC
6717 : 48 54 9E F3 94 77 3C 2C 71 35 55 E6 FE 4F
6718 : 22 CB D5 D8 3E 89 93 33 4D FC BD 4F 41 64
6722 Housley, et. al. Standards Track [Page 120]
6724 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
6727 : 3E A2 98 70 EC 31 B4 50 DE EB F1 98 28 0A
6728 : C9 3E 44 B3 FD 22 97 96 83 D0 18 A3 E3 BD
6729 : 35 5B FF EE A3 21 72 6A 7B 96 DA B9 3F 1E
6730 : 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A
6731 : FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48
6734 : 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA
6735 : 55 F7 7D 57 74 81 E5
6737 : 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91
6738 : C0 8E 47 F1 0A C3 01 47 C2 44 42 36 A9 92
6739 : 81 DE 57 C5 E0 68 86 58 00 7B 1F F9 9B 77
6740 : A1 C5 10 A5 80 91 78 51 51 3C F6 FC FC CC
6741 : 46 C6 81 78 92 84 3D F4 93 3D 0C 38 7E 1A
6742 : 5B 99 4E AB 14 64 F6 0C 21 22 4E 28 08 9C
6743 : 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 39 A2
6744 : 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF
6745 : F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE
6749 474 03 132: BIT STRING 0 unused bits, encapsulates {
6751 : 30 B6 75 F7 7C 20 31 AE 38 BB 7E 0D 2B AB
6752 : A0 9C 4B DF 20 D5 24 13 3C CD 98 E5 5F 6C
6753 : B7 C1 BA 4A BA A9 95 80 53 F0 0D 72 DC 33
6754 : 37 F4 01 0B F5 04 1F 9D 2E 1F 62 D8 84 3A
6755 : 9B 25 09 5A 2D C8 46 8E 2B D4 F5 0D 3B C7
6756 : 2D C6 6C B9 98 C1 25 3A 44 4E 8E CA 95 61
6757 : 35 7C CE 15 31 5C 23 13 1E A2 05 D1 7A 24
6758 : 1C CB D3 72 09 90 FF 9B 9D 28 C0 A1 0A EC
6759 : 46 9F 0D B8 D0 DC D0 18 A6 2B 5E F9 8F B5
6764 611 30 60: SEQUENCE {
6765 613 30 25: SEQUENCE {
6766 615 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17)
6767 620 04 18: OCTET STRING, encapsulates {
6768 622 30 16: SEQUENCE {
6769 624 81 14: [1] 'wpolk@nist.gov'
6773 640 30 31: SEQUENCE {
6774 642 06 3: OBJECT IDENTIFIER
6778 Housley, et. al. Standards Track [Page 121]
6780 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
6783 : authorityKeyIdentifier (2 5 29 35)
6784 647 04 24: OCTET STRING, encapsulates {
6785 649 30 22: SEQUENCE {
6787 : 86 CA A5 22 81 62 EF AD 0A 89 BC AD 72
6788 : 41 2C 29 49 F4 86 56
6795 673 30 9: SEQUENCE {
6796 675 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
6798 684 03 48: BIT STRING 0 unused bits, encapsulates {
6799 687 30 45: SEQUENCE {
6801 : 36 97 CB E3 B4 2C E1 BB 61 A9 D3 CC 24 CC
6804 : 00 AB C9 79 AF D2 16 1C A9 E3 68 A9 14 10
6805 : B4 A0 2E FF 22 5A 73
6810 C.3 End Entity Certificate Using RSA
6812 This section contains an annotated hex dump of a 654 byte version 3
6813 certificate. The certificate contains the following information:
6814 (a) the serial number is 256;
6815 (b) the certificate is signed with RSA and the SHA-1 hash algorithm;
6816 (c) the issuer's distinguished name is OU=NIST; O=gov; C=US
6817 (d) and the subject's distinguished name is CN=Tim Polk; OU=NIST;
6819 (e) the certificate was issued on May 21, 1996 at 09:58:26 and
6820 expired on May 21, 1997 at 09:58:26;
6821 (f) the certificate contains a 1024 bit RSA public key;
6822 (g) the certificate is an end entity certificate (not a CA
6824 (h) the certificate includes an alternative subject name of
6825 "<http://www.itl.nist.gov/div893/staff/polk/index.html>" and an
6826 alternative issuer name of "<http://www.nist.gov/>" - both are URLs;
6827 (i) the certificate include an authority key identifier extension
6828 and a certificate policies extension specifying the policy OID
6829 2.16.840.1.101.3.2.1.48.9; and
6834 Housley, et. al. Standards Track [Page 122]
6836 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
6839 (j) the certificate includes a critical key usage extension
6840 specifying that the public key is intended for verification of
6843 0 30 654: SEQUENCE {
6844 4 30 503: SEQUENCE {
6848 13 02 2: INTEGER 256
6849 17 30 13: SEQUENCE {
6850 19 06 9: OBJECT IDENTIFIER
6851 : sha1withRSAEncryption (1 2 840 113549 1 1 5)
6854 32 30 42: SEQUENCE {
6857 38 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
6858 43 13 2: PrintableString 'US'
6862 49 30 10: SEQUENCE {
6863 51 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
6864 56 13 3: PrintableString 'gov'
6868 63 30 11: SEQUENCE {
6869 65 06 3: OBJECT IDENTIFIER
6870 : organizationalUnitName (2 5 4 11)
6871 70 13 4: PrintableString 'NIST'
6875 76 30 30: SEQUENCE {
6876 78 17 13: UTCTime '960521095826Z'
6877 93 17 13: UTCTime '970521095826Z'
6879 108 30 61: SEQUENCE {
6881 112 30 9: SEQUENCE {
6882 114 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
6883 119 13 2: PrintableString 'US'
6890 Housley, et. al. Standards Track [Page 123]
6892 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
6895 125 30 10: SEQUENCE {
6896 127 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
6897 132 13 3: PrintableString 'gov'
6901 139 30 11: SEQUENCE {
6902 141 06 3: OBJECT IDENTIFIER
6903 : organizationalUnitName (2 5 4 11)
6904 146 13 4: PrintableString 'NIST'
6908 154 30 15: SEQUENCE {
6909 156 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
6910 161 13 8: PrintableString 'Tim Polk'
6914 171 30 159: SEQUENCE {
6915 174 30 13: SEQUENCE {
6916 176 06 9: OBJECT IDENTIFIER
6917 : rsaEncryption (1 2 840 113549 1 1 1)
6920 189 03 141: BIT STRING 0 unused bits, encapsulates {
6921 193 30 137: SEQUENCE {
6923 : 00 E1 6A E4 03 30 97 02 3C F4 10 F3 B5 1E
6924 : 4D 7F 14 7B F6 F5 D0 78 E9 A4 8A F0 A3 75
6925 : EC ED B6 56 96 7F 88 99 85 9A F2 3E 68 77
6926 : 87 EB 9E D1 9F C0 B4 17 DC AB 89 23 A4 1D
6927 : 7E 16 23 4C 4F A8 4D F5 31 B8 7C AA E3 1A
6928 : 49 09 F4 4B 26 DB 27 67 30 82 12 01 4A E9
6929 : 1A B6 C1 0C 53 8B 6C FC 2F 7A 43 EC 33 36
6930 : 7E 32 B2 7B D5 AA CF 01 14 C6 12 EC 13 F2
6931 : 2D 14 7A 8B 21 58 14 13 4C 46 A3 9A F2 16
6933 328 02 3: INTEGER 65537
6938 336 30 172: SEQUENCE {
6939 339 30 63: SEQUENCE {
6940 341 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17)
6941 346 04 56: OCTET STRING, encapsulates {
6942 348 30 54: SEQUENCE {
6946 Housley, et. al. Standards Track [Page 124]
6948 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
6952 : 'http://www.itl.nist.gov/div893/staff/'
6957 404 30 31: SEQUENCE {
6958 406 06 3: OBJECT IDENTIFIER issuerAltName (2 5 29 18)
6959 411 04 24: OCTET STRING, encapsulates {
6960 413 30 22: SEQUENCE {
6961 415 86 20: [6] 'http://www.nist.gov/'
6965 437 30 31: SEQUENCE {
6966 439 06 3: OBJECT IDENTIFIER
6967 : authorityKeyIdentifier (2 5 29 35)
6968 444 04 24: OCTET STRING, encapsulates {
6969 446 30 22: SEQUENCE {
6971 : 08 68 AF 85 33 C8 39 4A 7A F8 82 93 8E
6972 : 70 6A 4A 20 84 2C 32
6976 470 30 23: SEQUENCE {
6977 472 06 3: OBJECT IDENTIFIER
6978 : certificatePolicies (2 5 29 32)
6979 477 04 16: OCTET STRING, encapsulates {
6980 479 30 14: SEQUENCE {
6981 481 30 12: SEQUENCE {
6982 483 06 10: OBJECT IDENTIFIER
6983 : '2 16 840 1 101 3 2 1 48 9'
6988 495 30 14: SEQUENCE {
6989 497 06 3: OBJECT IDENTIFIER keyUsage (2 5 29 15)
6990 502 01 1: BOOLEAN TRUE
6991 505 04 4: OCTET STRING, encapsulates {
6992 507 03 2: BIT STRING 7 unused bits
7002 Housley, et. al. Standards Track [Page 125]
7004 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
7007 511 30 13: SEQUENCE {
7008 513 06 9: OBJECT IDENTIFIER
7009 : sha1withRSAEncryption (1 2 840 113549 1 1 5)
7012 526 03 129: BIT STRING 0 unused bits
7013 : 1E 07 77 6E 66 B5 B6 B8 57 F0 03 DC 6F 77
7014 : 6D AF 55 1D 74 E5 CE 36 81 FC 4B C5 F4 47
7015 : 82 C4 0A 25 AA 8D D6 7D 3A 89 AB 44 34 39
7016 : F6 BD 61 1A 78 85 7A B8 1E 92 A2 22 2F CE
7017 : 07 1A 08 8E F1 46 03 59 36 4A CB 60 E6 03
7018 : 40 01 5B 2A 44 D6 E4 7F EB 43 5E 74 0A E6
7019 : E4 F9 3E E1 44 BE 1F E7 5F 5B 2C 41 8D 08
7020 : BD 26 FE 6A A6 C3 2F B2 3B 41 12 6B C1 06
7021 : 8A B8 4C 91 59 EB 2F 38 20 2A 67 74 20 0B
7025 C.4 Certificate Revocation List
7027 This section contains an annotated hex dump of a version 2 CRL with
7028 one extension (cRLNumber). The CRL was issued by OU=NIST; O=gov;
7029 C=US on August 7, 1997; the next scheduled issuance was September 7,
7030 1997. The CRL includes one revoked certificates: serial number 18
7031 (12 hex), which was revoked on July 31, 1997 due to keyCompromise.
7032 The CRL itself is number 18, and it was signed with DSA and SHA-1.
7034 0 30 203: SEQUENCE {
7035 3 30 140: SEQUENCE {
7038 11 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
7040 20 30 42: SEQUENCE {
7043 26 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
7044 31 13 2: PrintableString 'US'
7048 37 30 10: SEQUENCE {
7049 39 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
7050 44 13 3: PrintableString 'gov'
7054 51 30 11: SEQUENCE {
7058 Housley, et. al. Standards Track [Page 126]
7060 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
7063 53 06 3: OBJECT IDENTIFIER
7064 : organizationalUnitName (2 5 4 11)
7065 58 13 4: PrintableString 'NIST'
7069 64 17 13: UTCTime '970807000000Z'
7070 79 17 13: UTCTime '970907000000Z'
7071 94 30 34: SEQUENCE {
7072 96 30 32: SEQUENCE {
7074 101 17 13: UTCTime '970731000000Z'
7075 116 30 12: SEQUENCE {
7076 118 30 10: SEQUENCE {
7077 120 06 3: OBJECT IDENTIFIER cRLReason (2 5 29 21)
7078 125 04 3: OCTET STRING, encapsulates {
7079 127 0A 1: ENUMERATED 1
7086 132 30 12: SEQUENCE {
7087 134 30 10: SEQUENCE {
7088 136 06 3: OBJECT IDENTIFIER cRLNumber (2 5 29 20)
7089 141 04 3: OCTET STRING, encapsulates {
7090 143 02 1: INTEGER 12
7096 146 30 9: SEQUENCE {
7097 148 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
7099 157 03 47: BIT STRING 0 unused bits, encapsulates {
7100 160 30 44: SEQUENCE {
7102 : 22 4E 9F 43 BA 95 06 34 F2 BB 5E 65 DB A6
7105 : 59 1A 57 C9 82 D7 02 21 14 C3 D4 0B 32 1B
7114 Housley, et. al. Standards Track [Page 127]
7116 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
7123 918 Spring Knoll Drive
7127 EMail: rhousley@rsasecurity.com
7135 EMail: wford@verisign.com
7139 Building 820, Room 426
7140 Gaithersburg, MD 20899
7143 EMail: wpolk@nist.gov
7147 909 Third Ave, 16th Floor
7151 EMail: dsolo@alum.mit.edu
7170 Housley, et. al. Standards Track [Page 128]
7172 RFC 3280 Internet X.509 Public Key Infrastructure April 2002
7175 Full Copyright Statement
7177 Copyright (C) The Internet Society (2002). All Rights Reserved.
7179 This document and translations of it may be copied and furnished to
7180 others, and derivative works that comment on or otherwise explain it
7181 or assist in its implementation may be prepared, copied, published
7182 and distributed, in whole or in part, without restriction of any
7183 kind, provided that the above copyright notice and this paragraph are
7184 included on all such copies and derivative works. However, this
7185 document itself may not be modified in any way, such as by removing
7186 the copyright notice or references to the Internet Society or other
7187 Internet organizations, except as needed for the purpose of
7188 developing Internet standards in which case the procedures for
7189 copyrights defined in the Internet Standards process must be
7190 followed, or as required to translate it into languages other than
7193 The limited permissions granted above are perpetual and will not be
7194 revoked by the Internet Society or its successors or assigns.
7196 This document and the information contained herein is provided on an
7197 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
7198 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
7199 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
7200 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
7201 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
7205 Funding for the RFC Editor function is currently provided by the
7226 Housley, et. al. Standards Track [Page 129]
Code Review / com / asn1c.git / blob