idnits 2.17.1 draft-ietf-pkix-ipki-part1-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 109 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 110 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 22 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 561: '... issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,...' RFC 2119 keyword, line 563: '... subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,...' RFC 2119 keyword, line 565: '... extensions [3] EXPLICIT Extensions OPTIONAL...' RFC 2119 keyword, line 621: '... ANY DEFINED BY algorithm OPTIONAL }...' RFC 2119 keyword, line 939: '... keyIdentifier [0] KeyIdentifier OPTIONAL,...' (129 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 168 has weird spacing: '...ate the certi...' == Line 317 has weird spacing: '...ication path ...' == Line 473 has weird spacing: '...issuing a cer...' == Line 483 has weird spacing: '...: This is th...' == Line 1233 has weird spacing: '...its the host,...' == (5 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 14, 1997) is 9684 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 4744 -- Looks like a reference, but probably isn't: '1' on line 4903 -- Looks like a reference, but probably isn't: '2' on line 4298 -- Looks like a reference, but probably isn't: '3' on line 4817 -- Looks like a reference, but probably isn't: '4' on line 4173 -- Looks like a reference, but probably isn't: '5' on line 4174 -- Looks like a reference, but probably isn't: '6' on line 4176 -- Looks like a reference, but probably isn't: '7' on line 3946 -- Looks like a reference, but probably isn't: '8' on line 3947 == Missing Reference: 'RFC1738' is mentioned on line 1976, but not defined ** Obsolete undefined reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) == Missing Reference: 'RFC1778' is mentioned on line 1976, but not defined ** Obsolete undefined reference: RFC 1778 (Obsoleted by RFC 3494) == Missing Reference: 'DB94' is mentioned on line 2380, but not defined == Missing Reference: 'UNIVERSAL 28' is mentioned on line 2881, but not defined == Missing Reference: 'UNIVERSAL 30' is mentioned on line 2884, but not defined == Missing Reference: 'APPLICATION 0' is mentioned on line 4146, but not defined == Missing Reference: 'APPLICATION 1' is mentioned on line 4179, but not defined == Missing Reference: 'APPLICATION 2' is mentioned on line 4185, but not defined == Unused Reference: 'FIPS 180-1' is defined on line 2695, but no explicit reference was found in the text == Unused Reference: 'RFC 791' is defined on line 2715, but no explicit reference was found in the text == Unused Reference: 'RFC 1423' is defined on line 2724, but no explicit reference was found in the text == Unused Reference: 'RFC 1738' is defined on line 2728, but no explicit reference was found in the text == Unused Reference: 'RFC 1777' is defined on line 2731, but no explicit reference was found in the text == Unused Reference: 'RFC 1778' is defined on line 2734, but no explicit reference was found in the text == Unused Reference: 'RFC 1883' is defined on line 2737, but no explicit reference was found in the text == Unused Reference: 'RFC 1959' is defined on line 2740, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'COR95' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS 180-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS 186' -- Possible downref: Non-RFC (?) normative reference: ref. 'OIW' -- Possible downref: Non-RFC (?) normative reference: ref. 'RC95' ** Obsolete normative reference: RFC 1319 (Obsoleted by RFC 6149) ** Downref: Normative reference to an Historic RFC: RFC 1422 ** Downref: Normative reference to an Historic RFC: RFC 1423 ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 1777 (Obsoleted by RFC 3494) ** Obsolete normative reference: RFC 1778 (Obsoleted by RFC 3494) ** Obsolete normative reference: RFC 1883 (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 1959 (Obsoleted by RFC 2255) == Outdated reference: A later version (-09) exists of draft-ietf-pkix-ipki3cmp-04 == Outdated reference: A later version (-08) exists of draft-ietf-pkix-ipki2opp-03 ** Downref: Normative reference to an Historic draft: draft-ietf-pkix-ipki2opp (ref. 'PKIXLDAP') == Outdated reference: A later version (-08) exists of draft-ietf-pkix-ipki2opp-02 -- Duplicate reference: draft-ietf-pkix-ipki2opp, mentioned in 'PKIXOCSP', was also mentioned in 'PKIXLDAP'. ** Downref: Normative reference to an Historic draft: draft-ietf-pkix-ipki2opp (ref. 'PKIXOCSP') == Outdated reference: A later version (-04) exists of draft-ietf-pkix-opp-ftp-http-00 Summary: 24 errors (**), 0 flaws (~~), 31 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group R. Housley (SPYRUS) 3 Internet Draft W. Ford (Verisign) 4 W. Polk (NIST) 5 D. Solo (BBN) 6 expires in six months October 14, 1997 8 Internet Public Key Infrastructure 10 X.509 Certificate and CRL Profile 12 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 To learn the current status of any Internet-Draft, please check the 27 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 28 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 29 munnari.oz.au Pacific Rim), ds.internic.net (US East Coast), or 30 ftp.isi.edu (US West Coast). 32 Abstract 34 This is the sixth draft of the Internet Public Key Infrastructure 35 X.509 Certificate and CRL Profile. This draft is a complete 36 specification. This text includes minor modifications over the 37 previous draft. Please send comments on this document to the ietf- 38 pkix@tandem.com mail list. 40 1 Executive Summary 42 This specification is one part of a multipart standard for the Public 43 Key Infrastructure (PKI) for the Internet. This specification is a 44 standalone document; implementations of this standard may proceed 45 independent from the other parts. 47 This specification profiles the format and semantics of certificates 48 and certificate revocation lists for the Internet PKI. Procedures 49 are described for processing of certification paths in the Internet 50 environment. Encoding rules are provided for popular cryptographic 51 algorithms. Finally, ASN.1 modules are provided in the appendices 52 for all data structure defined or referenced. 54 The specification describes the requirements which inspire the 55 creation of this document and the assumptions which affect its scope 56 in Section 2. Section 3 presents an architectural model and 57 describes its relationship to previous IETF and ISO standards. In 58 particular, this document's relationship with the IETF PEM 59 specifications and the ISO X.509 documents are described. 61 The specification profiles the X.509 version 3 certificate in Section 62 4, and the X.509 version 2 certificate revocation list (CRL) in 63 Section 5. The profiles include the identification of ISO and ANSI 64 extensions which may be useful in the Internet PKI and definition of 65 new extensions to meet the Internet's requirements. The profiles are 66 presented in the 1988 Abstract Syntax Notation One (ASN.1) rather 67 than the 1993 syntax used in the ISO standards. The ASN.1 notation 68 assumes implict tagging throughout. 70 This specification also includes path validation procedures in 71 Section 6. These procedures are based upon the ISO definition, but 72 the presentation assumes a self-signed root certificate. 73 Implementations are required to derive the same results but are not 74 required to use the specified procedures. 76 Finally, Section 7 of the specification describes procedures for 77 identification and encoding of public key materials and digital 78 signatures. Implementations are not required to use any particular 79 cryptographic algorithms. However, conforming implementations which 80 use the identified algorithms are required to identify and encode the 81 public key materials and digital signatures as described. 83 Appendix A contains all ASN.1 structures defined or referenced within 84 this specification. As above, the material is presented in the 1988 85 Abstract Syntax Notation One (ASN.1) rather than the 1993 syntax. 86 Appendix B contains the same information in the 1993 ASN.1 notation. 87 Appendix C contains notes on less familiar features of the ASN.1 88 notation used within this specification. Appendix D contains 89 examples of a conforming certificate and a conforming CRL. 91 2 Requirements and Assumptions 93 Goal is to develop a profile and associated management structure to 94 facilitate the adoption/use of X.509 certificates within Internet 95 applications for those communities wishing to make use of X.509 96 technology. Such applications may include WWW, electronic mail, user 97 authentication, and IPSEC, as well as others. In order to relieve 98 some of the obstacles to using X.509 certificates, this document 99 defines a profile to promote the development of certificate 100 management systems; development of application tools; and 101 interoperability determined by policy, as opposed to syntax. 103 Some communities will need to supplement, or possibly replace, this 104 profile in order to meet the requirements of specialized application 105 domains or environments with additional authorization, assurance, or 106 operational requirements. However, for basic applications, common 107 representations of frequently used attributes are defined so that 108 application developers can obtain necessary information without 109 regard to the issuer of a particular certificate or certificate 110 revocation list (CRL). 112 A certificate user should review the certification practice Statement 113 (CPS) generated by the CA before relying on the authentication or 114 non-repudiation services associated with the public key in a 115 particular certificate. To this end, this standard does not 116 prescribe legally binding rules or duties. 118 As supplemental authorization and attribute management tools emerge, 119 such as attribute certificates, it may be appropriate to limit the 120 authenticated attributes that are included in a certificate. These 121 other management tools may be more appropriate method of conveying 122 many authenticated attributes. 124 2.1 Communication and Topology 126 The users of certificates will operate in a wide range of 127 environments with respect to their communication topology, especially 128 users of secure electronic mail. This profile supports users without 129 high bandwidth, real-time IP connectivity, or high connection 130 availablity. In addition, the profile allows for the presence of 131 firewall or other filtered communication. 133 This profile does not assume the deployment of an X.500 Directory 134 system. The profile does not prohibit the use of an X.500 Directory, 135 but other means of distributing certificates and certificate 136 revocation lists (CRLs) are supported. 138 2.2 Acceptability Criteria 140 The goal of the Internet Public Key Infrastructure (PKI) is to meet 141 the needs of deterministic, automated identification, authentication, 142 access control, and authorization functions. Support for these 143 services determines the attributes contained in the certificate as 144 well as the ancillary control information in the certificate such as 145 policy data and certification path constraints. 147 2.3 User Expectations 149 Users of the Internet PKI are people and processes who use client 150 software and are the subjects named in certificates. These uses 151 include readers and writers of electronic mail, the clients for WWW 152 browsers, WWW servers, and the key manager for IPSEC within a router. 153 This profile recognizes the limitations of the platforms these users 154 employ and the sophistication/attentiveness of the users themselves. 155 This manifests itself in minimal user configuration responsibility 156 (e.g., root keys, rules), explicit platform usage constraints within 157 the certificate, certification path constraints which shield the user 158 from many malicious actions, and applications which sensibly automate 159 validation functions. 161 2.4 Administrator Expectations 163 As with users, the Internet PKI profile is structured to support the 164 individuals who generally operate Certification Authorities (CAs). 165 Providing administrators with unbounded choices increases the chances 166 that a subtle CA administrator mistake will result in broad 167 compromise. Also, unbounded choices greatly complicates the software 168 that must process and validate the certificates created by the CA. 170 3 Overview of Approach 172 Following is a simplified view of the architectural model assumed by 173 the PKIX specifications. 175 +---+ 176 | C | +------------+ 177 | e | <-------------------->| End entity | 178 | r | Operational +------------+ 179 | t | transactions ^ 180 | | and management | Management 181 | / | transactions | transactions 182 | | | 183 | C | PKI users v 184 | R | -------+-------+--------+------ 185 | L | PKI management ^ ^ 186 | | entities | | 187 | | v | 188 | R | +------+ | 189 | e | <-------------- | RA | <-----+ | 190 | p | certificate | | | | 191 | o | publish +------+ | | 192 | s | | | 193 | I | v v 194 | t | +------------+ 195 | o | <--------------------------| CA | 196 | r | certificate publish +------------+ 197 | y | CRL publish ^ 198 | | | 199 +---+ | Management 200 | transactions 201 v 202 +------+ 203 | CA | 204 +------+ 206 Figure 1 - PKI Entities 208 The components in this model are: 210 end entity: user of PKI certificates and/or end user system that 211 is the subject of a certificate; 212 CA: certification authority; 213 RA: registration authority, i.e., an optional system to 214 which a CA delegates certain management functions; 215 repository: a system or collection of distributed systems that 216 store certificates and CRLs and serves as a means of 217 distributing these certificates and CRLs to end 218 entities. 220 3.1 X.509 Version 3 Certificate 222 Application of public key technology requires the user of a public 223 key to be confident that the public key belongs to the correct remote 224 subject (person or system) with which an encryption or digital 225 signature mechanism will be used. This confidence is obtained 226 through the use of public key certificates, which are data structures 227 that bind public key values to subjects. The binding is achieved by 228 having a trusted certification authority (CA) digitally sign each 229 certificate. A certificate has a limited valid lifetime which is 230 indicated in its signed contents. Because a certificate's signature 231 and timeliness can be independently checked by a certificate-using 232 client, certificates can be distributed via untrusted communications 233 and server systems, and can be cached in unsecured storage in 234 certificate-using systems. 236 The standard known as ITU-T X.509 (formerly CCITT X.509) or ISO/IEC 237 9594-8, which was first published in 1988 as part of the X.500 238 Directory recommendations, defines a standard certificate format. The 239 certificate format in the 1988 standard is called the version 1 (v1) 240 format. When X.500 was revised in 1993, two more fields were added, 241 resulting in the version 2 (v2) format. These two fields are used to 242 support directory access control. 244 The Internet Privacy Enhanced Mail (PEM) proposals, published in 245 1993, include specifications for a public key infrastructure based on 246 X.509 v1 certificates [RFC 1422]. The experience gained in attempts 247 to deploy RFC 1422 made it clear that the v1 and v2 certificate 248 formats are deficient in several respects. Most importantly, more 249 fields were needed to carry information which PEM design and 250 implementation experience has proven necessary. In response to these 251 new requirements, ISO/IEC and ANSI X9 developed the X.509 version 3 252 (v3) certificate format. The v3 format extends the v2 format by 253 adding provision for additional extension fields. Particular 254 extension field types may be specified in standards or may be defined 255 and registered by any organization or community. In June 1996, 256 standardization of the basic v3 format was completed [X.509-AM]. 258 ISO/IEC and ANSI X9 have also developed standard extensions for use 259 in the v3 extensions field [X.509-AM][X9.55]. These extensions can 260 convey such data as additional subject identification information, 261 key attribute information, policy information, and certification path 262 constraints. 264 However, the ISO/IEC and ANSI standard extensions are very broad in 265 their applicability. In order to develop interoperable 266 implementations of X.509 v3 systems for Internet use, it is necessary 267 to specify a profile for use of the X.509 v3 extensions tailored for 268 the Internet. It is one goal of this document to specify a profile 269 for Internet WWW, electronic mail, and IPSEC applications. 270 Environments with additional requirements may build on this profile 271 or may replace it. 273 3.2 Certification Paths and Trust 275 A user of a security service requiring knowledge of a public key 276 generally needs to obtain and validate a certificate containing the 277 required public key. If the public-key user does not already hold an 278 assured copy of the public key of the CA that signed the certificate, 279 then it might need an additional certificate to obtain that public 280 key. In general, a chain of multiple certificates may be needed, 281 comprising a certificate of the public key owner (the end entity) 282 signed by one CA, and zero or more additional certificates of CAs 283 signed by other CAs. Such chains, called certification paths, are 284 required because a public key user is only initialized with a limited 285 number of assured CA public keys. 287 There are different ways in which CAs might be configured in order 288 for public key users to be able to find certification paths. For 289 PEM, RFC 1422 defined a rigid hierarchical structure of CAs. There 290 are three types of PEM certification authority: 292 (a) Internet Policy Registration Authority (IPRA): This 293 authority, operated under the auspices of the Internet Society, 294 acts as the root of the PEM certification hierarchy at level 1. 295 It issues certificates only for the next level of authorities, 296 PCAs. All certification paths start with the IPRA. 298 (b) Policy Certification Authorities (PCAs): PCAs are at level 2 299 of the hierarchy, each PCA being certified by the IPRA. A PCA 300 must establish and publish a statement of its policy with respect 301 to certifying users or subordinate certification authorities. 302 Distinct PCAs aim to satisfy different user needs. For example, 303 one PCA (an organizational PCA) might support the general 304 electronic mail needs of commercial organizations, and another PCA 305 (a high-assurance PCA) might have a more stringent policy designed 306 for satisfying legally binding signature requirements. 308 (c) Certification Authorities (CAs): CAs are at level 3 of the 309 hierarchy and can also be at lower levels. Those at level 3 are 310 certified by PCAs. CAs represent, for example, particular 311 organizations, particular organizational units (e.g., departments, 312 groups, sections), or particular geographical areas. 314 RFC 1422 furthermore has a name subordination rule which requires 315 that a CA can only issue certificates for entities whose names are 316 subordinate (in the X.500 naming tree) to the name of the CA itself. 317 The trust associated with a PEM certification path is implied by the 318 PCA name. The name subordination rule ensures that CAs below the PCA 319 are sensibly constrained as to the set of subordinate entities they 320 can certify (e.g., a CA for an organization can only certify entities 321 in that organization's name tree). Certificate user systems are able 322 to mechanically check that the name subordination rule has been 323 followed. 325 The RFC 1422 was based upon the X.509 v1 certificate formats. The 326 limitations of X.509 v1 required imposition of several structural 327 restrictions to clearly associate policy information or restrict the 328 utility of certificates. These restrictions included: 330 (a) a pure top-down hierarchy, with all certification paths 331 starting from the root; 333 (b) a naming subordination rule restricting the names of a CA's 334 subjects; and 336 (c) use of the PCA concept, which requires knowledge of individual 337 PCAs to be built into certificate chain verification logic. 338 Knowledge of individual PCAs was required to determine if a chain 339 could be accepted. 341 With X.509 v3, most of the requirements addressed by RFC 1422 can be 342 addressed using certificate extensions, without a need to restrict 343 the CA structures used. In particular, the certificate extensions 344 relating to certificate policies obviate the need for PCAs and the 345 constraint extensions obviate the need for the name subordination 346 rule. As a result, this document supports a more flexible 347 architecture, including: 349 (a) Certification paths may start with a public key of a CA in a 350 user's own domain, or with the public key of the top of a 351 hierarchy. Starting with the public key of a CA in a user's own 352 domain has certain advantages. In many environments, the local 353 domain is often the most trusted. Initialization and key-pair- 354 update operations can often be more effectively conducted between 355 an end entity and a local management system. 357 (b) Name constraints may be imposed through explicit inclusion of 358 a name constraints extension in a certificate, but are not 359 required. 361 (c) Policy extensions and policy mappings replace the PCA 362 concept, which permits a greater degree of automation. The 363 application can determine if the certification path is acceptable 364 based on the contents of the certificates instead of a priori 365 knowledge of PCAs. This permits the full process of certificate 366 chain processing to be implemented in software. 368 3.3 Revocation 370 When a certificate is issued, it is expected to be in use for its 371 entire validity period. However, various circumstances may cause a 372 certificate to become invalid prior to the expiration of the validity 373 period. Such circumstances might include change of name, change of 374 association between subject and CA (e.g., an employee terminates 375 employment with an organization), and compromise or suspected 376 compromise of the corresponding private key. Under such 377 circumstances, the CA needs to revoke the certificate. 379 X.509 defines one method of certificate revocation. This method 380 involves each CA periodically issuing a signed data structure called 381 a certificate revocation list (CRL). A CRL is a time stamped list 382 identifying revoked certificates which is signed by a CA and made 383 freely available in a public repository. Each revoked certificate is 384 identified in a CRL by its certificate serial number. When a 385 certificate-using system uses a certificate (e.g., for verifying a 386 remote user's digital signature), that system not only checks the 387 certificate signature and validity but also acquires a suitably- 388 recent CRL and checks that the certificate serial number is not on 389 that CRL. The meaning of "suitably-recent" may vary with local 390 policy, but it usually means the most recently-issued CRL. A CA 391 issues a new CRL on a regular periodic basis (e.g., hourly, daily, or 392 weekly). Entries are added to CRLs as revocations occur, and an 393 entry may be removed when the certificate expiration date is reached. 395 An advantage of this revocation method is that CRLs may be 396 distributed by exactly the same means as certificates themselves, 397 namely, via untrusted communications and server systems. 399 One limitation of the CRL revocation method, using untrusted 400 communications and servers, is that the time granularity of 401 revocation is limited to the CRL issue period. For example, if a 402 revocation is reported now, that revocation will not be reliably 403 notified to certificate-using systems until the next periodic CRL is 404 issued -- this may be up to one hour, one day, or one week depending 405 on the frequency that the CA issues CRLs. 407 Another potential problem with CRLs is the risk of a CRL growing to 408 an entirely unacceptable size. In the 1988 and 1993 versions of 409 X.509, the CRL for the end-user certificates needed to cover the 410 entire population of end-users for one CA. It is desirable to allow 411 such populations to be in the range of thousands, tens of thousands, 412 or possibly even hundreds of thousands of users. The end-user CRL is 413 therefore at risk of growing to such sizes, which present major 414 communication and storage overhead problems. With the version 2 CRL 415 format, introduced along with the v3 certificate format, it becomes 416 possible to arbitrarily divide the population of certificates for one 417 CA into a number of partitions, each partition being associated with 418 one CRL distribution point (e.g., directory entry or URL) from which 419 CRLs are distributed. Therefore, the maximum CRL size can be 420 controlled by a CA. Separate CRL distribution points can also exist 421 for different revocation reasons. For example, routine revocations 422 (e.g., name change) may be placed on a different CRL to revocations 423 resulting from suspected key compromises, and policy may specify that 424 the latter CRL be updated and issued more frequently than the former. 426 As with the X.509 v3 certificate format, in order to facilitate 427 interoperable implementations from multiple vendors, the X.509 v2 CRL 428 format needs to be profiled for Internet use. It is one goal of this 429 document to specify that profile. 431 Furthermore, it is recognized that on-line methods of revocation 432 notification may be applicable in some environments as an alternative 433 to the X.509 CRL. On-line revocation checking significantly reduces 434 the latency between a revocation report and the next issue of a CRL. 435 Once the CA accepts the report as authentic and valid, any query to 436 the on-line service will correctly reflect the certificate validation 437 impacts of the revocation. However, these methods impose new 438 security requirements; the certificate validator must trust the on- 439 line validation service while the repository did not need to be 440 trusted. 442 Therefore, this profile also considers standard approaches to on-line 443 revocation notification. The PKIX series of specifications defines a 444 set of standard message formats supporting these functions in 445 [PKIXOCSP]. The protocols for conveying these messages in different 446 environments are also specified. 448 3.4 Operational Protocols 450 Operational protocols are required to deliver certificates and CRLs 451 (or status information) to certificate using client systems. 452 Provision is needed for a variety of different means of certificate 453 and CRL delivery, including request/delivery procedures based on E- 454 mail, http, X.500, and WHOIS++. These specifications include 455 definitions of, and/or references to, message formats and procedures 456 for supporting all of the above operational environments, including 457 definitions of or references to appropriate MIME content types. 459 Operational protocols supporting these functions are defined in the 460 PKIX specifications [PKIXLDAP], [PKIXFTP] and [PKIXOCSP]. 462 3.5 Management Protocols 464 Management protocols are required to support on-line interactions 465 between Public Key Infrastructure (PKI) components. For example, 466 management protocol might be used between a CA and a client system 467 with which a key pair is associated, or between two CAs which cross- 468 certify each other. The set of functions which potentially need to 469 be supported by management protocols include: 471 (a) registration: This is the process whereby a user first makes 472 itself known to a CA (directly, or through an RA), prior to that CA 473 issuing a certificate or certificates for that user. 475 (b) initialization: Before a client system can operate securely it 476 is necessary to install in it necessary key materials which have the 477 appropriate relationship with keys stored elsewhere in the 478 infrastructure. For example, the client needs to be securely 479 initialized with the public key of a CA, to be used in validating 480 certificate paths. Furthermore, a client typically needs to be 481 initialized with its own key pair(s). 483 (c) certification: This is the process in which a CA issues a 484 certificate for a user's public key, and returns that certificate to 485 the user's client system and/or posts that certificate in a 486 repository. 488 (d) key pair recovery: As an option, user client key materials 489 (e.g., a user's private key used for encryption purposes) may be 490 backed up by a CA or a key backup system. If a user needs to recover 491 these backed up key materials (e.g., as a result of a forgotten 492 password or a lost key chain file), an on-line protocol exchange may 493 be needed to support such recovery. 495 (e) key pair update: All key pairs need to be updated regularly, 496 i.e., replaced with a new key pair, and new certificates issued. 498 (f) revocation request: An authorized person advises a CA of an 499 abnormal situation requiring certificate revocation. 501 (g) cross-certification: Two CAs exchange the information necessary 502 to establish cross-certificates between those CAs. 504 Note that on-line protocols are not the only way of implementing the 505 above functions. For all functions there are off-line methods of 506 achieving the same result, and this specification does not mandate 507 use of on-line protocols. For example, when hardware tokens are 508 used, many of the functions may be achieved as part of the physical 509 token delivery. Furthermore, some of the above functions may be 510 combined into one protocol exchange. In particular, two or more of 511 the registration, initialization, and certification functions can be 512 combined into one protocol exchange. 514 The PKIX series of specifications defines a set of standard message 515 formats supporting the above functions in [PKIXMGMT]. The protocols 516 for conveying these messages in different environments (on-line, e- 517 mail, and WWW) are also specified in [PKIXMGMT]. 519 4 Certificate and Certificate Extensions Profile 521 This section presents a profile for public key certificates that will 522 foster interoperability and a reusable public key infrastructure. 523 This section is based upon the X.509 V3 certificate format 524 [COR95][X.509-AM] and the standard certificate extensions defined in 525 the Amendment [X.509-AM]. The ISO documents use the 1993 version of 526 ASN.1; while this document uses the 1988 ASN.1 syntax, the encoded 527 certificate and standard extensions are equivalent. This section 528 also defines private extensions required to support a public key 529 infrastructure for the Internet community. 531 Certificates may be used in a wide range of applications and 532 environments covering a broad spectrum of interoperability goals and 533 a broader spectrum of operational and assurance requirements. The 534 goal of this document is to establish a common baseline for generic 535 applications requiring broad interoperability and limited special 536 purpose requirements. In particular, the emphasis will be on 537 supporting the use of X.509 v3 certificates for informal internet 538 electronic mail, IPSEC, and WWW applications. Other efforts are 539 looking at certificate profiles for payment systems. 541 4.1 Basic Certificate Fields 543 The X.509 v3 certificate basic syntax is as follows. For signature 544 calculation, the certificate is encoded using the ASN.1 distinguished 545 encoding rules (DER) [X.208]. ASN.1 DER encoding is a tag, length, 546 value encoding system for each element. 548 Certificate ::= SEQUENCE { 549 tbsCertificate TBSCertificate, 550 signatureAlgorithm AlgorithmIdentifier, 551 signature BIT STRING } 553 TBSCertificate ::= SEQUENCE { 554 version [0] EXPLICIT Version DEFAULT v1, 555 serialNumber CertificateSerialNumber, 556 signature AlgorithmIdentifier, 557 issuer Name, 558 validity Validity, 559 subject Name, 560 subjectPublicKeyInfo SubjectPublicKeyInfo, 561 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, 562 -- If present, version must be v2 or v3 563 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, 564 -- If present, version must be v2 or v3 565 extensions [3] EXPLICIT Extensions OPTIONAL 566 -- If present, version must be v3 567 } 569 Version ::= INTEGER { v1(0), v2(1), v3(2) } 571 CertificateSerialNumber ::= INTEGER 573 Validity ::= SEQUENCE { 574 notBefore Time, 575 notAfter Time } 577 Time ::= CHOICE { 578 utcTime UTCTime, 579 generalTime GeneralizedTime } 581 UniqueIdentifier ::= BIT STRING 583 SubjectPublicKeyInfo ::= SEQUENCE { 584 algorithm AlgorithmIdentifier, 585 subjectPublicKey BIT STRING } 587 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 589 Extension ::= SEQUENCE { 590 extnID OBJECT IDENTIFIER, 591 critical BOOLEAN DEFAULT FALSE, 592 extnValue OCTET STRING } 594 The following items describe a proposed use of the X.509 v3 595 certificate for the Internet. 597 4.1.1 Certificate Fields 599 The Certificate is a SEQUENCE of three required fields. The fields 600 are are described in detail in the following subsections 602 4.1.1.1 tbsCertificate 604 The first field in the sequence is the tbsCertificate. This is a 605 itself a sequence, and contains the names of the subject and issuer, 606 a public key associated with the subject an expiration date, and 607 other associated information. The fields of the basic tbsCertificate 608 are described in detail in section 4.1.2; the tbscertificate may also 609 include extensions which are described in section 4.2. 611 4.1.1.2 signatureAlgorithm 613 The signatureAlgorithm field contains the algorithm identifier for 614 the algorithm used by the CA to sign this certificate. Section 7.2 615 lists the supported signature algorithms. 617 An algorithm identifier is defined by the following ASN.1 structure: 619 AlgorithmIdentifier ::= SEQUENCE { 620 algorithm OBJECT IDENTIFIER, 621 parameters ANY DEFINED BY algorithm OPTIONAL } 623 and it is used to identify a cryptographic algorithm. The OBJECT 624 IDENTIFIER algorithm identifies the algorithm (such as RSA with SHA- 625 1). The contents of the optional parameters field will vary according 626 to the algorithm identfied and the purpose of the algorithm 627 identifier. 629 In this case, the parameters field will usually be empty. Section 7.2 630 lists the supported algorithms for this specification and describes 631 the contents of the parameters fields for each algorithm. 633 This field should contain the same algorithm identifier as the 634 signature field in the sequence tbsCertificate (see section 4.1.2.3) 636 4.1.1.3 signature 638 The signature field contains a digital signature computed upon the 639 ASN.1 DER encoded TBSCertificate. The ASN.1 DER encoded 640 TBSCertificate is used as the input to a one-way hash function. The 641 one-way hash function output value is encrypted (e.g., using RSA 642 Encryption) to form the signed quantity. This signature value is 643 then ASN.1 encoded as a BIT STRING and included in the Certificate's 644 signature field. The details of this process are specified for each 645 of the supported algorithms in Section 7.2. 647 By generating this signature, a CA certifies the validity of the 648 information in tbscertificate. In particular, the CA certifies the 649 binding between the public key material and the subject of the 650 certificate. 652 4.1.2 TBSCertificate 654 The sequence TBSCertificate is a sequence which contains information 655 associated with the subject of the certificate and the CA who issued 656 it. Every TBSCertificate contains the names of the subject and 657 issuer, a public key associated with the subject, an expiration date, 658 a version number and a serial number; some will contain optional 659 unique identifier fields. The remainder of this section describes 660 the syntax and semantics of these fields. A TBSCertificate may also 661 include extensions. Extensions for the Internet PKI are described in 662 Section 4.2. 664 4.1.2.1 Version 666 This field describes the version of the encoded certificate. When 667 extensions are used, as expected in this profile, use X.509 version 3 668 (value is 2). If no extensions are present, but a UniqueIdentifier 669 is present, use version 2 (value is 1). If only basic fields are 670 present, use version 1 (the value is omitted from the certificate as 671 the default value). 673 Implementations should be prepared to accept any version certificate. 674 At a minimum, conforming implementations shall recognize version 3 675 certificates. 677 Generation of version 2 certificates is not expected by 678 implementations based on this profile. 680 4.1.2.2 Serial number 682 The serial number is an integer assigned by the certification 683 authority to each certificate. It must be unique for each 684 certificate issued by a given CA (i.e., the issuer name and serial 685 number identify a unique certificate). 687 4.1.2.3 Signature 689 This field contains the algorithm identifier for the algorithm used 690 by the CA to sign the certificate. Section 7.2 lists the supported 691 signature algorithms. 693 This field should contain the same algorithm identifier as the 694 signatureAlgorithm field in the sequence Certificate (see section 695 4.1.1.2). 697 4.1.2.4 Issuer Name 699 The issuer name identifies the entity who has signed (and issued the 700 certificate). The issuer identity may be carried in the issuer name 701 field and/or the issuerAltName extension. If identity information is 702 present only in the issuerAltName extension, then the issuer name may 703 be an empty sequence and the issuerAltName extension must be 704 critical. 706 Where it is non-null, the issuer name field shall contain an X.500 707 distinguished name (DN). The issuer field is defined as the X.501 708 type Name. Name is defined by the following ASN.1 structures: 710 Name ::= CHOICE { 711 RDNSequence } 713 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 715 RelativeDistinguishedName ::= 716 SET OF AttributeTypeAndValue 718 AttributeTypeAndValue ::= SEQUENCE { 719 type AttributeType, 720 value AttributeValue } 722 AttributeType ::= OBJECT IDENTIFIER 724 AttributeValue ::= ANY 726 -- Directory string type -- 728 DirectoryString ::= CHOICE { 729 teletexString TeletexString (SIZE (1..maxSize), 730 printableString PrintableString (SIZE (1..maxSize)), 731 universalString UniversalString (SIZE (1..maxSize)), 732 bmpString BMPString (SIZE(1..maxSIZE)) 733 } 735 The Name describes a hierarchical name composed of attributes, such 736 as country name, and corresponding values, such as US. The type of 737 the component AttributeValue is determined by the AttributeType; in 738 general it will be a directoryString. 740 The directoryString is defined as a choice of PrintableString, 741 TeletexString, BMPString and UniversalString. Conforming CAs shall 742 choose from these options as follows: 744 (a) if the character set is sufficient, the string will be 745 represented as a PrintableString; 747 (b) failing (a), if the teletexString character set is sufficient, 748 the string will be represented as a TeletexString; 750 (c) failing (a) and (b), if the bMPString character set is 751 sufficient the string shall be represented as a BMPString; and 753 (d) failing (a), (b) and (c), the string shall be represented as a 754 UniversalString. 756 Standard sets of attributes have been defined in the X.500 series of 757 specifications. Where CAs issue certificates with X.501 type names, 758 it is recommended that these attributes types be used. 760 4.1.2.5 Validity 762 This field indicates the period of validity of the certificate, and 763 consists of two dates, the first and last on which the certificate is 764 valid. The certificate validity period is the time interval during 765 which the CA warrants that it will maintain information about the 766 status of the certificate, i.e. publish revocation data. The field is 767 represented as a SEQUENCE of two dates: the date on which the 768 certificate validity period begins (notBefore) and the date on which 769 the certificate validity period ends (notAfter). Both notBefore and 770 notAfter may be encoded as UTCTime or GeneralizedTime. 772 CAs conforming to this profile shall always encode certificate 773 validity dates through the year 2049 as UTCTime; certificate validity 774 dates in 2050 or later shall be encoded as GeneralizedTime. 776 4.1.2.5.1 UTCTime 778 The universal time type, UTCTime, is a standard ASN.1 type intended 779 for international applications where local time alone is not 780 adequate. UTCTime specifies the year through the two low order 781 digits and time is specified to the precision of one minute or one 782 second. UTCTime includes either Z (for Zulu, or Greenwich Mean Time) 783 or a time differential. 785 For the purposes of this profile, UTCTime values shall be expressed 786 Greenwich Mean Time (Zulu) and shall include seconds (i.e., times are 787 YYMMDDHHMMSSZ), even where the number of seconds is zero. Conforming 788 systems shall interpret the year field (YY) as follows: 790 Where YY is greater than or equal to 50, the year shall be 791 interpreted as 19YY; and 792 Where YY is less than 50, the year shall be interpreted as 20YY. 794 4.1.2.5.2 GeneralizedTime 796 The generalized time type, GeneralizedTime, is a standard ASN.1 type 797 for variable precision representation of time. Optionally, the 798 GeneralizedTime field can include a representation of the time 799 differential between local and Greenwich Mean Time. 801 For the purposes of this profile, GeneralizedTime values shall be 802 expressed Greenwich Mean Time (Zulu) and shall include seconds (i.e., 803 times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. 804 GeneralizedTime values shall not include fractional seconds. 806 4.1.2.6 Subject Name 808 The subject name identifies the entity associated with the public key 809 stored in the subject public key field. The subject identity may be 810 carried in the subject field and/or the subjectAltName extension. If 811 identity information is present only in the subjectAltName extension 812 (e.g., a key bound only to an email address or URI), then the subject 813 name may be an empty sequence and the subjectAltName extension must 814 be critical. 816 Where it is non-null, the subject name field shall contain an X.500 817 distinguished name (DN). The DN must be unique for each subject 818 entity certified by the one CA as defined by the issuer name field. 819 (A CA may issue more than one certificate with the same DN to the 820 same subject entity.) 822 The subject name field is defined as the X.501 type Name, and shall 823 follow the encoding rules for the issuer name field (see 4.1.2.4). 825 4.1.2.7 Subject Public Key Info 827 This field is used to carry the public key and identify the algorithm 828 with which the key is used. The algorithm is identified using the 829 algorithmIdentifier structure specified in Section 4.1.1.2. The 830 object identifiers for the supported algorithms and the methods for 831 encoding the public key materials (public key and parameters) are 832 specified in Section 7.3. 834 4.1.2.8 Unique Identifiers 836 The subject and issuer unique identifier are present in the 837 certificate to handle the possibility of reuse of subject and/or 838 issuer names over time. This profile recommends that names not be 839 reused and that Internet certificates not make use of unique 840 identifiers. CAs conforming to this profile should not generate 841 certificates with unique identifiers. Applications conforming to 842 this profile should be capable of parsing unique identifiers and 843 making comparisons. 845 4.1.2.9 Extensions 847 This field may only appear if the version number is 3 (see 4.1.2.x). 848 If present, this field is a SEQUENCE of one or more certificate 849 extensions. The format and content of certificate extensions in the 850 Internet PKI is defined in Section 4.2. 852 4.2 Certificate Extensions 854 The extensions defined for X.509 v3 certificates provide methods for 855 associating additional attributes with users or public keys, for 856 managing the certification hierarchy, and for managing CRL 857 distribution. The X.509 v3 certificate format also allows 858 communities to define private extensions to carry information unique 859 to those communities. Each extension in a certificate may be 860 designated as critical or non-critical. A certificate using system 861 (an application validating a certificate) must reject the certificate 862 if it encounters a critical extension it does not recognize. A non- 863 critical extension may be ignored if it is not recognized. The 864 following presents recommended extensions used within Internet 865 certificates and standard locations for information. Communities may 866 elect to use additional extensions; however, caution should be 867 exercised in adopting any critical extensions in certificates which 868 might be used in a general context. 870 Each extension includes an object identifier and an ASN.1 structure. 871 When an extension appears in a certificate, the object identifier 872 appears as the field extnID and the corresponding ASN.1 encoded 873 structure is the value of the octet string extnValue. Only one 874 instance of a particular extension may appear in a particular 875 certificate. For example, a certificate may contain only one 876 authority key identifier extension (4.2.1.1). An extension may also 877 include the optional boolean critical; critical's default value is 878 FALSE. The text for each extension specifies the acceptable values 879 for the critical field. 881 Conforming CAs are required to support the basic Constraints 882 extension (Section 4.2.1.10), the key usage extension (4.2.1.3) and 883 certificate policies extension (4.2.1.5). If the CA issues 884 certificates with an empty sequence for the subject field, the CA 885 must support the subjectAltName extension. If the CA issues 886 certificates with an empty sequence for the issuer field, the CA must 887 support the issuerAltName extension. Support for the remaining 888 extensions is optional. Conforming CAs may support extensions that 889 are not identified within this specification; certificate issuers are 890 cautioned that marking such extensions as critical may inhibit 891 interoperability. 893 At a minimum, applications conforming to this profile shall recognize 894 extensions which shall or may be critical. These extensions are: key 895 usage (4.2.1.3), certificate policies (4.2.1.5), the alternative 896 subject name (4.2.1.7), issuer alternative name (4.2.1.8), basic 897 constraints (4.2.1.10), name constraints (4.2.1.11), policy 898 constraints (4.2.1.12), and extended key usage (4.2.1.14). 900 In addition, this profile recommends support for key identifiers 901 (4.2.1.1 and 4.2.1.2), CRL distribution points (4.2.1.13), and 902 authority information access (4.2.2.1). 904 4.2.1 Standard Extensions 906 This section identifies standard certificate extensions defined in 907 [X.509-AM] for use in the Internet Public Key Infrastructure. Each 908 extension is associated with an object identifier defined in [X.509- 909 AM]. These object identifiers are members of the 910 certificateExtension arc, which is defined by the following: 912 certificateExtension OBJECT IDENTIFIER ::= 913 {joint-iso-ccitt(2) ds(5) 29} 914 id-ce OBJECT IDENTIFIER ::= certificateExtension 916 4.2.1.1 Authority Key Identifier 918 The authority key identifier extension provides a means of 919 identifying the particular public key used to sign a certificate. 920 This extension would be used where an issuer has multiple signing 921 keys (either due to multiple concurrent key pairs or due to 922 changeover). In general, this extension should be included in 923 certificates. 925 The identification can be based on either the key identifier (the 926 subject key identifier in the issuer's certificate) or on the issuer 927 name and serial number. The key identifier method is recommended in 928 this profile. Conforming CAs that generate this extension shall 929 include or omit both authorityCertIssuer and 930 authorityCertSerialNumber. If authorityCertIssuer and 931 authorityCertSerialNumber are omitted, the keyIdentifier field shall 932 be present. 934 This extension shall not be marked critical. 936 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } 938 AuthorityKeyIdentifier ::= SEQUENCE { 939 keyIdentifier [0] KeyIdentifier OPTIONAL, 940 authorityCertIssuer [1] GeneralNames OPTIONAL, 941 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL 942 } 944 KeyIdentifier ::= OCTET STRING 946 4.2.1.2 Subject Key Identifier 948 The subject key identifier extension provides a means of identifying 949 the particular public key used in an application. Where a reference 950 to a public key identifier is needed (as with an Authority Key 951 Identifier) and one is not included in the associated certificate, a 952 SHA-1 hash of the subject public key shall be used. The hash shall 953 be calculated over the value (excluding tag and length) of the 954 subject public key field in the certificate. This extension should 955 be marked non-critical. 957 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } 959 SubjectKeyIdentifier ::= KeyIdentifier 961 4.2.1.3 Key Usage 963 The key usage extension defines the purpose (e.g., encipherment, 964 signature, certificate signing) of the key contained in the 965 certificate. The usage restriction might be employed when a key that 966 could be used for more than one operation is to be restricted. For 967 example, when an RSA key should be used only for signing, the 968 digitalSignature and nonRepudiation bits would be asserted. Likewise, 969 when an RSA key should be used only for key management, the 970 keyEncipherment bit would be asserted. The profile recommends that 971 when used, this be marked as a critical extension. 973 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } 975 KeyUsage ::= BIT STRING { 976 digitalSignature (0), 977 nonRepudiation (1), 978 keyEncipherment (2), 979 dataEncipherment (3), 980 keyAgreement (4), 981 keyCertSign (5), 982 cRLSign (6), 983 encipherOnly (7), 984 decipherOnly (8) } 986 Bits in the KeyUsage type are used as follows: 988 The digitalSignature bit is asserted when the subject public key 989 is used to verifying digital signatures that have purposes other 990 than non-repudiation, certificate signature, and CRL signature. 991 For example, The digitalSignature bit is asserted when the subject 992 public key is used to provide authentication. 994 The nonRepudiation bit is asserted when the subject public key is 995 used to verifying digital signatures used to provide a non- 996 repudiation service which protects against the signing entity 997 falsely denying some action, excluding certificate or CRL signing. 999 The keyEncipherment bit is asserted when the subject public key is 1000 used for key transport. For example, when an RSA key is to be 1001 used exclusively for key management, then this bit must asserted. 1003 The dataEncipherment bit is asserted when the subject public key 1004 is used for enciphering user data, other than cryptographic keys. 1006 The keyAgreement bit is asserted when the subject public key is 1007 used for key agreement. For example, when a Diffie-Hellman key is 1008 to be used exclusively for key management, then this bit must 1009 asserted. 1011 The keyCertSign bit is asserted when the subject public key is 1012 used for verifying a signature on certificates. This bit may only 1013 be asserted in CA certificates. 1015 The cRLSign bit is asserted when the subject public key is used 1016 for verifying a signature on CRLs. This bit may only be asserted 1017 in CA certificates. 1019 When the encipherOnly bit is asserted and the keyAgreement bit is 1020 also set, the subject public key may be used only for enciphering 1021 data while performing key agreement. The meaning of the 1022 encipherOnly bit is undefined in the absence of the keyAgreement 1023 bit. 1025 When the decipherOnly bit is asserted and the keyAgreement bit is 1026 also set, the subject public key may be used only for deciphering 1027 data while performing key agreement. The meaning of the 1028 decipherOnly bit is undefined in the absence of the keyAgreement 1029 bit. 1031 This profile does not restrict the combinations the bits that may 1032 be set in an instantiation of the keyUsage extension. However, 1033 appropriate values for keyUsage extensions for particular 1034 algorithms are specifed in section 7.3. 1036 4.2.1.4 Private Key Usage Period 1038 The private key usage period extension allows the certificate issuer 1039 to specify a different validity period for the private key than the 1040 certificate. This extension is intended for use with digital 1041 signature keys. This extension consists of two optional components 1042 notBefore and notAfter. The private key associated with the 1043 certificate should not be used to sign objects before or after the 1044 times specified by the two components, respectively. CAs conforming 1045 to this profile shall not generate certificates with private key 1046 usage period extensions unless at least one of the two components is 1047 present. 1049 This profile recommends against the use of this extension. CAs 1050 conforming to this profile shall not generate certificates with 1051 critical private key usage period extensions. Where used, notBefore 1052 and notAfter are represented as GeneralizedTime and shall be 1053 specified and interpreted as defined in Section 4.1.2.5.2. 1055 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } 1057 PrivateKeyUsagePeriod ::= SEQUENCE { 1058 notBefore [0] GeneralizedTime OPTIONAL, 1059 notAfter [1] GeneralizedTime OPTIONAL } 1061 4.2.1.5 Certificate Policies 1063 The certificate policies extension contains a sequence of one or more 1064 policy information terms, each of which consists of an object 1065 identifier (OID) and optional qualifiers. These policy information 1066 terms indicate the policy under which the certificate has been issued 1067 and the purposes for which the certificate may be used. This profile 1068 strongly recommends that a simple OID be present in this field. 1069 Optional qualifiers which may be present are expected to provide 1070 information about obtaining CA rules, not change the definition of 1071 the policy. 1073 Applications with specific policy requirements are expected to have a 1074 list of those policies which they will accept and to compare the 1075 policy OIDs in the certificate to that list. If this extension is 1076 critical, the path validation software must be able to interpret this 1077 extension, or must reject the certificate. (Applications without 1078 specific policy requirements are not required to list acceptable 1079 policies, and may accept any valid certificate regardless of policy 1080 even if the extension is marked critical.) 1082 This specification defines two policy qualifiers types for use by 1083 certificate policy writers and certificate issuers at their own 1084 discretion. The qualifier types are the CPS Pointer qualifier, and 1085 the User Notice qualifier. 1087 The CPS Pointer qualifier contains a pointer to a Certification 1088 Practice Statement (CPS) published by the CA. The pointer is in the 1089 form of a URI. 1091 User notice is intended for display to a relying party when a 1092 certificate is used. The application software should display all 1093 user notices in all certificates of the certification path used, 1094 except that if a notice is duplicated only one copy need be 1095 displayed. It is recommended that only the lowest-level certificate 1096 issued by one organization in a certification path contain a user 1097 notice. 1099 The user notice has two optional fields: the noticeRef field and the 1100 explicitText field. 1102 The noticeRef field, if used, names an organization and 1103 identifies, by number, a particular textual statement prepared by 1104 that organization. For example, it might identify the 1105 organization "CertsRUs" and notice number 1. In a typical 1106 implementation, the application software will have a notice file 1107 containing the current set of notices for CertsRUs; the 1108 application will extract the notice text from the file and display 1109 it. Messages may be multilingual, allowing the software to select 1110 the particular language message for its own environment. 1112 An explicitText field includes the textual statement directly in 1113 the certificate. The explicitText field is a string with a 1114 maximum size of 200 characters. 1116 If both the noticeRef and explicitText options are included in the 1117 one qualifier and if the application software can locate the notice 1118 text indicated by the noticeRef option then that text should be 1119 displayed; otherwise, the explicitText string should be displayed. 1121 id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } 1123 certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 1125 PolicyInformation ::= SEQUENCE { 1126 policyIdentifier CertPolicyId, 1127 policyQualifiers SEQUENCE SIZE (1..MAX) OF 1128 PolicyQualifierInfo OPTIONAL } 1130 CertPolicyId ::= OBJECT IDENTIFIER 1132 PolicyQualifierInfo ::= SEQUENCE { 1133 policyQualifierId PolicyQualifierId, 1134 qualifier ANY DEFINED BY policyQualifierId } 1136 -- policyQualifierIds for Internet policy qualifiers 1138 id-qt ::= { id-pkix 2 } -- pkix arc for qualifier types 1139 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 1140 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 1142 PolicyQualifierId ::= 1143 OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) 1145 Qualifier ::= CHOICE { 1146 cPSuri CPSuri, 1147 userNotice UserNotice } 1149 CPSuri ::= IA5String 1151 UserNotice ::= SEQUENCE { 1152 noticeRef NoticeReference OPTIONAL, 1153 explicitText DisplayText OPTIONAL} 1155 NoticeReference ::= SEQUENCE { 1156 organization IA5String, 1157 noticeNumbers SEQUENCE OF INTEGER } 1159 DisplayText ::= CHOICE { 1160 visibleString VisibleString, 1161 bmpString BMPString } 1163 4.2.1.6 Policy Mappings 1165 This extension is used in CA certificates. It lists one or more 1166 pairs of object identifiers; each pair includes an issuerDomainPolicy 1167 and a subjectDomainPolicy. The pairing indicates the issuing CA 1168 considers its issuerDomainPolicy equivalent to the subject CA's 1169 subjectDomainPolicy. 1171 The issuing CA's users may accept an issuerDomainPolicy for certain 1172 applications. The policy mapping tells the issuing CA's users which 1173 policies associated with the subject CA are comparable to the policy 1174 they accept. 1176 This extension may be supported by CAs and/or applications, and it is 1177 always non-critical. 1179 id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } 1181 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 1182 issuerDomainPolicy CertPolicyId, 1183 subjectDomainPolicy CertPolicyId } 1185 4.2.1.7 Subject Alternative Name 1187 The subject alternative names extension allows additional identities 1188 to be bound to the subject of the certificate. Defined options 1189 include an rfc822 name (electronic mail address), a DNS name, an IP 1190 address, and a URI. Other options exist, including completely local 1191 definitions. Multiple instances of a name and multiple name forms 1192 may be included. Whenever such identities are to be bound into a 1193 certificate, the subject alternative name (or issuer alternative 1194 name) extension shall be used. (Note: a form of such an identifier 1195 may also be present in the subject distinguished name; however, the 1196 alternative name extension is the preferred location for finding such 1197 information.) 1199 Further, if the only subject identity included in the certificate is 1200 an alternative name form (e.g., an electronic mail address), then the 1201 subject distinguished name shall be empty (an empty sequence), and 1202 the subjectAltName extension shall be present. If the subject field 1203 contains an empty sequence, the subjectAltName extension shall be 1204 marked critical. 1206 Where the subjectAltName extension contains a dNSName, this name may 1207 contain the wildcard character. An "*" is the wildcard character. 1208 Where a dNSName includes a wildcard, the subject of this certificate 1209 is a subnet or a collection of hosts. Examples include *.bar.com and 1210 www*.bar.com. 1212 Where the subjectAltName extension contains an rfc822Name, this name 1213 may also include the wildcard character. Use of the wildcard is 1214 limited to the host name. 1216 Where the subjectAltName extension contains a 1217 uniformResourceIdentifier, the URI is a pointer to a sequence of 1218 certificates issued by this CA (and optionally other CAs) to this 1219 subject. The URI may not contain the wildcard character in the host 1220 name. 1222 The URI must be an absolute, not relative, pathname and must specify 1223 the host. This specification recognizes the following values for the 1224 URI scheme: ftp, http, ldap, and mailto. The mailto scheme 1225 indicates that mail sent to the specified address will generate an 1226 electronic mail response (to the sender) containing the subject's 1227 certificates. No message is required. If the URI scheme is ftp, 1228 then the information is available through anonymous ftp. If the URI 1229 scheme is http or ldap, then the information may be retrieved using 1230 that protocol. 1232 (If the URI specifies any other scheme, contains a relative pathname, 1233 or omits the host, the semantics are not defined by this 1234 specification.) 1236 When the subjectAltName extension contains a iPAddress, the address 1237 shall be stored in the octet string in "network byte order," as 1238 specified in RFC791. The least significant bit (LSB) of each octet is 1239 the LSB of the corresponding byte in the network address. For IP 1240 Version 4, as specified in RFC 791, the octet string must contain 1241 exactly four octets. For IP Version 6, as specified in RFC 1883, the 1242 octet string must contain exactly sixteen octets. 1244 Alternative names may be constrained in the same manner as subject 1245 distinguished names using the name constraints extension as described 1246 in section 4.2.1.11. 1248 If the subjectAltName extension is present, the sequence must contain 1249 at least one entry. Unlike the subject field, conforming CAs shall 1250 not issue certificates with subjectAltNames containing empty 1251 GeneralName fields. For example, an rfc822Name is represented as an 1252 IA5String. While an empty string is a valid IA5String, such an 1253 rfc822Name is not permitted by this profile. The behavior of clients 1254 that encounter such a certificate when processing a certificication 1255 path is not defined by this profile. 1257 id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } 1259 SubjectAltName ::= GeneralNames 1261 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 1263 GeneralName ::= CHOICE { 1264 otherName [0] OtherName, 1265 rfc822Name [1] IA5String, 1266 dNSName [2] IA5String, 1267 x400Address [3] ORAddress, 1268 directoryName [4] Name, 1269 ediPartyName [5] EDIPartyName, 1270 uniformResourceIdentifier [6] IA5String, 1271 iPAddress [7] OCTET STRING, 1272 registeredID [8] OBJECT IDENTIFIER} 1274 OtherName ::= SEQUENCE { 1275 type-id OBJECT IDENTIFIER, 1276 value [0] EXPLICIT ANY DEFINED BY type-id } 1278 EDIPartyName ::= SEQUENCE { 1279 nameAssigner [0] DirectoryString OPTIONAL, 1280 partyName [1] DirectoryString } 1282 4.2.1.8 Issuer Alternative Name 1284 As with 4.2.1.7, this extension is used to associate Internet style 1285 identities with the certificate issuer. If the only issuer identity 1286 included in the certificate is an alternative name form (e.g., an 1287 electronic mail address), then the issuer distinguished name shall be 1288 empty (an empty sequence), and the issuerAltName extension shall be 1289 present. If the subject field contains an empty sequence, the 1290 issuerAltName extension shall be marked critical. 1292 Where the issuerAltName extension contains a URI, the following 1293 semantics shall be assumed: the URI is a pointer to an ASN.1 sequence 1294 of certificates issued to this CA (and optionally other CAs). The 1295 expected values for the URI are those defined in 4.2.1.7. Processing 1296 rules for other values are not defined by this specification. 1298 Where the issuerAltName extension contains a dNSName, rfc822Name, or 1299 a URI, wildcard characters are not permitted. 1301 id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } 1303 IssuerAltName ::= GeneralNames 1305 4.2.1.9 Subject Directory Attributes 1307 The subject directory attributes extension is not recommended as an 1308 essential part of this profile, but it may be used in local 1309 environments. This extension is always non-critical. 1311 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } 1313 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute 1315 4.2.1.10 Basic Constraints 1317 The basic constraints extension identifies whether the subject of the 1318 certificate is a CA and how deep a certification path may exist 1319 through that CA. 1321 The pathLenConstraint field is meaningful only if cA is set to TRUE. 1322 In this case, it gives the maximum number of CA certificates that may 1323 follow this certificate in a certification path. A value of zero 1324 indicates that only an end-entity certificate may follow in the path. 1325 Where it appears, the pathLenConstraint field must be greater than or 1326 equal to zero. Where pathLenConstraint does not appear, there is no 1327 limit to the allowed length of the certification path. 1329 This profile requires the use of this extension, and it shall always 1330 be critical for CA certificates. 1332 id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } 1334 BasicConstraints ::= SEQUENCE { 1335 cA BOOLEAN DEFAULT FALSE, 1336 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 1338 4.2.1.11 Name Constraints 1340 The name constraints extension, which shall be used only in a CA 1341 certificate, indicates a name space within which all subject names in 1342 subsequent certificates in a certification path must be located. 1343 Restrictions may apply to the subject distinguished name or subject 1344 alternative names. Restrictions are defined in terms of permitted or 1345 excluded name subtrees. Any name matching a restriction in the 1346 excludedSubtrees field is invalid regardless of information appearing 1347 in the permittedSubtrees. This extension must be critical. 1349 Within this profile, the minimum and maximum fields are not used with 1350 any name forms, thus minimum is always zero, and maximum is always 1351 absent. 1353 Restrictions for the rfc822, dNSName, and uri name forms are all 1354 expressed in terms of strings with wild card matching. An "*" is the 1355 wildcard character. For uris and rfc822 names, the restriction 1356 applies to the host part of the name. Examples would be foo.bar.com; 1357 www*.bar.com; *.xyz.com. 1359 Legacy implementations exist where an RFC 822 name is embeded in the 1360 subject distinguished name as a PKCS #9 e-mail attribute, which has 1361 the ASN.1 type EmailAddress. When rfc822 names are constrained, but 1362 the certificate does not include a subject alternative name, the 1363 rfc822 name constraint must be applied to PKCS #9 e-mail attributes 1364 in the subject distinguished name. The ASN.1 syntax for EmailAddress 1365 and the corresponding OID are supplied below. 1367 EmailAddress ::= IA5String 1369 pkcs-9 OBJECT IDENTIFIER ::= 1370 { iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 9 } 1372 emailAddress OBJECT IDENTIFIER ::= { pkcs-9 1 } 1374 Restrictions of the form directoryName shall be applied to the 1375 subject field in the certificate and to the subjectAltName extensions 1376 of type directoryName. Restrictions of the form x400Address shall be 1377 applied to subjectAltName extensions of type x400Address. 1379 The syntax and semantics for name constraints for otherName, 1380 ediPartyName, iPAddress, and registeredID are not defined by this 1381 specification. 1383 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } 1385 NameConstraints ::= SEQUENCE { 1386 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 1387 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 1389 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 1391 GeneralSubtree ::= SEQUENCE { 1392 base GeneralName, 1393 minimum [0] BaseDistance DEFAULT 0, 1394 maximum [1] BaseDistance OPTIONAL } 1396 BaseDistance ::= INTEGER (0..MAX) 1398 4.2.1.12 Policy Constraints 1400 The policy constraints extension can be used in certificates issued 1401 to CAs. The policy constraints extension constrains path validation 1402 in two ways. It can be used to prohibit policy mapping or require 1403 that each certificate in a path contain an acceptable policy 1404 identifier. 1406 If the inhibitPolicyMapping field is present, the value indicates the 1407 number of additional certificates that may appear in the path before 1408 policy mapping is no longer permitted. For example, a value of one 1409 indicates that policy mapping may be processed in certificates issued 1410 by the subject of this certificate, but not in additional 1411 certificates in the path. 1413 If the requireExplicitPolicy field is present, subsequent 1414 certificates must include an acceptable policy identifier. The value 1415 of requireExplicitPolicy indicates the number of additional 1416 certificates that may appear in the path before an explicit policy is 1417 required. An acceptable policy identifier is the identifier of a 1418 policy required by the user of the certification path or the 1419 identifier of a policy which has been declared equivalent through 1420 policy mapping. 1422 Conforming CAs shall not issue certificates where policy constraints 1423 is a null sequence. That is, at least one of the inhibitPolicyMapping 1424 field or the requireExplicitPolicy field must be present. The 1425 behavior of clients that encounter a null policy constraints field is 1426 not addressed in this profile. 1428 This extension may be critical or non-critical. 1430 id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } 1432 CertificatePoliciesSyntax ::= 1433 SEQUENCE SIZE (1..MAX) OF PolicyInformation 1435 PolicyConstraints ::= SEQUENCE { 1436 requireExplicitPolicy [0] SkipCerts OPTIONAL, 1437 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 1439 SkipCerts ::= INTEGER (0..MAX) 1441 4.2.1.13 CRL Distribution Points 1443 The CRL distribution points extension identifies how CRL information 1444 is obtained. The extension shall be non-critical, but this profile 1445 recommends support for this extension by CAs and applications. 1446 Further discussion of CRL management is contained in section 5. 1448 If the cRLDistributionPoints extension contains a 1449 DistributionPointName of type URI, the following semantics shall be 1450 assumed: the URI is a pointer to the current CRL for the associated 1451 reasons and will be issued by the associated cRLIssuer. The expected 1452 values for the URI are those defined in 4.2.1.7. Processing rules for 1453 other values are not defined by this specification. If the 1454 distributionPoint omits reasons, the CRL shall include revocations 1455 for all reasons. If the distributionPoint omits cRLIssuer, the CRL 1456 shall be issued by the CA that issued the certificate. 1458 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 } 1459 cRLDistributionPoints ::= { 1460 CRLDistPointsSyntax } 1462 CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 1464 DistributionPoint ::= SEQUENCE { 1465 distributionPoint [0] DistributionPointName OPTIONAL, 1466 reasons [1] ReasonFlags OPTIONAL, 1467 cRLIssuer [2] GeneralNames OPTIONAL } 1469 DistributionPointName ::= CHOICE { 1470 fullName [0] GeneralNames, 1471 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 1473 ReasonFlags ::= BIT STRING { 1474 unused (0), 1475 keyCompromise (1), 1476 cACompromise (2), 1477 affiliationChanged (3), 1478 superseded (4), 1479 cessationOfOperation (5), 1480 certificateHold (6) } 1482 4.2.1.14 Extended key usage field 1484 This field indicates one or more purposes for which the certified 1485 public key may be used, in addition to or in place of the basic 1486 purposes indicated in the key usage extension field. This field is 1487 defined as follows: 1489 id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} 1491 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 1493 KeyPurposeId ::= OBJECT IDENTIFIER 1495 Key purposes may be defined by any organization with a need. Object 1496 identifiers used to identify key purposes shall be assigned in 1497 accordance with ITU-T Rec. X.660 | ISO/IEC 9834-1. 1499 This extension may, at the option of the certificate issuer, be 1500 either critical or non-critical. 1502 If the extension is flagged critical, then the certificate shall be 1503 used only for one of the purposes indicated. 1505 If the extension is flagged non-critical, then it indicates the 1506 intended purpose or purposes of the key, and may be used in finding 1507 the correct key/certificate of an entity that has multiple 1508 keys/certificates. It is an advisory field and does not imply that 1509 usage of the key is restricted by the certification authority to the 1510 purpose indicated. (Using applications may nevertheless require that 1511 a particular purpose be indicated in order for the certificate to be 1512 acceptable to that application.) 1514 If a certificate contains both a critical key usage field and a 1515 critical extended key usage field, then both fields shall be 1516 processed independently and the certificate shall only be used for a 1517 purpose consistent with both fields. If there is no purpose 1518 consistent with both fields, then the certificate shall not be used 1519 for any purpose. 1521 The following key usage purposes are defined by this profile: 1523 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 1525 id-kp-serverAuth OBJECT IDENTIFIER ::= {id-kp 1} 1526 -- TLS Web server authentication 1527 -- Key usage bits that may be consistent: digitalSignature, 1528 -- keyEncipherment or keyAgreement 1529 -- 1530 id-kp-clientAuth OBJECT IDENTIFIER ::= {id-kp 2} 1531 -- TLS Web client authentication 1532 -- Key usage bits that may be consistent: digitalSignature and/or 1533 -- keyAgreement 1534 -- 1535 id-kp-codeSigning OBJECT IDENTIFIER ::= {id-kp 3} 1536 -- Signing of downloadable executable code 1537 -- Key usage bits that may be consistent: digitalSignature 1538 -- 1539 id-kp-emailProtection OBJECT IDENTIFIER ::= {id-kp 4} 1540 -- E-mail protection 1541 -- Key usage bits that may be consistent: digitalSignature, 1542 -- nonRepudiation, and/or (keyEncipherment 1543 -- or keyAgreement) 1544 -- 1545 id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= {id-kp 5} 1546 -- IP security end system (host or router) 1547 -- Key usage bits that may be consistent: digitalSignature and/or 1548 -- (keyEncipherment or keyAgreement) 1549 -- 1550 id-kp-ipsecTunnel OBJECT IDENTIFIER ::= {id-kp 6} 1551 -- IP security tunnel termination 1552 -- Key usage bits that may be consistent: digitalSignature and/or 1553 -- (keyEncipherment or keyAgreement) 1554 -- 1555 id-kp-ipsecUser OBJECT IDENTIFIER ::= {id-kp 7} 1556 -- IP security user 1557 -- Key usage bits that may be consistent: digitalSignature and/or 1558 -- (keyEncipherment or keyAgreement) 1559 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 1560 -- Binding the hash of an object to a time from an agreed-upon time 1561 -- source. Key usage bits that may be consistent: digitalSignature, 1562 -- nonRepudiation 1564 4.2.2 Private Internet Extensions 1566 This section defines one new extension for use in the Internet Public 1567 Key Infrastructure. This extension may be used to direct 1568 applications to identify an on-line validation service supporting the 1569 issuing CA. As the information may be available in multiple forms, 1570 each extension is a sequence of IA5String values, each of which 1571 represents a URI. The URI implicitly specifies the location and 1572 format of the information and the method for obtaining the 1573 information. 1575 An object identifier is defined for the private extension. The 1576 object identifier associated with the private extension is defined 1577 under the arc id-pe within the id-pkix name space. Any future 1578 extensions defined for the Internet PKI will also be defined uder the 1579 arc id-pe. 1581 id-pkix OBJECT IDENTIFIER ::= 1582 { iso(1) identified-organization(3) dod(6) internet(1) 1583 security(5) mechanisms(5) pkix(7) } 1585 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 1587 4.2.2.1 Authority Information Access 1589 The authority information access extension indicates how to access CA 1590 information and services for the issuer of the certificate in which 1591 the extension appears. Information and services may include on-line 1592 validation services and CA policy data. (The location of CRLs is not 1593 specified in this extension; that information is provided by the 1594 cRLDistributionPoints extension.) This extension may be included in 1595 subject or CA certificates, and it is always non-critical. 1597 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 1599 AuthorityInfoAccessSyntax ::= 1600 SEQUENCE SIZE (1..MAX) OF AccessDescription 1602 AccessDescription ::= SEQUENCE { 1603 accessMethod OBJECT IDENTIFIER, 1604 accessLocation GeneralName } 1606 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 1608 id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } 1610 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 1612 Each entry in the sequence AuthorityInfoAccessSyntax describes the 1613 format and location of additional information about the CA who issued 1614 the certificate in which this extension appears. 1616 This profile defines an object identifier for the On-line Certificate 1617 Status Protocol (OCSP) that will be defined in [PKIXOCSP]. When id- 1618 ad-ocsp appears as accessMethod, the accessLocation field describes 1619 the on-line status server and the access protocol to obtain current 1620 certificate status information for the certificate containing this 1621 extension. 1623 This profile defines an object identifier to obtain a description of 1624 the CAs that have issued certificates superior to the CA that issued 1625 the certificate containing this extension. The referenced CA Issuers 1626 description is intended to aid certificate users in the selection of 1627 a certification path that terminates at a point trusted by the 1628 certificate user. The syntax of the referenced CA Issuers 1629 description will be defined in [PKIXOCSP]. When id-ad-caIssuers 1630 appears as accessMethod, the accessLocation field describes the 1631 referenced description server and the access protocol to obtain 1632 referenced description. 1634 Additional access descriptors will likely be defined in the future. 1636 The authorityInfoAccess extension may be included in a PKCS 7 1637 encapsulation as an X.501 ATTRIBUTE. This attribute can then be used 1638 to locate certificates automatically rather than include the 1639 certificates directly. The intended effect is to reduce the size of 1640 the encapsulated message or object. 1642 PKCS 9 identifies attributes for inclusion in PKCS 7, referencing 1643 X.520 standard attributes and defining additional attributes unique 1644 to PKCS 9. The attributes defined in X.520 are based on the 1645 definition of ATTRIBUTE in ITU-T X.501 | ISO/IEC 9594-2. 1647 The following syntax defines authorityInfoAccess as an ATTRIBUTE 1648 suitable for inclusion in a PKCS #7 message: 1650 authorityInfoAccess ATTRIBUTE ::= { 1651 WITH SYNTAX authorityInfoAccessSyntax, 1652 ID id-pe-authorityInfoAccess } 1654 Other parts of the PKIX specifications [PKIXOCSP] [PKIXLDAP] 1655 establish requirements on certificate retrieval mechanisms. It is 1656 expected that applications using the URI form of the authorityInfo 1657 field for such a purpose will: 1659 1. Prepend a suitable HTTP retrieval primitive to the URL (e.g. 1660 "GET"). 1662 2. Append a filename to the URL. 1664 3. Use the result to retrieve a file containing the requested 1665 certificate. 1667 4. Use the authorityInfoAccess extension in that and subsequent 1668 certificates to complete a certificate path. 1670 The filename will be formed as the IA5string representation of 1671 SHA1(Issuer DN | certificate serial number) concatenated with ".cer." 1672 The IA5String representation will display the SHA1 result as a 1673 hexidecimal number using digits and the lowercase letters 'a' through 1674 'f.' The SignerInfo syntax of PKCS 7 provides the necessary 1675 information as issuerAndSerialNumber. 1677 The specified file will contain a single DER encoded certficate. 1679 5 CRL and CRL Extensions Profile 1681 As described above, one goal of this X.509 v2 CRL profile is to 1682 foster the creation of an interoperable and reusable Internet PKI. 1683 To achieve this goal, guidelines for the use of extensions are 1684 specified, and some assumptions are made about the nature of 1685 information included in the CRL. 1687 CRLs may be used in a wide range of applications and environments 1688 covering a broad spectrum of interoperability goals and an even 1689 broader spectrum of operational and assurance requirements. This 1690 profile establishes a common baseline for generic applications 1691 requiring broad interoperability. Emphasis is placed on support for 1692 X.509 v2 CRLs. The profile defines a baseline set of information 1693 that can be expected in every CRL. Also, the profile defines common 1694 locations within the CRL for frequently used attributes, and common 1695 representations for these attributes. 1697 This profile does not define any private Internet CRL extensions or 1698 CRL entry extensions. 1700 Environments with additional or special purpose requirements may 1701 build on this profile or may replace it. 1703 Conforming CAs are not required to issue CRLs if other revocation or 1704 status mechanisms are provided. Conforming CAs that issue CRLs are 1705 required to issue version 2 CRLs, and must include the date by which 1706 the next CRL will be issued in the nextUpdate field (Section 1707 5.1.2.5). Conforming applications are required to process version 1 1708 and 2 CRLs. 1710 5.1 CRL Fields 1712 The X.509 v2 CRL syntax is as follows. For signature calculation, 1713 the data that is to be signed is ASN.1 DER encoded. ASN.1 DER 1714 encoding is a tag, length, value encoding system for each element. 1716 CertificateList ::= SEQUENCE { 1717 tbsCertList TBSCertList, 1718 signatureAlgorithm AlgorithmIdentifier, 1719 signature BIT STRING } 1721 TBSCertList ::= SEQUENCE { 1722 version Version OPTIONAL, 1723 -- if present, must be v2 1724 signature AlgorithmIdentifier, 1725 issuer Name, 1726 thisUpdate Time, 1727 nextUpdate Time OPTIONAL, 1728 revokedCertificates SEQUENCE OF SEQUENCE { 1729 userCertificate CertificateSerialNumber, 1730 revocationDate Time, 1731 crlEntryExtensions Extensions OPTIONAL 1732 -- if present, must be v2 1733 } OPTIONAL, 1734 crlExtensions [0] EXPLICIT Extensions OPTIONAL 1735 -- if present, must be v2 1736 } 1738 -- Version, Time, CertificateSerialNumber and Extensions 1739 -- are all defined in the ASN.1 in section 4.1 1741 AlgorithmIdentifier ::= SEQUENCE { 1742 algorithm OBJECT IDENTIFIER, 1743 parameters ANY DEFINED BY algorithm OPTIONAL } 1744 -- contains a value of the type 1745 -- registered for use with the 1746 -- algorithm object identifier value 1748 The following items describe the proposed use of the X.509 v2 CRL in 1749 the Internet PKI. 1751 5.1.1 CertificateList Fields 1753 The CertificateList is a SEQUENCE of three required fields. The 1754 fields are are described in detail in the following subsections 1756 5.1.1.1 tbsCertList 1758 The first field in the sequence is the tbsCertList. This field is 1759 itself a sequence containing the name of the issuer, issue date, 1760 issue date of the next list, the list of revoked certificates, and 1761 optional CRL extensions. Further, each entry on the revoked 1762 certificate list is defined by a sequence of user certificate serial 1763 number, revocation date, and optional CRL entry extensions. 1765 5.1.1.2 signatureAlgorithm 1767 The signatureAlgorithm field contains the algorithm identifier for 1768 the algorithm used by the CA to sign the CertificateList. Section 1769 7.2 lists the supported signature algorithms. Conforming CAs shall 1770 use the algorithm identifiers presented in Section 7.2 when signing 1771 with a supported signature algorithm. 1773 5.1.1.3 signature 1775 The signature field contains a digital signature computed upon the 1776 ASN.1 DER encoded TBSCertList. The ASN.1 DER encoded TBSCertList is 1777 used as the input to a one-way hash function. The one-way hash 1778 function output value is encrypted (e.g., using RSA Encryption) to 1779 form the signed quantity. This signature value is then ASN.1 encoded 1780 as a BIT STRING and included in the CRL's signature field. The 1781 details of this process are specified for each of the supported 1782 algorithms in Section 7.2. 1784 5.1.2 Certificate List "To Be Signed" 1786 The certificate list to be signed, or tBSCertList, is a SEQUENCE of 1787 required and optional fields. The required fields identify the CRL 1788 issuer, the algorithm used to sign the CRL, the date and time the CRL 1789 was issued, and the date and time by which the CA will issue the next 1790 CRL. 1792 Optional fields include lists of revoked certificates and CRL 1793 extensions. The revoked certificate list is optional to support the 1794 special case where a CA has not revoked any unexpired certificates it 1795 has issued. It is expected that nearly all CRLs issued in the 1796 Internet PKI will contain one or more lists of revoked certificates. 1797 Similarly, the profile requires conforming CAs to use the CRL 1798 extension cRLNumber in all CRLs issued. 1800 5.1.2.1 Version 1802 This optional field describes the version of the encoded CRL. When 1803 extensions are used, as expected in this profile, this field shall be 1804 present and shall specify version 2 (the integer value is 1). If 1805 neither CRL extensions nor CRL entry extensions are present, version 1806 1 CRLs are recommended. In this case, the field shall be ommitted. 1808 5.1.2.2 Signature 1810 This field contains the algorithm identifier for the algorithm used 1811 to sign the CRL. Section 7.2 lists OIDs for the most popular 1812 signature algorithms used in the Internet PKI. 1814 5.1.2.3 Issuer Name 1816 The issuer name identifies the entity who has signed (and issued the 1817 CRL). The issuer identity may be carried in the issuer name field 1818 and/or the issuerAltName extension. If identity information is 1819 present only in the issuerAltName extension, then the issuer name may 1820 be an empty sequence and the issuerAltName extension must be 1821 critical. 1823 Where it is non-null, the issuer name field shall contain an X.500 1824 distinguished name (DN). The issuer name field is defined as the 1825 X.501 type Name, and shall follow the encoding rules for the issuer 1826 name field in the certificate (see 4.1.2.4). 1828 5.1.2.4 This Update 1830 This field indicates the issue date of this CRL. ThisUpdate may be 1831 encoded as UTCTime or GeneralizedTime. 1833 CAs conforming to this profile that issue CRLs shall encode 1834 thisUpdate as UTCTime for dates through the year 2049. CAs conforming 1835 to this profile that issue CRLs shall encode thisUpdate as 1836 GeneralizedTime for dates in the year 2050 or later. 1838 Where encoded as UTCTime, thisUpdate shall be specified and 1839 interpreted as defined in Section 4.1.2.5.1. Where encoded as 1840 GeneralizedTime, thisUpdate shall be specified and interpreted as 1841 defined in Section 4.1.2.5.2. 1843 5.1.2.5 Next Update 1845 This field indicates the date by which the next CRL will be issued. 1846 The next CRL could be issued before the indicated date, but it will 1847 not be issued any later than the indicated date. nextUpdate may be 1848 encoded as UTCTime or GeneralizedTime. 1850 This profile requires inclusion of nextUpdate in all CRLs issued by 1851 conforming CAs. Note that the ASN.1 syntax of TBSCertList describes 1852 this field as OPTIONAL, which is consistent with the ASN.1 structure 1853 defined in [X.509-AM]. The behavior of clients processing CRLs which 1854 omit nextUpdate is not specified by this profile. 1856 CAs conforming to this profile that issue CRLs shall encode 1857 nextUpdate as UTCTime for dates through the year 2049. CAs conforming 1858 to this profile that issue CRLs shall encode nextUpdate as 1859 GeneralizedTime for dates in the year 2050 or later. 1861 Where encoded as UTCTime, nextUpdate shall be specified and 1862 interpreted as defined in Section 4.1.2.5.1. Where encoded as 1863 GeneralizedTime, nextUpdate shall be specified and interpreted as 1864 defined in Section 4.1.2.5.2. 1866 5.1.2.6 Revoked Certificates 1868 Revoked certificates are listed. The revoked certificates are named 1869 by their serial numbers. Certificates are uniquely identified by the 1870 combination of the issuer name or issuer alternative name along with 1871 the user certificate serial number. The date on which the revocation 1872 occurred is specified. The time for revocationDate shall be 1873 expressed as described in section 5.1.2.4. Additional information may 1874 be supplied in CRL entry extensions; CRL entry extensions are 1875 discussed in section 5.3. 1877 5.1.2.7 Extensions 1879 This field may only appear if the version number is 2 (see 5.1.2.1). 1880 If present, this field is a SEQUENCE of one or more CRL extensions. 1881 CRL extensions are discussed in section 5.2. 1883 5.2 CRL Extensions 1885 The extensions defined by ANSI X9 and ISO for X.509 v2 CRLs [X.509- 1886 AM] [X9.55] provide methods for associating additional attributes 1887 with CRLs. The X.509 v2 CRL format also allows communities to define 1888 private extensions to carry information unique to those communities. 1889 Each extension in a CRL may be designated as critical or non- 1890 critical. A CRL validation must fail if it encounters an critical 1891 extension which it does not know how to process. However, an 1892 unrecognized non-critical extension may be ignored. The following 1893 presents those extensions used within Internet CRLs. Communities may 1894 elect to include extensions in CRLs which are not defined in this 1895 specification. However, caution should be exercised in adopting any 1896 critical extensions in CRLs which might be used in a general context. 1898 Conforming CAs that issue CRLs are required to support the CRL number 1899 extension (5.2.3), and include it in all CRLs issued. Conforming 1900 applications are required to support the critical and optionally 1901 critical CRL extensions issuer alternative name (5.2.2), issuing 1902 distribution point (5.2.4) and delta CRL indicator (5.2.5). 1904 5.2.1 Authority Key Identifier 1906 The authority key identifier extension provides a means of 1907 identifying the particular public key used to sign a CRL. The 1908 identification can be based on either the key identifier (the subject 1909 key identifier in the CRL signer's certificate) or on the issuer name 1910 and serial number. The key identifier method is recommended in this 1911 profile. This extension would be used where an issuer has multiple 1912 signing keys, either due to multiple concurrent key pairs or due to 1913 changeover. In general, this non-critical extension should be 1914 included in certificates. 1916 The syntax for this CRL extension is defined in Section 4.2.1.1. 1918 5.2.2 Issuer Alternative Name 1920 The issuer alternative names extension allows additional identities 1921 to be associated with the issuer of the CRL. Defined options include 1922 an rfc822 name (electronic mail address), a DNS name, an IP address, 1923 and a URI. Multiple instances of a name and multiple name forms may 1924 be included. Whenever such identities are used, the issuer 1925 alternative name extension shall be used. 1927 Further, if the only issuer identity included in the CRL is an 1928 alternative name form (e.g., an electronic mail address), then the 1929 issuer distinguished name should be empty (an empty sequence), the 1930 issuerAltName extension should be used, and the issuerAltName 1931 extension must be marked critical. 1933 The object identifier and syntax for this CRL extension are defined 1934 in Section 4.2.1.8. 1936 5.2.3 CRL Number 1938 The CRL number is a non-critical CRL extension which conveys a 1939 monotonically increasing sequence number for each CRL issued by a 1940 given CA through a specific CA X.500 Directory entry or CRL 1941 distribution point. This extension allows users to easily determine 1942 when a particular CRL supersedes another CRL. CAs conforming to this 1943 profile shall include this extension in all CRLs. 1945 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 1947 cRLNumber ::= INTEGER (0..MAX) 1949 5.2.4 Issuing Distribution Point 1951 The issuing distribution point is a critical CRL extension that 1952 identifies the CRL distribution point for a particular CRL, and it 1953 indicates whether the CRL covers revocation for end entity 1954 certificates only, CA certificates only, or a limitied set of reason 1955 codes. Since this extension is critical, all certificate users must 1956 be prepared to receive CRLs with this extension. 1958 The CRL is signed using the CA's private key. CRL Distribution 1959 Points do not have their own key pairs. If the CRL is stored in the 1960 X.500 Directory, it is stored in the Directory entry corresponding to 1961 the CRL distribution point, which may be different than the Directory 1962 entry of the CA. 1964 CAs may use CRL distribution points to partition the CRL on the basis 1965 of compromise and routine revocation. In this case, the revocations 1966 with reason code keyCompromise (1) shall appear in one distribution 1967 point, and the revocations with other reason codes shall appear in 1968 another distribution point. The reason codes associated with a 1969 distribution point must be specified in onlySomeReasons. If 1970 onlySomeReasons does not appear, the distribution point must contain 1971 revocations for all reason codes. 1973 Where the issuingDistributionPoint extension contains a URL, the 1974 following semantics shall be assumed: the object is a pointer to the 1975 most current CRL issued by this CA. The URI schemes ftp, http, 1976 mailto [RFC1738] and ldap [RFC1778] are defined for this purpose. 1977 The URI must be an absolute, not relative, pathname and must specify 1978 the host. 1980 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } 1982 issuingDistributionPoint ::= SEQUENCE { 1983 distributionPoint [0] DistributionPointName OPTIONAL, 1984 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 1985 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 1986 onlySomeReasons [3] ReasonFlags OPTIONAL, 1987 indirectCRL [4] BOOLEAN DEFAULT FALSE } 1989 5.2.5 Delta CRL Indicator 1991 The delta CRL indicator is a critical CRL extension that identifies a 1992 delta-CRL. The use of delta-CRLs can significantly improve 1993 processing time for applications which store revocation information 1994 in a format other than the CRL structure. This allows changes to be 1995 added to the local database while ignoring unchanged information that 1996 is already in the local database. 1998 When a delta-CRL is issued, the CAs shall also issue a complete CRL. 2000 The value of BaseCRLNumber identifies the CRL number of the base CRL 2001 that was used as the starting point in the generation of this delta- 2002 CRL. The delta-CRL contains the changes between the base CRL and the 2003 current CRL issued along with the delta-CRL. It is the decision of a 2004 CA as to whether to provide delta-CRLs. Again, a delta-CRL shall not 2005 be issued without a corresponding CRL. The value of CRLNumber for 2006 both the delta-CRL and the corresponding CRL shall be identical. 2008 A CRL user constructing a locally held CRL from delta-CRLs shall 2009 consider the constructed CRL incomplete and unusable if the CRLNumber 2010 of the received delta-CRL is more that one greater that the CRLnumber 2011 of the delta-CRL last processed. 2013 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } 2015 deltaCRLIndicator ::= BaseCRLNumber 2017 BaseCRLNumber ::= CRLNumber 2019 5.2.6 Certificate Issuer 2021 This CRL entry extension identifies the certificate issuer associated 2022 with an entry in an indirect CRL, i.e. a CRL that has the indirectCRL 2023 indicator set in its issuing distribution point extension. If this 2024 extension is not present on the first entry in an indirect CRL, the 2025 certificate issuer defaults to the CRL issuer. On subsequent entries 2026 in an indirect CRL, if this extension is not present, the certificate 2027 issuer for the entry is the same as that for the preceding entry. 2028 This field is defined as follows: 2030 id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } 2031 certificateIssuer ::= GeneralNames 2033 If used by conforming CAs that issue CRLs, this extension is always 2034 critical. Conforming applications if an implementation ignored this 2035 extension it could not correctly attribute CRL entries to 2036 certificates. 2038 5.3 CRL Entry Extensions 2040 The CRL entry extensions already defined by ANSI X9 and ISO for X.509 2041 v2 CRLs [X.509-AM] [X9.55] provide methods for associating additional 2042 attributes with CRL entries. The X.509 v2 CRL format also allows 2043 communities to define private CRL entry extensions to carry 2044 information unique to those communities. Each extension in a CRL 2045 entry may be designated as critical or non-critical. A CRL 2046 validation must fail if it encounters a critical CRL entry extension 2047 which it does not know how to process. However, an unrecognized 2048 non-critical CRL entry extension may be ignored. The following 2049 presents recommended extensions used within Internet CRL entries and 2050 standard locations for information. Communities may elect to use 2051 additional CRL entry extensions; however, caution should be exercised 2052 in adopting any critical extensions in CRL entries which might be 2053 used in a general context. 2055 All CRL entry extensions are non-critical; support for these 2056 extensions is optional for conforming CAs and applications. However, 2057 CAs that issue CRLs are strongly encouraged to include reason codes 2058 (5.3.1) whenever this information is available. 2060 5.3.1 Reason Code 2062 The reasonCode is a non-critical CRL entry extension that identifies 2063 the reason for the certificate revocation. CAs are strongly 2064 encouraged to include reason codes in CRL entries; however, the 2065 reason code CRL entry extension should be absent instead of using the 2066 unspecified (0) reasonCode value. 2068 id-ce-cRLReason OBJECT IDENTIFIER ::= { id-ce 21 } 2070 -- reasonCode ::= { CRLReason } 2072 CRLReason ::= ENUMERATED { 2073 unspecified (0), 2074 keyCompromise (1), 2075 cACompromise (2), 2076 affiliationChanged (3), 2077 superseded (4), 2078 cessationOfOperation (5), 2079 certificateHold (6), 2080 removeFromCRL (8) } 2082 5.3.2 Hold Instruction Code 2084 The hold instruction code is a non-critical CRL entry extension that 2085 provides a registered instruction identifier which indicates the 2086 action to be taken after encountering a certificate that has been 2087 placed on hold. 2089 id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } 2091 holdInstructionCode ::= OBJECT IDENTIFIER 2093 The following instruction codes have been defined. Conforming 2094 applications that process this extension shall recognize the 2095 following instruction codes. 2097 holdInstruction OBJECT IDENTIFIER ::= 2098 { iso(1) member-body(2) us(840) x9-57(10040) 2 } 2100 id-holdinstruction-none OBJECT IDENTIFIER ::= {holdInstruction 1} 2101 id-holdinstruction-callissuer 2102 OBJECT IDENTIFIER ::= {holdInstruction 2} 2103 id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3} 2105 Conforming applications which encounter a id-holdinstruction- 2106 callissuer must call the certificate issuer or reject the 2107 certificate. Conforming applications which encounter a id- 2108 holdinstruction-reject ID shall reject the transaction. id- 2109 holdinstruction-none is semantically equivalent to the absence of a 2110 holdInstructionCode. Its use is strongly deprecated for the Internet 2111 PKI. 2113 5.3.3 Invalidity Date 2115 The invalidity date is a non-critical CRL entry extension that 2116 provides the date on which it is known or suspected that the private 2117 key was compromised or that the certificate otherwise became invalid. 2118 This date may be earlier than the revocation date in the CRL entry, 2119 but it must be later than the issue date of the previously issued 2120 CRL. Remember that the revocation date in the CRL entry specifies 2121 the date that the CA revoked the certificate. Whenever this 2122 information is available, CAs are strongly encouraged to share it 2123 with CRL users. 2125 The GeneralizedTime values included in this field shall be expressed 2126 in Greenwich Mean Time (Zulu), and shall be specified and interpreted 2127 as defined in Section 4.1.2.5.2. 2129 id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } 2131 invalidityDate ::= GeneralizedTime 2133 6 Certificate Path Validation 2135 Certification path validation procedures for the Internet PKI are 2136 based on Section 12.4.3 of [X.509-AM]. Certification path processing 2137 verifies the binding between the subject distinguished name and 2138 subject public key. The binding is limited by constraints which are 2139 specified in the certificates which comprise the path. The basic 2140 constraints and policy constraints extensions allow the certification 2141 path processing logic to automate the decision making process. 2143 This section describes an algorithm for validating certification 2144 paths. Conforming implementations of this specification are not 2145 required to implement this algorithm, but shall be functionally 2146 equivalent to the external behaviour resulting from this procedure. 2147 Any algorithm may be used by a particular implementation so long as 2148 it derives the correct result. 2150 The following text assumes that all valid paths begin with the public 2151 key of a single "most-trusted CA". The "most-trusted CA" is a matter 2152 of policy: it could be a root CA in a hierarchical PKI; the CA that 2153 issued the verifier's own certificate(s); or any other CA in a 2154 network PKI. The path validation procedure is the same regardless of 2155 the choice of "most-trusted CA." 2157 The text assumes that this public key is contained in a "self-signed" 2158 certificate. This simplifies the description of the path processing 2159 procedure. Note that the signature on the self-signed certificate 2160 does not provide any security services. The public key it contains 2161 is trusted because of other procedures used to obtain and protect it. 2163 The goal of path validation is to verify the binding between a 2164 subject distinguished name and subject public key, as represented in 2165 the "end entity" certificate, based on the public key of the "most- 2166 trusted CA". This requires obtaining a sequence of certificates that 2167 support that binding. The procedures performed to obtain this 2168 sequence is outside the scope of this section. 2170 The following text also assumes that certificates do not use subject 2171 or unique identifier fields or private critical extensions, as 2172 recommended within this profile. However, if these components appear 2173 in certificates, they must be processed. Finally, policy qualifiers 2174 are also neglected for the sake of clarity. 2176 A certification path is a sequence of n certificates where: 2178 * for all x in {1,(n-1)}, the subject of certificate x is the 2179 issuer of certificate x+1. 2180 * certificate x=1 is the the self-signed certificate, and 2181 * certificate x=n is the end entity certificate. 2183 This section assumes the following inputs are provided to the path 2184 processing logic: 2186 (a) a certification path of length n; 2188 (b) a set of initial policy identifiers (each comprising a 2189 sequence of policy element identifiers), which identifies one or 2190 more certificate policies, any one of which would be acceptable 2191 for the purposes of certification path processing; and 2193 (c) the current date/time (if not available internally to the 2194 certification path processing module). 2196 From the inputs, the procedure intializes five state variables: 2198 (a) acceptable policy set: A set of certificate policy 2199 identifiers comprising the policy or policies recognized by the 2200 public key user together with policies deemed equivalent through 2201 policy mapping. The initial value of the acceptable policy set is 2202 the set of initial policy identifiers. 2204 (b) constrained subtrees: A set of root names defining a set of 2205 subtrees within which all subject names in subsequent certificates 2206 in the certification path shall fall. The initial value is 2207 "unbounded". 2209 (c) excluded subtrees: A set of root names defining a set of 2210 subtrees within which no subject name in subsequent certificates 2211 in the certification path may fall. The initial value is "empty". 2213 (d) explicit policy: an integer which indicates if an explicit 2214 policy identifier is required. The integer indicates the first 2215 certificate in the path where this requirement is imposed. Once 2216 set, this variable may be decreased, but may not be increased. 2217 (That is, if a certificate in the path requires explicit policy 2218 identifiers, a later certificate can not remove this requirement.) 2219 The initial value is n+1. 2221 (e) policy mapping: an integer which indicates if policy mapping 2222 is permitted. The integer indicates the last certificate on which 2223 policy mapping may be applied. Once set, this variable may be 2224 decreased, but may not be increased. (That is, if a certificate in 2225 the path specifies policy mapping is not permitted, it can not be 2226 overriden by a later certificate.) The initial value is n+1. 2228 The actions performed by the path processing software for each 2229 certificate i=1 through n are described below. The self-signed 2230 certificate is certificate i=1, the end entity certificate is i=n. 2231 The processing is performed sequentially, so that processing 2232 certificate i affects the state variables for processing certificate 2233 (i+1). Note that actions (f) through (i) are not applied to the end 2234 entity certificate (certificate n). 2236 The path processing actions to be performed are: 2238 (a) Verify the basic certificate information, including: 2240 (1) the certificate was signed using the subject public key 2241 from certificate i-1 (in the special case i=1, this step may be 2242 omitted; if not, use the subject public key from the same 2243 certificate), 2245 (2) the certificate is not expired, and (if present) the 2246 private key usage period is satisfied, 2248 (3) the certificate has not been revoked (this may be 2249 determined by obtaining current CRL, current status 2250 information, or by out-of-band mechanisms), and 2252 (4) the subject and issuer names chain correctly. (If the 2253 certificate has an empty sequence in the name field, name 2254 chaining will use the critical subjectAltNames and 2255 issuerAltNames fields.) 2257 (b) Verify that the subject name or critical subjectAltName 2258 extension is consistent with the constrained subtrees state 2259 variables; and 2261 (c) Verify that the subject name or critical subjectAltName 2262 extension is consistent with the excluded subtrees state 2263 variables. 2265 (d) Verify that policy information is consistent: 2267 (1) if the explicit policy state variable is less than or equal 2268 to i, an appropriate policy identifier must appear in the 2269 certificate; and 2270 (2) if the policy mapping variable is less than or equal to i, 2271 the policy identifier may not be mapped. 2273 (e) Recognize and process any other critical extension present in 2274 the certificate. 2276 (f) Verify that the certificate is a CA certificate (as specified 2277 in a basicConstraints extension or as verified out-of-band). 2279 (g) If permittedSubtrees is present in the certificate, set the 2280 constrained subtrees state variable to the intersection of its 2281 previous value and the value indicated in the extension field. 2283 (h) If excludedSubtrees is present in the certificate, set the 2284 excluded subtrees state variable to the union of its previous 2285 value and the value indicated in the extension field. 2287 (i) If a policy constraints extension is included in the 2288 certificate, modify the explicit policy and policy mapping state 2289 variables as follows: 2291 (1) If requireExplicitPolicy is present and has value r, the 2292 explicit policy state variable is set to the minimum of (a) its 2293 current value and (b) the sum of r and i (the current 2294 certificate in the sequence). 2296 (2) If inhibitPolicyMapping is present and has value q, the 2297 policy mapping state variable is set to the minimum of (a) its 2298 current value and (b) the sum of q and i (the current 2299 certificate in the sequence). 2301 If any one of the above checks fail, the procedure terminates, 2302 returning a failure indication and an appropriate reason. If none of 2303 the above checks fail on the end-entity certificate, the procedure 2304 terminates, returning a success indication together with the set of 2305 all policy qualifier values encountered in the set of certificates. 2307 Notes: It is possible to specify an extended version of the above 2308 certification path processing procedure which results in default 2309 behaviour identical to the rules of Privacy Enhanced Mail [RFC 1422]. 2310 In this extended version, additional inputs to the procedure are a 2311 list of one or more Policy Certification Authoritys (PCAs) names and 2312 an indicator of the position in the certification path where the PCA 2313 is expected. At the nominated PCA position, the CA name is compared 2314 against this list. If a recognized PCA name is found, then a 2315 constraint of SubordinateToCA is implicitly assumed for the remainder 2316 of the certification path and processing continues. If no valid PCA 2317 name is found, and if the certification path cannot be validated on 2318 the basis of identified policies, then the certification path is 2319 considered invalid. 2321 This procedure may also be extended by providing a set of self-signed 2322 certificates to the validation module. In this case, a valid path 2323 could begin with any one of the self-signed certificates. These 2324 self-signed certificates permit the path validation module to 2325 automatically incorporate local security policy and requirements. 2327 7 Algorithm Support 2329 This section describes cryptographic algorithms which may be used 2330 with this standard. The section describes one-way hash functions and 2331 digital signature algorithms which may be used to sign certificates 2332 and CRLs, and identifies object identifiers for public keys contained 2333 in a certificate. 2335 Conforming CAs and applications are not required to support the 2336 algorithms or algorithm identifiers described in this section. 2337 However, this profile requires conforming CAs and applications to 2338 conform when they use the algorithms identified here. 2340 7.1 One-way Hash Functions 2342 This section identifies one-way hash functions for use in the 2343 Internet PKI. One-way hash functions are also called message digest 2344 algorithms. SHA-1 is the preferred one-way hash function for the 2345 Internet PKI. However, PEM uses MD2 for certificates [RFC 1422] [RFC 2346 1423] and MD5 is used in other legacy applications. For this reason, 2347 MD2 and MD5 are included in this profile. 2349 7.1.1 MD2 One-way Hash Function 2351 MD2 was developed by Ron Rivest, but RSA Data Security has not placed 2352 the MD2 algorithm in the public domain. Rather, RSA Data Security 2353 has granted license to use MD2 for non-commercial Internet Privacy- 2354 Enhanced Mail. For this reason, MD2 may continue to be used with PEM 2355 certificates, but SHA-1 is preferred. MD2 is fully described in RFC 2356 1319 [RFC 1319]. 2358 At the Selected Areas in Cryptography '95 conference in May 1995, 2359 Rogier and Chauvaud presented an attack on MD2 that can nearly find 2360 collisions [RC95]. Collisions occur when one can find two different 2361 messages that generate the same message digest. A checksum operation 2362 in MD2 is the only remaining obstacle to the success of the attack. 2363 For this reason, the use of MD2 for new applications is discouraged. 2364 It is still reasonable to use MD2 to verify existing signatures, as 2365 the ability to find collisions in MD2 does not enable an attacker to 2366 find new messages having a previously computed hash value. 2368 << More information on the attack and its implications can be 2369 obtained from a RSA Laboratories security bulletin. These bulletins 2370 are available from . >> 2372 7.1.2 MD5 One-way Hash Function 2374 MD5 was developed by Ron Rivest in 1991. The algorithm takes as 2375 input a message of arbitrary length and produces as output a 128-bit 2376 "fingerprint" or "message digest" of the input. The MD5 message 2377 digest algorithm is specified by RFC 1321, "The MD5 Message-Digest 2378 Algorithm"[RFC1321]. 2380 Den Boer and Bosselaers [DB94] have found pseudo-collisions for MD5, 2381 but there are no other known cryptanalytic results. The use of MD5 2382 for new applications is discouraged. It is still reasonable to use 2383 MD5 to verify existing signatures. 2385 7.1.2 SHA-1 One-way Hash Function 2387 SHA-1 was developed by the U.S. Government. The algorithm takes as 2388 input a message of arbitrary length and produces as output a 160-bit 2389 "hash" of the input. SHA-1 is fully described in FIPS 180-1 [FIPS 2390 180-1]. 2392 SHA-1 is the one-way hash function of choice for use with both the 2393 RSA and DSA signature algorithms (see Section 7.2). 2395 7.2 Signature Algorithms 2397 Certificates and CRLs described by this standard may be signed with 2398 any public key signature algorithm. The certificate or CRL indicates 2399 the algorithm through an algorithmidentifier which appears in the 2400 signatureAlgorithm field in a Certificate or CertificateList. This 2401 algorithmidentfier is an OID and has optionally associated 2402 parameters. This section identifies algorithm identifiers and 2403 parameters that shall be used in the signatureAlgorithm field in a 2404 Certificate or CertificateList. 2406 RSA and DSA are the most popular signature algorithms used in the 2407 Internet. Signature algorithms are always used in conjunction with a 2408 one-way hash function identified in Section 7.1. 2410 The signature algorithm (and one-way hash function) used to sign a 2411 certificate or CRL is indicated by use of an algorithm identifier. 2412 An algorithm identifier is an object identifier, and may include 2413 associated parameters. This section identifies OIDS for RSA and DSA 2414 and the corresponding parameters. 2416 The data to be signed (e.g., the one-way hash function output value) 2417 is formatted for the signature algorithm to be used. Then, a private 2418 key operation (e.g., RSA encryption) is performed to generate the 2419 signature value. This signature value is then ASN.1 encoded as a BIT 2420 STRING and included in the Certificate or CertificateList (in the 2421 signature field). 2423 7.2.1 RSA Signature Algorithm 2425 A patent statement regarding the RSA algorithm can be found at the 2426 end of this profile. 2428 The RSA algorithm is named for its inventors: Rivest, Shamir, and 2429 Adleman. This profile includes three signature algorithms based on 2430 the RSA asymmetric encryption algorithm. The signature algorithms 2431 combine RSA with either the MD2, MD5, or the SHA-1 one-way hash 2432 functions. 2434 The signature algorithm with MD2 and the RSA encryption algorithm is 2435 defined in PKCS #1 [PKCS#1]. As defined in PKCS #1, the ASN.1 object 2436 identifier used to identify this signature algorithm is: 2438 md2WithRSAEncryption OBJECT IDENTIFIER ::= { 2439 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 2440 pkcs-1(1) 2 } 2442 The signature algorithm with MD5 and the RSA encryption algorithm is 2443 defined in PKCS #1 [PKCS#1]. As defined in PKCS #1, the ASN.1 object 2444 identifier used to identify this signature algorithm is: 2446 md5WithRSAEncryption OBJECT IDENTIFIER ::= { 2447 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 2448 pkcs-1(1) 4 } 2450 The signature algorithm with SHA-1 and the RSA encryption algorithm 2451 is defined in by the OSI Interoperability Workshop in [OIW]. Padding 2452 conventions described in PKCS #1, section 8.1, must be used. As 2453 defined in [OIW], the ASN.1 object identifier used to identify this 2454 signature algorithm is: 2456 sha1WithRSASignature OBJECT IDENTIFIER ::= { 2457 iso(1) identified-organization(3) oiw(14) 2458 secsig(3) algorithm(2) 29 } 2460 When any of these three object identifiers appears within the ASN.1 2461 type AlgorithmIdentifier, the parameters component of that type shall 2462 be the ASN.1 type NULL. 2464 The data to be signed (e.g., the one-way hash function output value) 2465 is first ASN.1 encoded as an OCTET STRING and the result is encrypted 2466 (e.g., using RSA Encryption) to form the signed quantity. When 2467 signing, the RSA algorithm generates an integer y. This signature 2468 value is then ASN.1 encoded as a BIT STRING, such that the most 2469 significant bit in y is the first bit in the bit string and the least 2470 significant bit in y is the last bit in the bit string, and included 2471 in the Certificate or CertificateList (in the signature field). 2473 (In general the conversion to a bit string occurs in two steps. The 2474 integer y is converted to an octet string such that the first octet 2475 has the most significance and the last octet has the least 2476 significance. The octet string is converted into a bit string such 2477 that the most significant bit of the first octet shall become the 2478 first bit in the bit string, and the least significant bit of the 2479 last octet is the last bit in the BIT STRING.) 2481 7.2.2 DSA Signature Algorithm 2483 A patent statement regarding the DSA can be found at the end of this 2484 profile. 2486 The Digital Signature Algorithm (DSA) is also called the Digital 2487 Signature Standard (DSS). DSA was developed by the U.S. Government, 2488 and DSA is used in conjunction with the the SHA-1 one-way hash 2489 function. DSA is fully described in FIPS 186 [FIPS 186]. The ASN.1 2490 object identifiers used to identify this signature algorithm are: 2492 id-dsa-with-sha1 ID ::= { 2493 iso(1) member-body(2) us(840) x9-57 (10040) 2494 x9cm(4) 3 } 2496 The id-dsa-with-sha1 algorithm syntax has NULL parameters. The DSA 2497 parameters in the subjectPublicKeyInfo field of the certificate of 2498 the issuer shall apply to the verification of the signature. 2500 If the subjectPublicKeyInfo AlgorithmIdentifier field has NULL 2501 parameters and the CA signed the subject certificate using DSA, then 2502 the certificate issuer's parameters apply to the subject's DSA key. 2503 If the subjectPublicKeyInfo AlgorithmIdentifier field has NULL 2504 parameters and the CA signed the subject with a signature algorithm 2505 other than DSA, then clients shall not validate the certificate. 2507 When signing, the DSA algorithm generates two values. These values 2508 are commonly referred to as r and s. To easily transfer these two 2509 values as one signature, they shall be ASN.1 encoded using the 2510 following ASN.1 structure: 2512 Dss-Sig-Value ::= SEQUENCE { 2513 r INTEGER, 2514 s INTEGER } 2516 7.3 Subject Public Key Algorithms 2518 Certificates described by this standard may convey a public key for 2519 any public key algorithm. The certificate indicates the algorithm 2520 through an algorithmidentifier. This algorithm identfieier is an OID 2521 and optionally associated parameters. 2523 This section identifies preferred OIDs and parameters for the RSA, 2524 DSA, and Diffie-Hellman algorithms. Conforming CAs shall use the 2525 identified OIDs when issuing certificates containing public keys for 2526 these algorithms. Conforming applications supporting any of these 2527 algorithms shall, at a minimum, recognize the OID identified in this 2528 section. 2530 7.3.1 RSA Keys 2532 The object identifier rsaEncryption identifies RSA public keys. 2534 pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 2535 rsadsi(113549) pkcs(1) 1 } 2537 rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1} 2539 The rsaEncryption object identifier is intended to be used in the 2540 algorithm field of a value of type AlgorithmIdentifier. The 2541 parameters field shall have ASN.1 type NULL for this algorithm 2542 identifier. 2544 The rsa public key shall be encoded using the ASN.1 type 2545 RSAPublicKey: 2547 RSAPublicKey ::= SEQUENCE { 2548 modulus INTEGER, -- n 2549 publicExponent INTEGER -- e 2550 } 2552 where modulus is the modulus n, and publicExponent is the public 2553 exponent e. The DER encoded RSAPublicKey is the value of the BIT 2554 STRING subjectPubliKey. 2556 This object identifier is used in public key certificates for both 2557 RSA signature keys and RSA encryption keys. The intended application 2558 for the key may be indicated in the key usage field (see Section 2559 4.2.1.3). The use of a single key for both signature and encryption 2560 purposes is not recommended, but is not forbidden. 2562 If the keyUsage extension is present in an end entity certificate 2563 which conveys an RSA public key, any combination of the following 2564 values may be present: 2566 digitalSignature; 2567 nonRepudiation; 2568 keyEncipherment; and 2569 dataEncipherment. 2571 If the keyUsage extension is present in a CA certificate which 2572 conveys an RSA public key, any combination of the following values 2573 may be present: 2575 digitalSignature; 2576 nonRepudiation; 2577 keyEncipherment; 2578 dataEncipherment; 2579 keyCertSign; and 2580 cRLSign. 2581 However, this specification recommends that if keyCertSign or cRLSign 2582 is present, both keyEncipherment and dataEncipherment should not be 2583 present. 2585 7.3.2 Diffie-Hellman Key Exchange Key 2587 This diffie-hellman object identifier supported by this standard is 2588 defined by ANSI X9.42. 2590 dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2591 us(840) ansi-x942(10046) number-type(2) 1 } 2593 The dhpublicnumber object identifier is intended to be used in the 2594 algorithm field of a value of type AlgorithmIdentifier. The 2595 parameters field of that type, which has the algorithm-specific 2596 syntax ANY DEFINED BY algorithm, would have ASN.1 type DHParameter 2597 for this algorithm. 2599 DHParameter ::= SEQUENCE { 2600 prime INTEGER, -- p 2601 base INTEGER, -- g } 2603 The fields of type DHParameter have the following meanings: 2605 prime is the prime p. 2607 base is the base g. 2609 The Diffie-Hellman public key (an INTEGER) is mapped to a 2610 subjectPublicKey (a BIT STRING) as follows: the most significant bit 2611 (MSB) of the INTEGER becomes the MSB of the BIT STRING; the least 2612 significant bit (LSB) of the INTEGER becomes the LSB of the BIT 2613 STRING. 2615 If the keyUsage extension is present in a certificate which conveys a 2616 DH public key, the following values may be present: 2618 keyAgreement; 2619 encipherOnly; and 2620 decipherOnly. 2622 At most one of encipherOnly and decipherOnly shall be asserted in 2623 keyUsage extension. 2625 7.3.3 DSA Signature Keys 2627 The object identifier supported by this standard is 2629 id-dsa ID ::= { iso(1) member-body(2) us(840) x9-57(10040) 2630 x9cm(4) 1 } 2632 The id-dsa algorithm syntax includes optional parameters. These 2633 parameters are commonly referred to as p, q, and g. If the DSA 2634 algorithm parameters are absent from the subjectPublicKeyInfo 2635 AlgorithmIdentifier and the CA signed the subject certificate using 2636 DSA, then the certificate issuer's DSA parameters apply to the 2637 subject's DSA key. If the DSA algorithm parameters are absent from 2638 the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the 2639 subject certificate using a signature algorithm other than DSA, then 2640 the subject's DSA parameters are distributed by other means. The 2641 parameters are included using the following ASN.1 structure: 2643 Dss-Parms ::= SEQUENCE { 2644 p INTEGER, 2645 q INTEGER, 2646 g INTEGER } 2648 If the subjectPublicKeyInfo AlgorithmIdentifier field has NULL 2649 parameters and the CA signed the subject certificate using DSA, then 2650 the certificate issuer's parameters apply to the subject's DSA key. 2651 If the subjectPublicKeyInfo AlgorithmIdentifier field has NULL 2652 parameters and the CA signed the subject with a signature algorithm 2653 other than DSA, then clients shall not validate the certificate. 2655 When signing, DSA algorithm generates two values. These values are 2656 commonly referred to as r and s. To easily transfer these two values 2657 as one signature, they are ASN.1 encoded using the following ASN.1 2658 structure: 2660 Dss-Sig-Value ::= SEQUENCE { 2661 r INTEGER, 2662 s INTEGER } 2664 The encoded signature is conveyed as the value of the BIT STRING 2665 signature in a Certificate or CertificateList. 2667 The DSA public key shall be ASN.1 encoded as an INTEGER; this 2668 encoding shall be used as the contents (i.e., the value) of the 2669 subjectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo 2670 data element. 2672 DSAPublicKey ::= INTEGER -- public key Y 2674 If the keyUsage extension is present in an end entity certificate 2675 which conveys a DSA public key, any combination of the following 2676 values may be present: 2678 digitalSignature; and 2679 nonRepudiation. 2681 If the keyUsage extension is present in an CA certificate which 2682 conveys a DSA public key, any combination of the following values may 2683 be present: 2685 digitalSignature; 2686 nonRepudiation; 2687 keyCertSign; and 2688 cRLSign. 2690 References 2692 [COR95] ISO/IEC JTC 1/SC 21, Technical Corrigendum 2 to ISO/IEC 2693 9594-8: 1990 & 1993 (1995:E), July 1995. 2695 [FIPS 180-1] Federal Information Processing Standards Publication 2696 (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995. 2697 [Supersedes FIPS PUB 180 dated 11 May 1993.] 2699 [FIPS 186] Federal Information Processing Standards Publication 2700 (FIPS PUB) 186, Digital Signature Standard, 18 May 1994. 2702 [OIW] Stable Implementation Agreements for Open Systems 2703 Interconnection Protocols: Part 12 - OS Security, 2704 Output from the June 1995 Open Systems Environment 2705 Implementors' Workshop (OIW). 2707 [PKCS#1] PKCS #1: RSA Encryption Standard, Version 1.4, RSA Data 2708 Security, Inc., 3 June 1991. 2710 [RC95] Rogier, N. and Chauvaud, P., "The compression function of 2711 MD2 is not collision free," Presented at Selected Areas in 2712 Cryptography '95, Carleton University, Ottawa, Canada, 2713 18-19 May 1995. 2715 [RFC 791] J. Postel, "Internet Protocol", September 1981. 2717 [RFC 1319] Kaliski, B., "The MD2 Message-Digest Algorithm," RFC 1319, 2718 RSA Laboratories, April 1992. 2720 [RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic 2721 Mail: Part II: Certificate-Based Key Management," RFC 2722 1422, BBN Communications, February 1993. 2724 [RFC 1423] Balenson, D., "Privacy Enhancement for Internet Electronic 2725 Mail: Part III: Algorithms, Modes, and Identifiers," 2726 RFC 1423, Trusted Information Systems, February 1993. 2728 [RFC 1738] T. Berners-Lee, L. Masinter & M. McCahill, "Uniform 2729 Resource Locators (URL)," December 1994. 2731 [RFC 1777] W. Yeong, T. Howes & S. Kille, "Lightweight Directory 2732 Access Protocol," March 1995. 2734 [RFC 1778] T. Howes, S. Kille, W. Yeong, C. Robbins, "The String 2735 Representation of Standard Attribute Syntaxes", March 1995. 2737 [RFC 1883] S. Deering, R. Hinden, "Internet Protocol, Version 6 2738 (IPv6)," December 1995. 2740 [RFC 1959] T. Howes, M. Smith, "An LDAP URL Format", RFC 1959, 2741 June 1996. 2743 [PKIXMGMT] C. Adams, S. Farrell, "Internet Public Key Infrastructure 2744 Certificate Management Protocols", 2745 draft-ietf-pkix-ipki3cmp-04.txt, September 1997 2747 [PKIXLDAP] S. Boyeun, T. Howes and P. Richard "Internet Public Key 2748 Infrastructure Operational Protocols - LDAP", 2749 draft-ietf-pkix-ipki2opp-03.txt, September 1997. 2751 [PKIXOCSP] M. Myers, in "Internet Public Key Infrastructure Part 2: 2752 Operational Protocols", draft-ietf-pkix-ipki2opp-02.txt, 2753 July 1997. 2755 [PKIXFTP] R. Housley, "Internet Public Key Infrastructure Operational 2756 Protocols: FTP and HTTP", draft-ietf-pkix-opp-ftp-http-00.txt, 2757 September 1997. 2759 [SDN.701R] SDN.701, "Message Security Protocol", Revision 4.0 2760 1996-06-07 with "Corrections to Message Security Protocol, 2761 SDN.701, Rev 4.0, 96-06-07." August 30, 1996. 2763 [X.208] CCITT Recommendation X.208: Specification of Abstract 2764 Syntax Notation One (ASN.1), 1988. 2766 [X.509-AM] ISO/IEC JTC1/SC 21, Draft Amendments DAM 4 to ISO/IEC 2767 9594-2, DAM 2 to ISO/IEC 9594-6, DAM 1 to ISO/IEC 9594-7, 2768 and DAM 1 to ISO/IEC 9594-8 on Certificate Extensions, 2769 1 December, 1996. 2771 [X9.55] ANSI X9.55-1995, Public Key Cryptography For The Financial 2772 Services Industry: Extensions To Public Key Certificates 2773 And Certificate Revocation Lists, 8 December, 1995. 2775 [X9.57] ANSI X9.57-199x, Public Key Cryptography For The Financial 2776 Services Industry: Certificate Management (Working Draft), 2777 21 June, 1996. 2779 Patent Statements 2781 The Internet PKI relies on the use of patented public key technology 2782 and secure hash technology for digital signature services. This 2783 specification also references public key encryption technology for 2784 provisioning key exchange services. 2786 The Internet Standards Process as defined in RFC 1310 requires a 2787 written statement from the Patent holder that a license will be made 2788 available to applicants under reasonable terms and conditions prior 2789 to approving a specification as a Proposed, Draft or Internet 2790 Standard. 2792 Patent statements for DSA, RSA, and Diffie-Hellman follow. These 2793 statements have been supplied by the patent holders, not the authors 2794 of this profile. 2796 The Internet Society, Internet Architecture Board, Internet 2797 Engineering Steering Group and the Corporation for National Research 2798 Initiatives take no position on the validity or scope of the 2799 following patents and patent applications, nor on the appropriateness 2800 of the terms of the assurance. The Internet Society and other groups 2801 mentioned above have not made any determination as to any other 2802 intellectual property rights which may apply to the practice of this 2803 standard. Any further consideration of these matters is the user's 2804 own responsibility. 2806 Digital Signature Algorithm (DSA) 2808 The U.S. Government holds patent 5,231,668 on the Digital 2809 Signature Algorithm (DSA), which has been incorporated into 2810 Federal Information Processing Standard (FIPS) 186. The patent 2811 was issued on July 27, 1993. 2813 The National Institute of Standards and Technology (NIST) has a 2814 long tradition of supplying U.S. Government-developed techniques 2815 to committees and working groups for inclusion into standards on a 2816 royalty-free basis. NIST has made the DSA patent available 2817 royalty-free to users worldwide. 2819 Regarding patent infringement, FIPS 186 summarizes our position; 2820 the Department of Commerce is not aware of any patents that would 2821 be infringed by the DSA. Questions regarding this matter may be 2822 directed to the Deputy Chief Counsel for NIST. 2824 RSA Signature and Encryption 2826 The Massachusetts Institute of Technology has granted RSA Data 2827 Security, Inc., exclusive sub-licensing rights to the following 2828 patent issued in the United States: 2830 Cryptographic Communications System and Method ("RSA"), No. 2831 4,405,829 2833 RSA Data Security, Inc. has provided the following statement with 2834 regard to this patent: 2836 It is our understanding that the proposed PKIX Certificate 2837 Profile (PKIX-1) standard currently under review contemplates 2838 the use of U.S Patent 4,405,829 entitled "Cryptographic 2839 Communication System and Method" (the "RSA patent") which 2840 patent is controlled by RSA. 2842 It is RSA's business practice to make licenses to its patents 2843 available on reasonable and nondiscriminatory terms. 2844 Accordingly, if the foregoing identified IETF standard is 2845 adopted, RSA is willing, upon request, to grant non-exclusive 2846 licenses to such patent on reasonable and non-discriminatory 2847 terms and conditions to those who respect RSA's intellectual 2848 property rights and subject to RSA's then current royalty rate 2849 for the patent licensed. The royalty rate for the RSA patent is 2850 presently set at 2% of the licensee's selling price for each 2851 product covered by the patent. Any requests for license 2852 information may be directed to: 2854 Director of Licensing RSA Data Security, Inc. 100 Marine 2855 Parkway, Suite 500 Redwood City, CA 94065 2857 A license under RSA's patent(s) does not include any rights to 2858 know-how or other technical information or license under other 2859 intellectual property rights. Such license does not extend to 2860 any activities which constitute infringement or inducement 2861 thereto. A licensee must make his own determination as to 2862 whether a license is necessary under patents of others. 2864 Diffie-Hellman Key Agreement and Hellman-Merkle Public Key 2865 Cryptography 2867 Patent No. 4,200,770: Cryptographic Apparatus and Method ("Diffie- 2868 Hellman") expired on August 19, 1997. Patent No. 4,218,582: Public 2869 Key Cryptographic Apparatus and Method ("Hellman-Merkle") expired on 2870 April 29, 1997. 2872 Appendix A. ASN.1 Structures and OIDs 2874 PKIX1 DEFINITIONS IMPLICIT TAGS::= 2876 BEGIN 2878 -- UNIVERSAL Types defined in '93 ASN.1 2879 -- but required by this specification 2881 UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING 2882 -- UniversalString is defined in ASN.1:1993 2884 BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING 2885 -- BMPString is the subtype of 2886 -- UniversalString and models the Basic Multilingual Plane 2887 -- of ISO/IEC 10646-1 2888 -- 2889 -- Proposed PKIX OIDs 2890 id-pkix OBJECT IDENTIFIER ::= 2891 { iso(1) identified-organization(3) dod(6) internet(1) 2892 security(5) mechanisms(5) pkix(7) } 2894 -- PKIX arcs 2895 -- arc for private certificate extensions 2896 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 2897 -- arc for policy qualifier types 2898 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 2899 -- arc for extended key purpose OIDS 2900 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 2901 -- arc for access descriptors 2902 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 2904 -- pkix private extensions 2905 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 2907 -- policyQualifierIds for Internet policy qualifiers 2908 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 2909 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 2911 -- extended key purpose OIDs 2912 id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } 2913 id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } 2914 id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } 2915 id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } 2916 id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 } 2917 id-kp-ipsecTunnel OBJECT IDENTIFIER ::= { id-kp 6 } 2918 id-kp-ipsecUser OBJECT IDENTIFIER ::= { id-kp 7 } 2919 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 2921 -- access descriptors for authority info access extension 2922 id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } 2923 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 2925 -- attribute data types -- 2927 Attribute ::= SEQUENCE { 2928 type AttributeValue, 2929 values SET OF AttributeValue 2930 -- at least one value is required -- } 2932 AttributeType ::= OBJECT IDENTIFIER 2934 AttributeValue ::= ANY 2936 AttributeTypeAndValue ::= SEQUENCE { 2937 type AttributeType, 2938 value AttributeValue } 2940 -- naming data types -- 2942 Name ::= CHOICE { -- only one possibility for now -- 2943 rdnSequence RDNSequence } 2945 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 2947 DistinguishedName ::= RDNSequence 2949 RelativeDistinguishedName ::= 2950 SET SIZE (1 .. MAX) OF AttributeTypeAndValue 2952 -- Directory string type -- 2954 DirectoryString ::= CHOICE { 2955 teletexString TeletexString (SIZE (1..maxSize)), 2956 printableString PrintableString (SIZE (1..maxSize)), 2957 universalString UniversalString (SIZE (1..maxSize)), 2958 bmpString BMPString (SIZE(1..maxSIZE)) 2959 } 2961 -- certificate and CRL specific structures begin here 2963 Certificate ::= SEQUENCE { 2964 tbsCertificate TBSCertificate, 2965 signatureAlgorithm AlgorithmIdentifier, 2966 signature BIT STRING } 2968 TBSCertificate ::= SEQUENCE { 2969 version [0] EXPLICIT Version DEFAULT v1, 2970 serialNumber CertificateSerialNumber, 2971 signature AlgorithmIdentifier, 2972 issuer Name, 2973 validity Validity, 2974 subject Name, 2975 subjectPublicKeyInfo SubjectPublicKeyInfo, 2976 issuerUniqueID [1] UniqueIdentifier OPTIONAL, 2977 -- If present, version must be v2 or v3 2978 subjectUniqueID [2] UniqueIdentifier OPTIONAL, 2979 -- If present, version must be v2 or v3 2980 extensions [3] EXPLICIT Extensions OPTIONAL 2981 -- If present, version must be v3 2982 } 2984 Version ::= INTEGER { v1(0), v2(1), v3(2) } 2986 CertificateSerialNumber ::= INTEGER 2988 Validity ::= SEQUENCE { 2989 notBefore Time, 2990 notAfter Time } 2992 Time ::= CHOICE { 2993 utcTime UTCTime, 2994 generalTime GeneralizedTime } 2996 UniqueIdentifier ::= BIT STRING 2998 SubjectPublicKeyInfo ::= SEQUENCE { 2999 algorithm AlgorithmIdentifier, 3000 subjectPublicKey BIT STRING } 3002 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 3004 Extension ::= SEQUENCE { 3005 extnID OBJECT IDENTIFIER, 3006 critical BOOLEAN DEFAULT FALSE, 3007 extnValue OCTET STRING } 3009 -- Extension ::= { {id-ce 15}, ... , keyUsage } 3011 ID ::= OBJECT IDENTIFIER 3012 joint-iso-ccitt ID ::= { 2 } 3013 ds ID ::= {joint-iso-ccitt 5} 3014 id-ce ID ::= {ds 29} 3016 AuthorityKeyIdentifier ::= SEQUENCE { 3017 keyIdentifier [0] KeyIdentifier OPTIONAL, 3018 authorityCertIssuer [1] GeneralNames OPTIONAL, 3019 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL 3020 } 3021 ( WITH COMPONENTS {..., authorityCertIssuer PRESENT, 3022 authorityCertSerialNumber PRESENT} | 3023 WITH COMPONENTS {..., authorityCertIssuer ABSENT, 3024 authorityCertSerialNumber ABSENT} ) 3026 KeyIdentifier ::= OCTET STRING 3028 -- subjectKeyIdentifier ::= KeyIdentifier 3030 KeyUsage ::= BIT STRING { 3031 digitalSignature (0), 3032 nonRepudiation (1), 3033 keyEncipherment (2), 3034 dataEncipherment (3), 3035 keyAgreement (4), 3036 keyCertSign (5), 3037 cRLSign (6) } 3039 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } 3040 PrivateKeyUsagePeriod ::= SEQUENCE { 3041 notBefore [0] GeneralizedTime OPTIONAL, 3042 notAfter [1] GeneralizedTime OPTIONAL } 3043 ( WITH COMPONENTS {..., notBefore PRESENT} | 3044 WITH COMPONENTS {..., notAfter PRESENT} ) 3046 id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } 3048 CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 3050 PolicyInformation ::= SEQUENCE { 3051 policyIdentifier CertPolicyId, 3052 policyQualifiers SEQUENCE SIZE (1..MAX) OF 3053 PolicyQualifierInfo OPTIONAL } 3055 CertPolicyId ::= OBJECT IDENTIFIER 3057 PolicyQualifierInfo ::= SEQUENCE { 3058 policyQualifierId PolicyQualifierId, 3059 qualifier ANY DEFINED BY policyQualifierId } 3061 PolicyQualifierId ::= OBJECT IDENTIFIER 3063 id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } 3065 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 3066 issuerDomainPolicy CertPolicyId, 3067 subjectDomainPolicy CertPolicyId } 3069 id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } 3071 SubjectAltName ::= GeneralNames 3073 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 3075 GeneralName ::= CHOICE { 3076 -- OTHER-NAME ::= TYPE-IDENTIFIER note: not supported in '88 ASN.1 3077 otherName [0] AnotherName, 3078 rfc822Name [1] IA5String, 3079 dNSName [2] IA5String, 3080 x400Address [3] ORAddress, 3081 directoryName [4] Name, 3082 ediPartyName [5] EDIPartyName, 3083 uniformResourceIdentifier [6] IA5String, 3084 iPAddress [7] OCTET STRING, 3085 registeredID [8] OBJECT IDENTIFIER } 3087 AnotherName ::= SEQUENCE { 3088 type-id OBJECT IDENTIFIER, 3089 value [0] EXPLICIT ANY DEFINED BY type-id 3090 } 3092 EDIPartyName ::= SEQUENCE { 3093 nameAssigner [0] DirectoryString OPTIONAL, 3094 partyName [1] DirectoryString } 3096 id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } 3098 IssuerAltName ::= GeneralNames 3100 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } 3102 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute 3104 id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } 3106 BasicConstraints ::= SEQUENCE { 3107 cA BOOLEAN DEFAULT FALSE, 3108 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 3110 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } 3112 NameConstraints ::= SEQUENCE { 3113 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 3114 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 3116 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 3118 GeneralSubtree ::= SEQUENCE { 3119 base GeneralName, 3120 minimum [0] BaseDistance DEFAULT 0, 3121 maximum [1] BaseDistance OPTIONAL } 3123 BaseDistance ::= INTEGER (0..MAX) 3125 id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } 3127 PolicyConstraints ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 3128 requireExplicitPolicy [0] SkipCerts OPTIONAL, 3129 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 3131 SkipCerts ::= INTEGER (0..MAX) 3133 -- cRLDistributionPoints CRLDistPointsSyntax ::= 3134 -- SEQUENCE SIZE (1..MAX) OF DistributionPoint 3135 CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 3137 DistributionPoint ::= SEQUENCE { 3138 distributionPoint [0] DistributionPointName OPTIONAL, 3139 reasons [1] ReasonFlags OPTIONAL, 3140 cRLIssuer [2] GeneralNames OPTIONAL } 3142 DistributionPointName ::= CHOICE { 3143 fullName [0] GeneralNames, 3144 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 3146 ReasonFlags ::= BIT STRING { 3147 unused (0), 3148 keyCompromise (1), 3149 cACompromise (2), 3150 affiliationChanged (3), 3151 superseded (4), 3152 cessationOfOperation (5), 3153 certificateHold (6) } 3155 id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} 3157 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 3159 KeyPurposeId ::= OBJECT IDENTIFIER 3161 AuthorityInfoAccessSyntax ::= 3162 SEQUENCE SIZE (1..MAX) OF AccessDescription 3164 AccessDescription ::= SEQUENCE { 3165 accessMethod OBJECT IDENTIFIER, 3166 accessLocation GeneralName } 3168 -- CRL structures 3170 CertificateList ::= SEQUENCE { 3171 tbsCertList TBSCertList, 3172 signatureAlgorithm AlgorithmIdentifier, 3173 signature BIT STRING } 3175 TBSCertList ::= SEQUENCE { 3176 version Version OPTIONAL, 3177 -- if present, must be v2 3178 signature AlgorithmIdentifier, 3179 issuer Name, 3180 thisUpdate Time, 3181 nextUpdate Time OPTIONAL, 3182 revokedCertificates SEQUENCE OF SEQUENCE { 3183 userCertificate CertificateSerialNumber, 3184 revocationDate Time, 3185 crlEntryExtensions Extensions OPTIONAL 3186 -- if present, must be v2 3187 } OPTIONAL, 3188 crlExtensions [0] EXPLICIT Extensions OPTIONAL 3189 -- if present, must be v2 3190 } 3192 -- Version, Time, CertificateSerialNumber, and Extensions were 3193 -- defined earlier for use in the certificate structure 3195 AlgorithmIdentifier ::= SEQUENCE { 3196 algorithm OBJECT IDENTIFIER, 3197 parameters ANY DEFINED BY algorithm OPTIONAL } 3198 -- contains a value of the type 3199 -- registered for use with the 3200 -- algorithm object identifier value 3202 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 3204 CRLNumber ::= INTEGER (0..MAX) 3206 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } 3208 IssuingDistributionPoint ::= SEQUENCE { 3209 distributionPoint [0] DistributionPointName OPTIONAL, 3210 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 3211 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 3212 onlySomeReasons [3] ReasonFlags OPTIONAL, 3213 indirectCRL [4] BOOLEAN DEFAULT FALSE } 3215 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } 3217 -- deltaCRLIndicator ::= BaseCRLNumber 3219 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } 3221 BaseCRLNumber ::= CRLNumber 3223 id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 } 3225 CRLReason ::= ENUMERATED { 3226 unspecified (0), 3227 keyCompromise (1), 3228 cACompromise (2), 3229 affiliationChanged (3), 3230 superseded (4), 3231 cessationOfOperation (5), 3232 certificateHold (6), 3233 removeFromCRL (8) } 3235 id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } 3237 CertificateIssuer ::= GeneralNames 3239 id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } 3241 HoldInstructionCode ::= OBJECT IDENTIFIER 3243 -- ANSI x9 arc holdinstruction arc 3245 member-body ID ::= { iso 2 } 3246 us ID ::= { member-body 840 } 3247 x9cm ID ::= { us 10040 } 3248 holdInstruction ID ::= {x9cm 2} 3250 -- ANSI X9 holdinstructions referenced by this standard 3252 id-holdinstruction-none ID ::= {holdInstruction 1} 3253 id-holdinstruction-callissuer ID ::= {holdInstruction 2} 3254 id-holdinstruction-reject ID ::= {holdInstruction 3} 3256 id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } 3258 InvalidityDate ::= GeneralizedTime 3260 -- Algorithm structures 3262 md2WithRSAEncryption OBJECT IDENTIFIER ::= { 3263 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 3264 pkcs-1(1) 2 } 3266 md5WithRSAEncryption OBJECT IDENTIFIER ::= { 3267 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 3268 pkcs-1(1) 4 } 3270 sha1WithRSASignature OBJECT IDENTIFIER ::= { 3271 iso(1) identified-organization(3) oiw(14) secsig(3) 3272 algorithm(2) 29 } 3274 id-dsa-with-sha1 ID ::= { 3275 iso(1) member-body(2) us(840) x9-57 (10040) 3276 x9algorithm(4) 3 } 3278 Dss-Sig-Value ::= SEQUENCE { 3279 r INTEGER, 3280 s INTEGER } 3282 pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 3283 rsadsi(113549) pkcs(1) 1 } 3285 rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1} 3287 dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3288 us(840) ansi-x942(10046) number-type(2) 1 } 3290 DHParameter ::= SEQUENCE { 3291 prime INTEGER, -- p 3292 base INTEGER -- g 3293 } 3295 id-dsa ID ::= { iso(1) member-body(2) us(840) x9-57(10040) 3296 x9algorithm(4) 1 } 3298 Dss-Parms ::= SEQUENCE { 3299 p INTEGER, 3300 q INTEGER, 3301 g INTEGER } 3303 id-keyEncryptionAlgorithm OBJECT IDENTIFIER ::= 3304 { 2 16 840 1 101 2 1 1 22 } 3306 KEA-Parms-Id ::= OCTET STRING 3308 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } 3309 id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } 3310 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } 3312 CPSuri ::= IA5String 3314 UserNotice ::= CHOICE { 3315 visibleString VisibleString, 3316 bmpString BMPString 3317 } 3319 PresentationAddress ::= SEQUENCE { 3320 pSelector [0] EXPLICIT OCTET STRING OPTIONAL, 3321 sSelector [1] EXPLICIT OCTET STRING OPTIONAL, 3322 tSelector [2] EXPLICIT OCTET STRING OPTIONAL, 3323 nAddresses [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING} 3325 -- x400 address syntax starts here 3326 -- OR Names 3328 ORAddressAndOrDirectoryName ::= ORName 3330 ORAddressAndOptionalDirectoryName ::= ORName 3332 ORName ::= [APPLICATION 0] SEQUENCE { 3333 -- address -- COMPONENTS OF ORAddress, 3334 directory-name [0] Name OPTIONAL } 3336 ORAddress ::= SEQUENCE { 3337 built-in-standard-attributes BuiltInStandardAttributes, 3338 built-in-domain-defined-attributes 3339 BuiltInDomainDefinedAttributes OPTIONAL, 3340 -- see also teletex-domain-defined-attributes 3341 extension-attributes ExtensionAttributes OPTIONAL } 3342 -- The OR-address is semantically absent from the OR-name if the 3343 -- built-in-standard-attribute sequence is empty and the 3344 -- built-in-domain-defined-attributes and extension-attributes are 3345 -- both omitted. 3347 -- Built-in Standard Attributes 3348 BuiltInStandardAttributes ::= SEQUENCE { 3349 country-name CountryName OPTIONAL, 3350 administration-domain-name AdministrationDomainName OPTIONAL, 3351 network-address [0] NetworkAddress OPTIONAL, 3352 -- see also extended-network-address 3353 terminal-identifier [1] TerminalIdentifier OPTIONAL, 3354 private-domain-name [2] PrivateDomainName OPTIONAL, 3355 organization-name [3] OrganizationName OPTIONAL, 3356 -- see also teletex-organization-name 3357 numeric-user-identifier [4] NumericUserIdentifier OPTIONAL, 3358 personal-name [5] PersonalName OPTIONAL, 3359 -- see also teletex-personal-name 3360 organizational-unit-names [6] OrganizationalUnitNames OPTIONAL 3361 -- see also teletex-organizational-unit-names -- } 3363 CountryName ::= [APPLICATION 1] CHOICE { 3364 x121-dcc-code NumericString 3365 (SIZE (ub-country-name-numeric-length)), 3366 iso-3166-alpha2-code PrintableString 3367 (SIZE (ub-country-name-alpha-length)) } 3369 AdministrationDomainName ::= [APPLICATION 2] CHOICE { 3370 numeric NumericString (SIZE (0..ub-domain-name-length)), 3371 printable PrintableString (SIZE (0..ub-domain-name-length)) } 3373 NetworkAddress ::= X121Address 3374 -- see also extended-network-address 3376 X121Address ::= NumericString (SIZE (1..ub-x121-address-length)) 3378 TerminalIdentifier ::= PrintableString (SIZE (1..ub-terminal-id-length)) 3380 PrivateDomainName ::= CHOICE { 3381 numeric NumericString (SIZE (1..ub-domain-name-length)), 3382 printable PrintableString (SIZE (1..ub-domain-name-length)) } 3384 OrganizationName ::= PrintableString 3385 (SIZE (1..ub-organization-name-length)) 3386 -- see also teletex-organization-name 3388 NumericUserIdentifier ::= NumericString 3389 (SIZE (1..ub-numeric-user-id-length)) 3391 PersonalName ::= SET { 3392 surname [0] PrintableString (SIZE (1..ub-surname-length)), 3393 given-name [1] PrintableString 3394 (SIZE (1..ub-given-name-length)) OPTIONAL, 3395 initials [2] PrintableString (SIZE (1..ub-initials-length)) OPTIONAL, 3396 generation-qualifier [3] PrintableString 3397 (SIZE (1..ub-generation-qualifier-length)) OPTIONAL} 3398 -- see also teletex-personal-name 3400 OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units) 3401 OF OrganizationalUnitName 3402 -- see also teletex-organizational-unit-names 3404 OrganizationalUnitName ::= PrintableString (SIZE 3405 (1..ub-organizational-unit-name-length)) 3407 -- Built-in Domain-defined Attributes 3408 BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE 3409 (1..ub-domain-defined-attributes) OF 3410 BuiltInDomainDefinedAttribute 3412 BuiltInDomainDefinedAttribute ::= SEQUENCE { 3413 type PrintableString (SIZE 3414 (1..ub-domain-defined-attribute-type-length)), 3415 value PrintableString (SIZE 3416 (1..ub-domain-defined-attribute-value-length))} 3418 -- Extension Attributes 3419 ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) OF 3420 ExtensionAttribute 3421 ExtensionAttribute ::= EXTENSION-ATTRIBUTE 3422 EXTENSION-ATTRIBUTE ::= SEQUENCE { 3423 extension-attribute-type [0] INTEGER (0..ub-extension-attributes), 3424 extension-attribute-value [1] ANY DEFINED BY extension-attribute-type 3425 } 3427 extensionAttributeTable EXTENSION-ATTRIBUTE ::= { 3428 common-name | 3429 teletex-common-name | 3430 teletex-organization-name | 3431 teletex-personal-name | 3432 teletex-organizational-unit-names | 3433 teletex-domain-defined-attributes | 3434 pds-name | 3435 physical-delivery-country-name | 3436 postal-code | 3437 physical-delivery-office-name | 3438 physical-delivery-office-number | 3439 extension-OR-address-components | 3440 physical-delivery-personal-name | 3441 physical-delivery-organization-name | 3442 extension-physical-delivery-address-components | 3443 unformatted-postal-address | 3444 street-address | 3445 post-office-box-address | 3446 poste-restante-address | 3447 unique-postal-name | 3448 local-postal-attributes | 3449 extended-network-address | 3450 terminal-type } 3452 -- Extension Standard Attributes 3454 common-name EXTENSION-ATTRIBUTE ::= {CommonName IDENTIFIED BY 1} 3456 CommonName ::= PrintableString (SIZE (1..ub-common-name-length)) 3458 teletex-common-name EXTENSION-ATTRIBUTE ::= 3459 {TeletexCommonName IDENTIFIED BY 2} 3461 TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length)) 3463 teletex-organization-name EXTENSION-ATTRIBUTE ::= 3464 {TeletexOrganizationName IDENTIFIED BY 3} 3466 TeletexOrganizationName ::= 3467 TeletexString (SIZE (1..ub-organization-name-length)) 3469 teletex-personal-name EXTENSION-ATTRIBUTE ::= 3470 {TeletexPersonalName IDENTIFIED BY 4} 3472 TeletexPersonalName ::= SET { 3473 surname [0] TeletexString (SIZE (1..ub-surname-length)), 3474 given-name [1] TeletexString 3475 (SIZE (1..ub-given-name-length)) OPTIONAL, 3476 initials [2] TeletexString (SIZE (1..ub-initials-length)) OPTIONAL, 3477 generation-qualifier [3] TeletexString (SIZE 3478 (1..ub-generation-qualifier-length)) OPTIONAL } 3480 teletex-organizational-unit-names EXTENSION-ATTRIBUTE ::= 3481 {TeletexOrganizationalUnitNames IDENTIFIED BY 5} 3483 TeletexOrganizationalUnitNames ::= SEQUENCE SIZE 3484 (1..ub-organizational-units) OF TeletexOrganizationalUnitName 3486 TeletexOrganizationalUnitName ::= TeletexString 3487 (SIZE (1..ub-organizational-unit-name-length)) 3489 pds-name EXTENSION-ATTRIBUTE ::= {PDSName IDENTIFIED BY 7} 3491 PDSName ::= PrintableString (SIZE (1..ub-pds-name-length)) 3493 physical-delivery-country-name EXTENSION-ATTRIBUTE ::= 3494 {PhysicalDeliveryCountryName IDENTIFIED BY 8} 3496 PhysicalDeliveryCountryName ::= CHOICE { 3497 x121-dcc-code NumericString (SIZE (ub-country-name-numeric-length)), 3498 iso-3166-alpha2-code PrintableString 3499 (SIZE (ub-country-name-alpha-length)) } 3501 postal-code EXTENSION-ATTRIBUTE ::= {PostalCode IDENTIFIED BY 9} 3503 PostalCode ::= CHOICE { 3504 numeric-code NumericString (SIZE (1..ub-postal-code-length)), 3505 printable-code PrintableString (SIZE (1..ub-postal-code-length)) } 3507 physical-delivery-office-name EXTENSION-ATTRIBUTE ::= 3508 {PhysicalDeliveryOfficeName IDENTIFIED BY 10} 3510 PhysicalDeliveryOfficeName ::= PDSParameter 3512 physical-delivery-office-number EXTENSION-ATTRIBUTE ::= 3513 {PhysicalDeliveryOfficeNumber IDENTIFIED BY 11} 3515 PhysicalDeliveryOfficeNumber ::= PDSParameter 3517 extension-OR-address-components EXTENSION-ATTRIBUTE ::= 3518 {ExtensionORAddressComponents IDENTIFIED BY 12} 3520 ExtensionORAddressComponents ::= PDSParameter 3522 physical-delivery-personal-name EXTENSION-ATTRIBUTE ::= 3523 {PhysicalDeliveryPersonalName IDENTIFIED BY 13} 3525 PhysicalDeliveryPersonalName ::= PDSParameter 3527 physical-delivery-organization-name EXTENSION-ATTRIBUTE ::= 3528 {PhysicalDeliveryOrganizationName IDENTIFIED BY 14} 3530 PhysicalDeliveryOrganizationName ::= PDSParameter 3532 extension-physical-delivery-address-components EXTENSION-ATTRIBUTE ::= 3533 {ExtensionPhysicalDeliveryAddressComponents IDENTIFIED BY 15} 3535 ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter 3537 unformatted-postal-address EXTENSION-ATTRIBUTE ::= 3538 {UnformattedPostalAddress IDENTIFIED BY 16} 3540 UnformattedPostalAddress ::= SET { 3541 printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines) OF 3542 PrintableString (SIZE (1..ub-pds-parameter-length)) OPTIONAL, 3543 teletex-string TeletexString (SIZE 3544 (1..ub-unformatted-address-length)) OPTIONAL } 3546 street-address EXTENSION-ATTRIBUTE ::= 3547 {StreetAddress IDENTIFIED BY 17} 3549 StreetAddress ::= PDSParameter 3551 post-office-box-address EXTENSION-ATTRIBUTE ::= 3552 {PostOfficeBoxAddress IDENTIFIED BY 18} 3554 PostOfficeBoxAddress ::= PDSParameter 3556 poste-restante-address EXTENSION-ATTRIBUTE ::= 3557 {PosteRestanteAddress IDENTIFIED BY 19} 3559 PosteRestanteAddress ::= PDSParameter 3561 unique-postal-name EXTENSION-ATTRIBUTE ::= 3562 {UniquePostalName IDENTIFIED BY 20} 3564 UniquePostalName ::= PDSParameter 3565 local-postal-attributes EXTENSION-ATTRIBUTE ::= 3566 {LocalPostalAttributes IDENTIFIED BY 21} 3568 LocalPostalAttributes ::= PDSParameter 3570 PDSParameter ::= SET { 3571 printable-string PrintableString 3572 (SIZE(1..ub-pds-parameter-length)) OPTIONAL, 3573 teletex-string TeletexString 3574 (SIZE(1..ub-pds-parameter-length)) OPTIONAL } 3576 extended-network-address EXTENSION-ATTRIBUTE ::= 3577 {ExtendedNetworkAddress IDENTIFIED BY 22} 3579 ExtendedNetworkAddress ::= CHOICE { 3581 e163-4-address SEQUENCE { 3582 number [0] NumericString (SIZE (1..ub-e163-4-number-length)), 3583 sub-address [1] NumericString 3584 (SIZE (1..ub-e163-4-sub-address-length)) OPTIONAL }, 3585 psap-address [0] PresentationAddress } 3587 terminal-type EXTENSION-ATTRIBUTE ::= {TerminalType IDENTIFIED BY 23} 3589 TerminalType ::= INTEGER { 3590 telex (3), 3591 teletex (4), 3592 g3-facsimile (5), 3593 g4-facsimile (6), 3594 ia5-terminal (7), 3595 videotex (8) } (0..ub-integer-options) 3597 -- Extension Domain-defined Attributes 3599 teletex-domain-defined-attributes EXTENSION-ATTRIBUTE ::= 3600 {TeletexDomainDefinedAttributes IDENTIFIED BY 6} 3602 TeletexDomainDefinedAttributes ::= SEQUENCE SIZE 3603 (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute 3605 TeletexDomainDefinedAttribute ::= SEQUENCE { 3606 type TeletexString 3607 (SIZE (1..ub-domain-defined-attribute-type-length)), 3608 value TeletexString 3609 (SIZE (1..ub-domain-defined-attribute-value-length)) } 3611 -- specifications of Upper Bounds 3612 -- must be regarded as mandatory 3613 -- from Annex B of ITU-T X.411 3614 -- Reference Definition of MTS Parameter Upper Bounds 3616 -- Upper Bounds 3617 ub-common-name-length INTEGER ::= 64 3618 ub-country-name-alpha-length INTEGER ::= 2 3619 ub-country-name-numeric-length INTEGER ::= 3 3620 ub-domain-defined-attributes INTEGER ::= 4 3621 ub-domain-defined-attribute-type-length INTEGER ::= 8 3622 ub-domain-defined-attribute-value-length INTEGER ::= 128 3623 ub-domain-name-length INTEGER ::= 16 3624 ub-extension-attributes INTEGER ::= 256 3625 ub-e163-4-number-length INTEGER ::= 15 3626 ub-e163-4-sub-address-length INTEGER ::= 40 3627 ub-generation-qualifier-length INTEGER ::= 3 3628 ub-given-name-length INTEGER ::= 16 3629 ub-initials-length INTEGER ::= 5 3630 ub-integer-options INTEGER ::= 256 3631 ub-numeric-user-id-length INTEGER ::= 32 3632 ub-organization-name-length INTEGER ::= 64 3633 ub-organizational-unit-name-length INTEGER ::= 32 3634 ub-organizational-units INTEGER ::= 4 3635 ub-pds-name-length INTEGER ::= 16 3636 ub-pds-parameter-length INTEGER ::= 30 3637 ub-pds-physical-address-lines INTEGER ::= 6 3638 ub-postal-code-length INTEGER ::= 16 3639 ub-surname-length INTEGER ::= 40 3640 ub-terminal-id-length INTEGER ::= 24 3641 ub-unformatted-address-length INTEGER ::= 180 3642 ub-x121-address-length INTEGER ::= 16 3644 -- Note - upper bounds on TeletexString are measured in characters. 3645 -- A significantly greater number of octets will be required to hold 3646 -- such a value. As a minimum, 16 octets, or twice the specified upper 3647 -- bound, whichever is the larger, should be allowed. 3649 END 3651 Appendix B. 1993 ASN.1 Structures and OIDs 3653 PKIX1 DEFINITIONS IMPLICIT TAGS::= 3655 BEGIN 3657 -- 3658 -- Proposed PKIX OIDs 3659 id-pkix OBJECT IDENTIFIER ::= 3660 { iso(1) identified-organization(3) dod(6) internet(1) 3661 security(5) mechanisms(5) pkix(7) } 3663 -- PKIX arcs 3664 -- arc for private certificate extensions 3665 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 3666 -- arc for policy qualifier types 3667 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 3668 -- arc for extended key purpose OIDS 3669 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 3670 -- arc for access descriptors 3671 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 3673 -- pkix private extensions 3674 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 3676 -- policyQualifierIds for Internet policy qualifiers 3677 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 3678 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 3680 -- extended key purpose OIDs 3681 id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } 3682 id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } 3683 id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } 3684 id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } 3685 id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 } 3686 id-kp-ipsecTunnel OBJECT IDENTIFIER ::= { id-kp 6 } 3687 id-kp-ipsecUser OBJECT IDENTIFIER ::= { id-kp 7 } 3688 id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } 3690 -- access descriptors for authority info access extension 3691 id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } 3692 id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } 3694 -- attribute data types -- 3696 Attribute ::= SEQUENCE { 3697 type AttributeValue, 3698 values SET OF AttributeValue 3699 -- at least one value is required -- } 3701 AttributeType ::= OBJECT IDENTIFIER 3703 AttributeValue ::= ANY 3705 AttributeTypeAndValue ::= SEQUENCE { 3706 type AttributeType, 3707 value AttributeValue } 3709 AttributeValueAssertion ::= SEQUENCE {AttributeType, AttributeValue} 3711 -- naming data types -- 3713 Name ::= CHOICE { -- only one possibility for now -- 3714 rdnSequence RDNSequence } 3716 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 3718 DistinguishedName ::= RDNSequence 3720 RelativeDistinguishedName ::= SET SIZE (1 .. MAX) OF 3721 AttributeTypeAndValue 3723 -- Directory string type -- 3725 DirectoryString ::= CHOICE { 3726 teletexString TeletexString (SIZE (1..maxSize)), 3727 printableString PrintableString (SIZE (1..maxSize)), 3728 universalString UniversalString (SIZE (1..maxSize)), 3729 bmpString BMPString (SIZE(1..maxSIZE)) 3730 } 3732 -- from AuthenticationFramework 3733 -- {joint-iso-ccitt ds(5) modules(1) authenticationFramework(7) 2} 3734 -- note this module was defined with EXPLICIT TAGS 3736 -- types -- 3738 Certificate ::= EXPLICIT SIGNED {SEQUENCE{ 3739 version [0] Version DEFAULT v1, 3740 serialNumber CertificateSerialNumber, 3741 signature AlgorithmIdentifier, 3742 issuer Name, 3743 validity Validity, 3744 subject Name, 3745 subjectPublicKeyInfo SubjectPublicKeyInfo} 3746 issuerUniqueIdentifier [1] IMPLICIT UniqueIdentifier OPTIONAL, 3747 ---if present, version must be v1 or v2-- 3748 subjectUniqueIdentifier [2] IMPLICIT UniqueIdentifier OPTIONAL, 3749 ---if present, version must be v1 or v2-- 3750 extensions [3] Extensions Optional 3751 --if present, version must be v3--} } 3753 Version ::= INTEGER {v1(0), v2(1), v3(2) } 3755 CertificateSerialNumber ::= INTEGER 3756 Algorithmidentifier ::= SEQUENCE{ 3757 algorithm ALGORITHM.&id({SupportedAlgorithms}), 3758 parameters ALGORITHM.&Type({SupportedAlgorithms} 3759 { @algorithm}) OPTIONAL } 3761 -- Definition of the following information object is deferred. 3762 -- SupportedAlgorithms ALGORITHM ::= { ...|... } 3764 Validity ::= SEQUENCE{ 3765 notBefore Time, 3766 notAfter Time } 3768 Time ::= CHOICE { 3769 utcTime UTCTime, 3770 generalTime GeneralizedTime } 3772 SubjectPublicKeyInfo ::= SEQUENCE{ 3773 algorithm AlgorithmIdentifier, 3774 subjectPublicKey BIT STRING} 3776 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 3778 Extension ::= SEQUENCE { 3779 extnId EXTENSION.&id ({ExtensionSet}), 3780 critical BOOLEAN DEFAULT FALSE, 3781 extnValue OCTET STRING 3782 -- contains a DER encoding of a value of type 3783 -- &ExtnType for the 3784 -- extension object identified by extnId -- 3786 -- Definition of the following information object set is deferred, 3787 -- The set is required to specify a table constraint on the critical 3788 -- component of Extension. 3789 -- ExtensionSet EXTENSION ::= { ... | ... } 3791 EXTENSION ::= CLASS 3792 { 3793 &id OBJECT IDENTIFIER UNIQUE, 3794 &ExtnType 3795 } 3796 WITH SYNTAX 3797 { 3798 SYNTAX &ExtnType 3799 IDENTIFIED BY &id 3800 } 3802 CertificateList ::= EXPLICIT SIGNED { SEQUENCE { 3803 version Version OPTIONAL, -- if present, must be v2 3804 signature AlgorithmIdentifier, 3805 issuer Name, 3806 thisUpdate Time, 3807 nextUpdate Time OPTIONAL, 3808 revokedCertificates SEQUENCE OF SEQUENCE { 3809 userCertificate CertificateSerialNumber, 3810 revocationDate Time, 3811 crlEntryExtensions Extensions OPTIONAL } OPTIONAL, 3812 crlExtensions [0] Extensions OPTIONAL }} 3814 -- information object classes -- 3816 ALGORITHM ::= TYPE-IDENTIFIER 3818 -- Parameterized Types -- 3819 HASHED {ToBeHashed} ::= OCTET STRING ( CONSTRAINED-BY { 3820 --must be the result of applying a hashing procedure to the -- 3821 --DER-encoded octets of a value of -- ToBeHashed }) 3823 ENCRYPTED { ToBeEnciphered} := BIT STRING ( CONSTRAINED BY { 3824 --must be the result of applying an encipherment procedure to the -- 3825 --BER-encoded octets of a value of -- ToBeEnciphered }) 3827 SIGNED { ToBeSigned } ::= SEQUENCE{ 3828 ToBeSigned, 3829 COMPONENTS OF SIGNATURE { ToBeSigned }), 3831 SIGNATURE { OfSignature } ::= SEQUENCE { 3832 AlgorithmIdentifier, 3833 ENCRYPTED { HASHED { OfSignature }}} 3835 -- Key and policy information extensions -- 3837 authorityKeyIdentifier EXTENSION ::= { 3838 SYNTAX AuthorityKeyIdentifier 3839 IDENTIFIED BY { id-ce 35 } } 3841 AuthorityKeyIdentifier ::= SEQUENCE { 3842 keyIdentifier [0] KeyIdentifier OPTIONAL, 3843 authorityCertIssuer [1] GeneralNames OPTIONAL, 3844 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } 3845 ( WITH COMPONENTS {..., authorityCertIssuer PRESENT, 3846 authorityCertSerialNumber PRESENT} | 3847 WITH COMPONENTS {..., authorityCertIssuer ABSENT, 3848 authorityCertSerialNumber ABSENT} ) 3850 KeyIdentifier ::= OCTET STRING 3852 subjectKeyIdentifier EXTENSION ::= { 3853 SYNTAX SubjectKeyIdentifier 3854 IDENTIFIED BY { id-ce 14 } } 3856 SubjectKeyIdentifier ::= KeyIdentifier 3858 keyUsage EXTENSION ::= { 3859 SYNTAX KeyUsage 3860 IDENTIFIED BY { id-ce 15 } } 3862 KeyUsage ::= BIT STRING { 3863 digitalSignature (0), 3864 nonRepudiation (1), 3865 keyEncipherment (2), 3866 dataEncipherment (3), 3867 keyAgreement (4), 3868 keyCertSign (5), 3869 cRLSign (6) } 3871 privateKeyUsagePeriod EXTENSION ::= { 3872 SYNTAX PrivateKeyUsagePeriod 3873 IDENTIFIED BY { id-ce 16 } } 3875 PrivateKeyUsagePeriod ::= SEQUENCE { 3876 notBefore [0] GeneralizedTime OPTIONAL, 3877 notAfter [1] GeneralizedTime OPTIONAL } 3878 ( WITH COMPONENTS {..., notBefore PRESENT} | 3879 WITH COMPONENTS {..., notAfter PRESENT} ) 3881 certificatePolicies EXTENSION ::= { 3882 SYNTAX CertificatePoliciesSyntax 3883 IDENTIFIED BY { id-ce 32 } } 3885 CertificatePoliciesSyntax ::= 3886 SEQUENCE SIZE (1..MAX) OF PolicyInformation 3888 PolicyInformation ::= SEQUENCE { 3889 policyIdentifier CertPolicyId, 3890 policyQualifiers SEQUENCE SIZE (1..MAX) OF 3891 PolicyQualifierInfo OPTIONAL } 3893 CertPolicyId ::= OBJECT IDENTIFIER 3895 PolicyQualifierInfo ::= SEQUENCE { 3896 policyQualifierId CERT-POLICY-QUALIFIER.&id 3897 ({SupportedPolicyQualifiers}), 3899 qualifier CERT-POLICY-QUALIFIER.&Qualifier 3900 ({SupportedPolicyQualifiers} 3901 {@policyQualifierId})OPTIONAL } 3903 SupportedPolicyQualifiers CERT-POLICY-QUALIFIER ::= { ... } 3905 CERT-POLICY-QUALIFIER ::= CLASS { 3906 &id OBJECT IDENTIFIER UNIQUE, 3907 &Qualifier OPTIONAL } 3908 WITH SYNTAX { 3909 POLICY-QUALIFIER-ID &id 3910 [QUALIFIER-TYPE &Qualifier] } 3912 policyMappings EXTENSION ::= { 3913 SYNTAX PolicyMappingsSyntax 3914 IDENTIFIED BY { id-ce 33 } } 3916 PolicyMappingsSyntax ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 3917 issuerDomainPolicy CertPolicyId, 3918 subjectDomainPolicy CertPolicyId } 3920 supportedAlgorithms ATTRIBUTE ::= { 3921 WITH SYNTAX SupportedAlgorithm 3922 EQUALITY MATCHING RULE algorithmIdentifierMatch 3923 ID { id-at 52 } } 3925 SupportedAlgorithm ::= SEQUENCE { 3926 algorithmIdentifier AlgorithmIdentifier, 3927 intendedUsage [0] KeyUsage OPTIONAL, 3928 intendedCertificatePolicies [1] CertificatePoliciesSyntax OPTIONAL } 3930 -- Certificate subject and certificate issuer attributes extensions -- 3932 subjectAltName EXTENSION ::= { 3933 SYNTAX GeneralNames 3934 IDENTIFIED BY { id-ce 17 } } 3936 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 3938 GeneralName ::= CHOICE { 3939 otherName [0] INSTANCE OF OTHER-NAME, 3940 rfc822Name [1] IA5String, 3941 dNSName [2] IA5String, 3942 x400Address [3] ORAddress, 3943 directoryName [4] Name, 3944 ediPartyName [5] EDIPartyName, 3945 uniformResourceIdentifier [6] IA5String, 3946 iPAddress [7] OCTET STRING, 3947 registeredID [8] OBJECT IDENTIFIER } 3949 OTHER-NAME ::= TYPE-IDENTIFIER 3951 EDIPartyName ::= SEQUENCE { 3952 nameAssigner [0] DirectoryString {ub-name} OPTIONAL, 3953 partyName [1] DirectoryString {ub-name} } 3955 issuerAltName EXTENSION ::= { 3956 SYNTAX GeneralNames 3957 IDENTIFIED BY { id-ce 18 } } 3959 subjectDirectoryAttributes EXTENSION ::= { 3960 SYNTAX AttributesSyntax 3961 IDENTIFIED BY { id-ce 9 } } 3963 AttributesSyntax ::= SEQUENCE SIZE (1..MAX) OF Attribute 3965 -- Certification path constraints extensions -- 3967 basicConstraints EXTENSION ::= { 3968 SYNTAX BasicConstraintsSyntax 3969 IDENTIFIED BY { id-ce 19 } } 3971 BasicConstraintsSyntax ::= SEQUENCE { 3972 cA BOOLEAN DEFAULT FALSE, 3973 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 3975 nameConstraints EXTENSION ::= { 3976 SYNTAX NameConstraintsSyntax 3977 IDENTIFIED BY { id-ce 30 } } 3979 NameConstraintsSyntax ::= SEQUENCE { 3980 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 3981 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 3983 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 3985 GeneralSubtree ::= SEQUENCE { 3986 base GeneralName, 3987 minimum [0] BaseDistance DEFAULT 0, 3988 maximum [1] BaseDistance OPTIONAL } 3990 BaseDistance ::= INTEGER (0..MAX) 3992 policyConstraints EXTENSION ::= { 3993 SYNTAX PolicyConstraintsSyntax 3994 IDENTIFIED BY { id-ce 36 } } 3996 PolicyConstraints Syntax ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 3997 requireExplicitPolicy [0] SkipCerts OPTIONAL, 3998 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 4000 SkipCerts ::= INTEGER (0..MAX) 4002 -- Basic CRL extensions -- 4004 cRLNumber EXTENSION ::= { 4005 SYNTAX CRLNumber 4006 IDENTIFIED BY { id-ce 20 } } 4008 CRLNumber ::= INTEGER (0..MAX) 4010 reasonCode EXTENSION ::= { 4011 SYNTAX CRLReason 4012 IDENTIFIED BY { id-ce 21 } } 4014 CRLReason ::= ENUMERATED { 4015 unspecified (0), 4016 keyCompromise (1), 4017 cACompromise (2), 4018 affiliationChanged (3), 4019 superseded (4), 4020 cessationOfOperation (5), 4021 certificateHold (6), 4022 removeFromCRL (8) } 4024 instructionCode EXTENSION ::= { 4025 SYNTAX HoldInstruction 4026 IDENTIFIED BY { id-ce 23 } } 4028 HoldInstruction ::= OBJECT IDENTIFIER 4030 invalidityDate EXTENSION ::= { 4031 SYNTAX GeneralizedTime 4032 IDENTIFIED BY { id-ce 24 } } 4034 -- CRL distribution points and delta-CRL extensions -- 4036 cRLDistributionPoints EXTENSION ::= { 4037 SYNTAX CRLDistPointsSyntax 4038 IDENTIFIED BY { id-ce 31 } } 4040 CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 4041 DistributionPoint ::= SEQUENCE { 4042 distributionPoint [0] DistributionPointName OPTIONAL, 4043 reasons [1] ReasonFlags OPTIONAL, 4044 cRLIssuer [2] GeneralNames OPTIONAL } 4046 DistributionPointName ::= CHOICE { 4047 fullName [0] GeneralNames, 4048 nameRelativeToCRLIssuer [1] RelativeDistinguishedName } 4050 ReasonFlags ::= BIT STRING { 4051 unused (0), 4052 keyCompromise (1), 4053 caCompromise (2), 4054 affiliationChanged (3), 4055 superseded (4), 4056 cessationOfOperation (5), 4057 certificateHold (6) } 4059 issuingDistributionPoint EXTENSION ::= { 4060 SYNTAX IssuingDistPointSyntax 4061 IDENTIFIED BY { id-ce 28 } } 4063 IssuingDistPointSyntax ::= SEQUENCE { 4064 distributionPoint [0] DistributionPointName OPTIONAL, 4065 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 4066 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 4067 onlySomeReasons [3] ReasonFlags OPTIONAL, 4068 indirectCRL [4] BOOLEAN DEFAULT FALSE } 4070 certificateIssuer EXTENSION ::= { 4071 SYNTAX GeneralNames 4072 IDENTIFIED BY { id-ce 29 } } 4074 deltaCRLIndicator EXTENSION ::= { 4075 SYNTAX BaseCRLNumber 4076 IDENTIFIED BY { id-ce 27 } } 4078 BaseCRLNumber ::= CRLNumber 4080 deltaRevocationList ATTRIBUTE ::= { 4081 WITH SYNTAX CertificateList 4082 EQUALITY MATCHING RULE certificateListExactMatch 4083 ID {id-at 53 } } 4085 -- Object identifier assignments -- 4087 id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= {id-ce 9} 4088 id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= {id-ce 14} 4089 id-ce-keyUsage OBJECT IDENTIFIER ::= {id-ce 15} 4090 id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= {id-ce 16} 4091 id-ce-subjectAltName OBJECT IDENTIFIER ::= {id-ce 17} 4092 id-ce-issuerAltName OBJECT IDENTIFIER ::= {id-ce 18} 4093 id-ce-basicConstraints OBJECT IDENTIFIER ::= {id-ce 19} 4094 id-ce-cRLNumber OBJECT IDENTIFIER ::= {id-ce 20} 4095 id-ce-reasonCode OBJECT IDENTIFIER ::= {id-ce 21} 4096 id-ce-instructionCode OBJECT IDENTIFIER ::= {id-ce 23} 4097 id-ce-invalidityDate OBJECT IDENTIFIER ::= {id-ce 24} 4098 id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= {id-ce 27} 4099 id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= {id-ce 28} 4100 id-ce-certificateIssuer OBJECT IDENTIFIER ::= {id-ce 29} 4101 id-ce-nameConstraints OBJECT IDENTIFIER ::= {id-ce 30} 4102 id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31} 4103 id-ce-certificatePolicies OBJECT IDENTIFIER ::= {id-ce 32} 4104 id-ce-policyMappings OBJECT IDENTIFIER ::= {id-ce 33} 4105 id-ce-policyConstraints OBJECT IDENTIFIER ::= {id-ce 36} 4106 id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= {id-ce 35} 4108 -- PKIX 1 extensions 4110 id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } 4112 AuthorityInfoAccessSyntax ::= 4113 SEQUENCE SIZE (1..MAX) OF AccessDescription 4115 AccessDescription ::= SEQUENCE { 4116 accessMethod OBJECT IDENTIFIER, 4117 accessLocation GeneralName } 4119 CPSuri ::= IA5String 4121 UserNotice ::= CHOICE { 4122 visibleString VisibleString, 4123 bmpString BMPString 4124 } 4126 -- misc missing ASN.1 4128 PresentationAddress ::= SEQUENCE { 4129 pSelector [0] EXPLICIT OCTET STRING OPTIONAL, 4130 sSelector [1] EXPLICIT OCTET STRING OPTIONAL, 4131 tSelector [2] EXPLICIT OCTET STRING OPTIONAL, 4132 nAddresses [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING} 4134 -- The following OBJECT IDENTIFIERS are not used by this specification: 4136 -- {id-ce 2}, {id-ce 3}, {id-ce 4}, {id-ce 5}, {id-ce 6}, {id-ce 7}, 4137 -- {id-ce 8}, {id-ce 10}, {id-ce 11}, {id-ce 12}, {id-ce 13}, 4138 -- {id-ce 22}, {id-ce 25}, {id-ce 26} 4140 -- X.400, Algorithm Identifier, and maximum values Module 4142 ORAddressAndOrDirectoryName ::= ORName 4144 ORAddressAndOptionalDirectoryName ::= ORName 4146 ORName ::= [APPLICATION 0] SEQUENCE { 4147 -- address -- COMPONENTS OF ORAddress, 4148 directory-name [0] Name OPTIONAL } 4150 ORAddress ::= SEQUENCE { 4151 built-in-standard-attributes BuiltInStandardAttributes, 4152 built-in-domain-defined-attributes 4153 BuiltInDomainDefinedAttributes OPTIONAL, 4154 -- see also teletex-domain-defined-attributes 4155 extension-attributes ExtensionAttributes OPTIONAL } 4157 -- The OR-address is semantically absent from the OR-name if the 4158 -- built-in-standard-attribute sequence is empty and the 4159 -- built-in-domain-defined-attributes and extension-attributes are 4160 -- both omitted. 4162 -- Built-in Standard Attributes 4164 BuiltInStandardAttributes ::= SEQUENCE { 4165 country-name CountryName OPTIONAL, 4166 administration-domain-name AdministrationDomainName OPTIONAL, 4167 network-address [0] NetworkAddress OPTIONAL, 4168 -- see also extended-network-address 4169 terminal-identifier [1] TerminalIdentifier OPTIONAL, 4170 private-domain-name [2] PrivateDomainName OPTIONAL, 4171 organization-name [3] OrganizationName OPTIONAL, 4172 -- see also teletex-organization-name 4173 numeric-user-identifier [4] NumericUserIdentifier OPTIONAL, 4174 personal-name [5] PersonalName OPTIONAL, 4175 -- see also teletex-personal-name 4176 organizational-unit-names [6] OrganizationalUnitNames OPTIONAL 4177 -- see also teletex-organizational-unit-names -- } 4179 CountryName ::= [APPLICATION 1] CHOICE { 4180 x121-dcc-code NumericString 4181 (SIZE (ub-country-name-numeric-length)), 4182 iso-3166-alpha2-code PrintableString 4183 (SIZE (ub-country-name-alpha-length)) } 4185 AdministrationDomainName ::= [APPLICATION 2] CHOICE { 4186 numeric NumericString (SIZE (0..ub-domain-name-length)), 4187 printable PrintableString (SIZE (0..ub-domain-name-length)) } 4189 NetworkAddress ::= X121Address 4190 -- see also extended-network-address 4192 X121Address ::= NumericString (SIZE (1..ub-x121-address-length)) 4194 TerminalIdentifier ::= PrintableString (SIZE (1..ub-terminal-id-length)) 4196 PrivateDomainName ::= CHOICE { 4197 numeric NumericString (SIZE (1..ub-domain-name-length)), 4198 printable PrintableString (SIZE (1..ub-domain-name-length)) } 4200 OrganizationName ::= PrintableString 4201 (SIZE (1..ub-organization-name-length)) 4202 -- see also teletex-organization-name 4204 NumericUserIdentifier ::= NumericString 4205 (SIZE (1..ub-numeric-user-id-length)) 4207 PersonalName ::= SET { 4208 surname [0] PrintableString (SIZE (1..ub-surname-length)), 4209 given-name [1] PrintableString 4210 (SIZE (1..ub-given-name-length)) OPTIONAL, 4211 initials [2] PrintableString 4212 (SIZE (1..ub-initials-length)) OPTIONAL, 4213 generation-qualifier [3] PrintableString 4214 (SIZE (1..ub-generation-qualifier-length)) OPTIONAL} 4215 -- see also teletex-personal-name 4217 OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units) 4218 OF OrganizationalUnitName 4219 -- see also teletex-organizational-unit-names 4221 OrganizationalUnitName ::= PrintableString (SIZE 4222 (1..ub-organizational-unit-name-length)) 4224 -- Built-in Domain-defined Attributes 4225 BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE 4226 (1..ub-domain-defined-attributes) OF 4227 BuiltInDomainDefinedAttribute 4229 BuiltInDomainDefinedAttribute ::= SEQUENCE { 4230 type PrintableString (SIZE 4231 (1..ub-domain-defined-attribute-type-length)), 4232 value PrintableString (SIZE 4233 (1..ub-domain-defined-attribute-value-length)) } 4235 -- Extension Attributes 4237 ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) 4238 OF ExtensionAttribute 4239 ExtensionAttribute ::= SEQUENCE { 4240 extension-attribute-type [0] EXTENSION-ATTRIBUTE.&id 4241 ({ExtensionAttributeTable}), 4242 extension-attribute-value [1] EXTENSION-ATTRIBUTE.&Type 4243 ({ExtensionAttributeTable} {@extension-attribute-type}) } 4245 EXTENSION-ATTRIBUTE ::= CLASS { 4246 &id INTEGER (0..ub-extension-attributes) UNIQUE, 4247 &Type } 4248 WITH SYNTAX {&Type IDENTIFIED BY &id} 4250 ExtensionAttributeTable EXTENSION-ATTRIBUTE ::= { 4251 common-name | 4252 teletex-common-name | 4253 teletex-organization-name | 4254 teletex-personal-name | 4255 teletex-organizational-unit-names | 4256 teletex-domain-defined-attributes | 4257 pds-name | 4258 physical-delivery-country-name | 4259 postal-code | 4260 physical-delivery-office-name | 4261 physical-delivery-office-number | 4262 extension-OR-address-components | 4263 physical-delivery-personal-name | 4264 physical-delivery-organization-name | 4265 extension-physical-delivery-address-components | 4266 unformatted-postal-address | 4267 street-address | 4268 post-office-box-address | 4269 poste-restante-address | 4270 unique-postal-name | 4271 local-postal-attributes | 4272 extended-network-address | 4273 terminal-type } 4275 -- Extension Standard Attributes 4277 common-name EXTENSION-ATTRIBUTE ::= {CommonName IDENTIFIED BY 1} 4279 CommonName ::= PrintableString (SIZE (1..ub-common-name-length)) 4280 teletex-common-name EXTENSION-ATTRIBUTE ::= 4281 {TeletexCommonName IDENTIFIED BY 2} 4283 TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length)) 4285 teletex-organization-name EXTENSION-ATTRIBUTE ::= 4286 {TeletexOrganizationName IDENTIFIED BY 3} 4288 TeletexOrganizationName ::= 4289 TeletexString (SIZE (1..ub-organization-name-length)) 4291 teletex-personal-name EXTENSION-ATTRIBUTE ::= 4292 {TeletexPersonalName IDENTIFIED BY 4} 4294 TeletexPersonalName ::= SET { 4295 surname [0] TeletexString (SIZE (1..ub-surname-length)), 4296 given-name [1] TeletexString 4297 (SIZE (1..ub-given-name-length)) OPTIONAL, 4298 initials [2] TeletexString (SIZE (1..ub-initials-length)) OPTIONAL, 4299 generation-qualifier [3] TeletexString (SIZE 4300 (1..ub-generation-qualifier-length)) OPTIONAL } 4302 teletex-organizational-unit-names EXTENSION-ATTRIBUTE ::= 4303 {TeletexOrganizationalUnitNames IDENTIFIED BY 5} 4305 TeletexOrganizationalUnitNames ::= SEQUENCE SIZE 4306 (1..ub-organizational-units) OF TeletexOrganizationalUnitName 4308 TeletexOrganizationalUnitName ::= TeletexString 4309 (SIZE (1..ub-organizational-unit-name-length)) 4311 pds-name EXTENSION-ATTRIBUTE ::= {PDSName IDENTIFIED BY 7} 4313 PDSName ::= PrintableString (SIZE (1..ub-pds-name-length)) 4315 physical-delivery-country-name EXTENSION-ATTRIBUTE ::= 4316 {PhysicalDeliveryCountryName IDENTIFIED BY 8} 4318 PhysicalDeliveryCountryName ::= CHOICE { 4319 x121-dcc-code NumericString (SIZE (ub-country-name-numeric-length)), 4320 iso-3166-alpha2-code PrintableString 4321 (SIZE (ub-country-name-alpha-length)) } 4323 postal-code EXTENSION-ATTRIBUTE ::= {PostalCode IDENTIFIED BY 9} 4325 PostalCode ::= CHOICE { 4326 numeric-code NumericString (SIZE (1..ub-postal-code-length)), 4327 printable-code PrintableString (SIZE (1..ub-postal-code-length)) } 4329 physical-delivery-office-name EXTENSION-ATTRIBUTE ::= 4330 {PhysicalDeliveryOfficeName IDENTIFIED BY 10} 4332 PhysicalDeliveryOfficeName ::= PDSParameter 4334 physical-delivery-office-number EXTENSION-ATTRIBUTE ::= 4335 {PhysicalDeliveryOfficeNumber IDENTIFIED BY 11} 4337 PhysicalDeliveryOfficeNumber ::= PDSParameter 4339 extension-OR-address-components EXTENSION-ATTRIBUTE ::= 4340 {ExtensionORAddressComponents IDENTIFIED BY 12} 4342 ExtensionORAddressComponents ::= PDSParameter 4344 physical-delivery-personal-name EXTENSION-ATTRIBUTE ::= 4345 {PhysicalDeliveryPersonalName IDENTIFIED BY 13} 4347 PhysicalDeliveryPersonalName ::= PDSParameter 4349 physical-delivery-organization-name EXTENSION-ATTRIBUTE ::= 4350 {PhysicalDeliveryOrganizationName IDENTIFIED BY 14} 4352 PhysicalDeliveryOrganizationName ::= PDSParameter 4354 extension-physical-delivery-address-components EXTENSION-ATTRIBUTE ::= 4355 {ExtensionPhysicalDeliveryAddressComponents IDENTIFIED BY 15} 4357 ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter 4359 unformatted-postal-address EXTENSION-ATTRIBUTE ::= 4360 {UnformattedPostalAddress IDENTIFIED BY 16} 4362 UnformattedPostalAddress ::= SET { 4363 printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines) OF 4364 PrintableString (SIZE (1..ub-pds-parameter-length)) OPTIONAL, 4365 teletex-string TeletexString (SIZE 4366 (1..ub-unformatted-address-length)) OPTIONAL } 4368 street-address EXTENSION-ATTRIBUTE ::= 4369 {StreetAddress IDENTIFIED BY 17} 4371 StreetAddress ::= PDSParameter 4373 post-office-box-address EXTENSION-ATTRIBUTE ::= 4374 {PostOfficeBoxAddress IDENTIFIED BY 18} 4376 PostOfficeBoxAddress ::= PDSParameter 4377 poste-restante-address EXTENSION-ATTRIBUTE ::= 4378 {PosteRestanteAddress IDENTIFIED BY 19} 4380 PosteRestanteAddress ::= PDSParameter 4382 unique-postal-name EXTENSION-ATTRIBUTE ::= 4383 {UniquePostalName IDENTIFIED BY 20} 4385 UniquePostalName ::= PDSParameter 4387 local-postal-attributes EXTENSION-ATTRIBUTE ::= 4388 {LocalPostalAttributes IDENTIFIED BY 21} 4390 LocalPostalAttributes ::= PDSParameter 4392 PDSParameter ::= SET { 4393 printable-string PrintableString 4394 (SIZE(1..ub-pds-parameter-length)) OPTIONAL, 4395 teletex-string TeletexString 4396 (SIZE(1..ub-pds-parameter-length)) OPTIONAL } 4398 extended-network-address EXTENSION-ATTRIBUTE ::= 4399 {ExtendedNetworkAddress IDENTIFIED BY 22} 4401 ExtendedNetworkAddress ::= CHOICE { 4402 e163-4-address SEQUENCE { 4403 number [0] NumericString 4404 (SIZE (1..ub-e163-4-number-length)), 4405 sub-address [1] NumericString 4406 (SIZE (1..ub-e163-4-sub-address-length)) OPTIONAL}, 4407 psap-address [0] PresentationAddress } 4409 terminal-type EXTENSION-ATTRIBUTE ::= {TerminalType IDENTIFIED BY 23} 4411 TerminalType ::= INTEGER { 4412 telex (3), 4413 teletex (4), 4414 g3-facsimile (5), 4415 g4-facsimile (6), 4416 ia5-terminal (7), 4417 videotex (8) } (0..ub-integer-options) 4419 -- Extension Domain-defined Attributes 4421 teletex-domain-defined-attributes EXTENSION-ATTRIBUTE ::= 4422 {TeletexDomainDefinedAttributes IDENTIFIED BY 6} 4424 TeletexDomainDefinedAttributes ::= SEQUENCE SIZE 4425 (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute 4427 TeletexDomainDefinedAttribute ::= SEQUENCE { 4428 type TeletexString 4429 (SIZE (1..ub-domain-defined-attribute-type-length)), 4430 value TeletexString 4431 (SIZE (1..ub-domain-defined-attribute-value-length)) } 4433 -- specifications of Upper Bounds 4434 -- must be regarded as mandatory 4435 -- from Annex B of ITU-T X.411 4436 -- Reference Definition of MTS Parameter Upper Bounds 4438 -- Upper Bounds 4439 ub-common-name-length INTEGER ::= 64 4440 ub-country-name-alpha-length INTEGER ::= 2 4441 ub-country-name-numeric-length INTEGER ::= 3 4442 ub-domain-defined-attributes INTEGER ::= 4 4443 ub-domain-defined-attribute-type-length INTEGER ::= 8 4444 ub-domain-defined-attribute-value-length INTEGER ::= 128 4445 ub-domain-name-length INTEGER ::= 16 4446 ub-extension-attributes INTEGER ::= 256 4447 ub-e163-4-number-length INTEGER ::= 15 4448 ub-e163-4-sub-address-length INTEGER ::= 40 4449 ub-generation-qualifier-length INTEGER ::= 3 4450 ub-given-name-length INTEGER ::= 16 4451 ub-initials-length INTEGER ::= 5 4452 ub-integer-options INTEGER ::= 256 4453 ub-numeric-user-id-length INTEGER ::= 32 4454 ub-organization-name-length INTEGER ::= 64 4455 ub-organizational-unit-name-length INTEGER ::= 32 4456 ub-organizational-units INTEGER ::= 4 4457 ub-pds-name-length INTEGER ::= 16 4458 ub-pds-parameter-length INTEGER ::= 30 4459 ub-pds-physical-address-lines INTEGER ::= 6 4460 ub-postal-code-length INTEGER ::= 16 4461 ub-surname-length INTEGER ::= 40 4462 ub-terminal-id-length INTEGER ::= 24 4463 ub-unformatted-address-length INTEGER ::= 180 4464 ub-x121-address-length INTEGER ::= 16 4466 -- Note - upper bounds on TeletexString are measured in characters. 4467 -- A significantly greater number of octets will be required to hold 4468 -- such a value. As a minimum, 16 octets, or twice the specified upper 4469 -- bound, whichever is the larger, should be allowed. 4471 END 4472 Appendix C. ASN.1 Notes 4474 The construct 4476 SEQUENCE SIZE (1..MAX) OF 4478 appears in several ASN.1 constructs. A valid ASN.1 sequence will have 4479 zero or more entries. The SIZE (1..MAX) construct constrains the 4480 sequence to have at least one entry. MAX indicates the upper bound is 4481 unspecified. Implementations are free to choose an upper bound that 4482 suits their environment. 4484 The construct 4486 positiveInt ::= INTEGER (0..MAX) 4488 defines positiveInt as a subtype of INTEGER containing integers greater 4489 than or equal to zero. The upper bound is unspecified. Implementations 4490 are free to select an upper bound that suits their environment. 4492 The character string type PrintableString supports a very basic Latin 4493 character set: the lower case letters 'a' through 'z', upper case 4494 letters 'A' through 'Z', the digits '0' through '9', eleven special 4495 characters ' " ( ) + , - . / : ? and space. 4497 The character string type TeletexString is a superset of 4498 PrintableString. TeletexString supports a fairly standard (ascii- 4499 like) Latin character set, Latin characters with non-spacing accents 4500 and Japanese characters. 4502 The character string type UniversalString supports any of the 4503 characters allowed by ISO 10646-1. ISO 10646 is the Universal 4504 multiple-octet coded Character Set (UCS). ISO 10646-1 specifes the 4505 architecture and the "basic multilingual plane" - a large standard 4506 character set which includes all major world character standards. 4508 Appendix D. Examples 4510 This section contains four examples; three certificates and a CRL. 4511 The first two certificates and the CRL comprise a minimal 4512 certification path. 4514 Section D.1 contains two annotated hex dumps of a "self-signed" 4515 certificate issued by a CA whose distinguished name is 4516 cn=us,o=gov,ou=nist. The certificate contains a DSA public key with 4517 parameters, and is signed by the corresponding DSA private key. The 4518 first hex dump is a basic dump of the ASN.1 encoding and does not not 4519 reflect the fact that the object is a certificate. The second dump 4520 identfies the values of the various certificate fields. 4522 Section D.2 contains an annotated hex dump of an end-entity 4523 certificate. The end entity certificate contains a DSA public key, 4524 and is signed by the private key corresponding to the "self-signed" 4525 certificate in section D.1. The first hex dump is a basic dump of 4526 the ASN.1 encoding and does not not reflect the fact that the object 4527 is a certificate. The second dump identfies the values of the various 4528 certificate fields. 4530 Section D.3 contains a dump of an end entity certificate which 4531 contains an RSA public key and is signed with RSA and MD5. (This 4532 certificate is not part of the minimal certification path.) 4534 Section D.4 contains an annotated hex dump of a CRL. The CRL is 4535 issued by the CA whose distinguished name is cn=us,o=gov,ou=nist and 4536 the list of revoked certifcates includes the end entity certificate 4537 presented in D.2. The hex dump is a basic dump of the ASN.1 4538 encoding. 4540 D.1 Certificate 4542 This section contains an annotated hex dump of a 662 byte version 3 4543 certificate. The certificate contains the following information: 4544 (a) the serial number is 17 (11 hex); 4545 (b) the certificate is signed with DSA and the SHA-1 hash algorithm; 4546 (c) the issuer's distinguished name is OU=nist;O=gov;C=US 4547 (d) and the subject's distinguished name is OU=nist;O=gov;C=US 4548 (e) the certificate was issued on June 30, 1997 and will expire on 4549 December 31, 1997; 4550 (f) the certificate contains a 1024 bit DSA public key; and 4551 (g) the certificate is a CA certificate (as indicated through the 4552 basic constraints extension.) 4554 D.1.1 ASN.1 Dump of "Self-Signed" Certificate 4556 get 0, len=662 (662 bytes in file) 4557 0000 30 82 02 92 658: SEQUENCE 4558 0004 30 82 02 52 594: . SEQUENCE 4559 0008 a0 03 3: . . [0] 4560 0010 02 01 1: . . . INTEGER 2 4561 0013 02 01 1: . . INTEGER 17 4562 0016 30 09 9: . . SEQUENCE 4563 0018 06 07 7: . . . OID 1.2.840.10040.4.3: dsa-with-sha 4564 0027 30 2a 42: . . SEQUENCE 4565 0029 31 0b 11: . . . SET 4566 0031 30 09 9: . . . . SEQUENCE 4567 0033 06 03 3: . . . . . OID 2.5.4.6: C 4568 0038 13 02 2: . . . . . PrintableString 'US' 4569 0042 31 0c 12: . . . SET 4570 0044 30 0a 10: . . . . SEQUENCE 4571 0046 06 03 3: . . . . . OID 2.5.4.10: O 4572 0051 13 03 3: . . . . . PrintableString 'gov' 4573 0056 31 0d 13: . . . SET 4574 0058 30 0b 11: . . . . SEQUENCE 4575 0060 06 03 3: . . . . . OID 2.5.4.11: OU 4576 0065 13 04 4: . . . . . PrintableString 'nist' 4577 0071 30 1e 30: . . SEQUENCE 4578 0073 17 0d 13: . . . UTCTime '970630000000Z' 4579 0088 17 0d 13: . . . UTCTime '971231000000Z' 4580 0103 30 2a 42: . . SEQUENCE 4581 0105 31 0b 11: . . . SET 4582 0107 30 09 9: . . . . SEQUENCE 4583 0109 06 03 3: . . . . . OID 2.5.4.6: C 4584 0114 13 02 2: . . . . . PrintableString 'US' 4585 0118 31 0c 12: . . . SET 4586 0120 30 0a 10: . . . . SEQUENCE 4587 0122 06 03 3: . . . . . OID 2.5.4.10: O 4588 0127 13 03 3: . . . . . PrintableString 'gov' 4589 0132 31 0d 13: . . . SET 4590 0134 30 0b 11: . . . . SEQUENCE 4591 0136 06 03 3: . . . . . OID 2.5.4.11: OU 4592 0141 13 04 4: . . . . . PrintableString 'nist' 4593 0147 30 82 01 b4 436: . . SEQUENCE 4594 0151 30 82 01 29 297: . . . SEQUENCE 4595 0155 06 07 7: . . . . OID 1.2.840.10040.4.1: dsa 4596 0164 30 82 01 1c 284: . . . . SEQUENCE 4597 0168 02 81 80 128: . . . . . INTEGER 4598 : d4 38 02 c5 35 7b d5 0b a1 7e 5d 72 59 63 55 d3 4599 : 45 56 ea e2 25 1a 6b c5 a4 ab aa 0b d4 62 b4 d2 4600 : 21 b1 95 a2 c6 01 c9 c3 fa 01 6f 79 86 83 3d 03 4601 : 61 e1 f1 92 ac bc 03 4e 89 a3 c9 53 4a f7 e2 a6 4602 : 48 cf 42 1e 21 b1 5c 2b 3a 7f ba be 6b 5a f7 0a 4603 : 26 d8 8e 1b eb ec bf 1e 5a 3f 45 c0 bd 31 23 be 4604 : 69 71 a7 c2 90 fe a5 d6 80 b5 24 dc 44 9c eb 4d 4605 : f9 da f0 c8 e8 a2 4c 99 07 5c 8e 35 2b 7d 57 8d 4606 0299 02 14 20: . . . . . INTEGER 4607 : a7 83 9b f3 bd 2c 20 07 fc 4c e7 e8 9f f3 39 83 4608 : 51 0d dc dd 4609 0321 02 81 80 128: . . . . . INTEGER 4610 : 0e 3b 46 31 8a 0a 58 86 40 84 e3 a1 22 0d 88 ca 4611 : 90 88 57 64 9f 01 21 e0 15 05 94 24 82 e2 10 90 4612 : d9 e1 4e 10 5c e7 54 6b d4 0c 2b 1b 59 0a a0 b5 4613 : a1 7d b5 07 e3 65 7c ea 90 d8 8e 30 42 e4 85 bb 4614 : ac fa 4e 76 4b 78 0e df 6c e5 a6 e1 bd 59 77 7d 4615 : a6 97 59 c5 29 a7 b3 3f 95 3e 9d f1 59 2d f7 42 4616 : 87 62 3f f1 b8 6f c7 3d 4b b8 8d 74 c4 ca 44 90 4617 : cf 67 db de 14 60 97 4a d1 f7 6d 9e 09 94 c4 0d 4618 0452 03 81 84 132: . . . BIT STRING (0 unused bits) 4619 : 02 81 80 aa 98 ea 13 94 a2 db f1 5b 7f 98 2f 78 4620 : e7 d8 e3 b9 71 86 f6 80 2f 40 39 c3 da 3b 4b 13 4621 : 46 26 ee 0d 56 c5 a3 3a 39 b7 7d 33 c2 6b 5c 77 4622 : 92 f2 55 65 90 39 cd 1a 3c 86 e1 32 eb 25 bc 91 4623 : c4 ff 80 4f 36 61 bd cc e2 61 04 e0 7e 60 13 ca 4624 : c0 9c dd e0 ea 41 de 33 c1 f1 44 a9 bc 71 de cf 4625 : 59 d4 6e da 44 99 3c 21 64 e4 78 54 9d d0 7b ba 4626 : 4e f5 18 4d 5e 39 30 bf e0 d1 f6 f4 83 25 4f 14 4627 : aa 71 e1 4628 0587 a3 0d 13: . . [3] 4629 0589 30 0b 11: . . . SEQUENCE 4630 0591 30 09 9: . . . . SEQUENCE 4631 0593 06 03 3: . . . . . OID 2.5.29.19: basicConstraints 4632 0598 04 02 2: . . . . . OCTET STRING 4633 : 30 00 4634 0602 30 09 9: . SEQUENCE 4635 0604 06 07 7: . . OID 1.2.840.10040.4.3: dsa-with-sha 4636 0613 03 2f 47: . BIT STRING (0 unused bits) 4637 : 30 2c 02 14 a0 66 c1 76 33 99 13 51 8d 93 64 2f 4638 : ca 13 73 de 79 1a 7d 33 02 14 5d 90 f6 ce 92 4a 4639 : bf 29 11 24 80 28 a6 5a 8e 73 b6 76 02 68 4641 ------- extensions ---------- 4643 printber -s 456 pkix-ex1.ber 4644 get 0, len=131 (662 bytes in file) 4645 0000 02 81 80 128: INTEGER 4646 : aa 98 ea 13 94 a2 db f1 5b 7f 98 2f 78 e7 d8 e3 4647 : b9 71 86 f6 80 2f 40 39 c3 da 3b 4b 13 46 26 ee 4648 : 0d 56 c5 a3 3a 39 b7 7d 33 c2 6b 5c 77 92 f2 55 4649 : 65 90 39 cd 1a 3c 86 e1 32 eb 25 bc 91 c4 ff 80 4650 : 4f 36 61 bd cc e2 61 04 e0 7e 60 13 ca c0 9c dd 4651 : e0 ea 41 de 33 c1 f1 44 a9 bc 71 de cf 59 d4 6e 4652 : da 44 99 3c 21 64 e4 78 54 9d d0 7b ba 4e f5 18 4653 : 4d 5e 39 30 bf e0 d1 f6 f4 83 25 4f 14 aa 71 e1 4655 D.1.2 Pretty Print of "Self-Signed" Certificate 4657 ---------- 4658 decode: 0-OK, len=662 (662 bytes in file) 4660 Version: v3 4661 Serial Number: 17 4662 Signature Alg: dsa-with-sha (1.2.840.10040.4.3) 4663 Issuer: C=US, O=gov, OU=nist 4664 Validity: from 970630000000Z 4665 to 971231000000Z 4666 Subject: OU=nist, O=gov, C=US 4667 SubjectPKInfo: dsa (1.2.840.10040.4.1) 4668 params: 4669 02 81 80 d4 38 02 c5 35 7b d5 0b a1 7e 5d 72 59 4670 63 55 d3 45 56 ea e2 25 1a 6b c5 a4 ab aa 0b d4 4671 62 b4 d2 21 b1 95 a2 c6 01 c9 c3 fa 01 6f 79 86 4672 83 3d 03 61 e1 f1 92 ac bc 03 4e 89 a3 c9 53 4a 4673 f7 e2 a6 48 cf 42 1e 21 b1 5c 2b 3a 7f ba be 6b 4674 5a f7 0a 26 d8 8e 1b eb ec bf 1e 5a 3f 45 c0 bd 4675 31 23 be 69 71 a7 c2 90 fe a5 d6 80 b5 24 dc 44 4676 9c eb 4d f9 da f0 c8 e8 a2 4c 99 07 5c 8e 35 2b 4677 7d 57 8d 02 14 a7 83 9b f3 bd 2c 20 07 fc 4c e7 4678 e8 9f f3 39 83 51 0d dc dd 02 81 80 0e 3b 46 31 4679 8a 0a 58 86 40 84 e3 a1 22 0d 88 ca 90 88 57 64 4680 9f 01 21 e0 15 05 94 24 82 e2 10 90 d9 e1 4e 10 4681 5c e7 54 6b d4 0c 2b 1b 59 0a a0 b5 a1 7d b5 07 4682 e3 65 7c ea 90 d8 8e 30 42 e4 85 bb ac fa 4e 76 4683 4b 78 0e df 6c e5 a6 e1 bd 59 77 7d a6 97 59 c5 4684 29 a7 b3 3f 95 3e 9d f1 59 2d f7 42 87 62 3f f1 4685 b8 6f c7 3d 4b b8 8d 74 c4 ca 44 90 cf 67 db de 4686 14 60 97 4a d1 f7 6d 9e 09 94 c4 0d 4687 Public Key: 4688 00 02 81 80 aa 98 ea 13 94 a2 db f1 5b 7f 98 2f 4689 78 e7 d8 e3 b9 71 86 f6 80 2f 40 39 c3 da 3b 4b 4690 13 46 26 ee 0d 56 c5 a3 3a 39 b7 7d 33 c2 6b 5c 4691 77 92 f2 55 65 90 39 cd 1a 3c 86 e1 32 eb 25 bc 4692 91 c4 ff 80 4f 36 61 bd cc e2 61 04 e0 7e 60 13 4693 ca c0 9c dd e0 ea 41 de 33 c1 f1 44 a9 bc 71 de 4694 cf 59 d4 6e da 44 99 3c 21 64 e4 78 54 9d d0 7b 4695 ba 4e f5 18 4d 5e 39 30 bf e0 d1 f6 f4 83 25 4f 4696 14 aa 71 e1 4697 issuerUID: 4698 subjectUID: 4699 1 extensions: 4700 Exten 1: basicConstraints (2.5.29.19) 4701 30 00 4702 Signature Alg: dsa-with-sha (1.2.840.10040.4.3) 4703 Sig Value: 368 bits: 4704 30 2c 02 14 a0 66 c1 76 33 99 13 51 8d 93 64 2f 4705 ca 13 73 de 79 1a 7d 33 02 14 5d 90 f6 ce 92 4a 4706 bf 29 11 24 80 28 a6 5a 8e 73 b6 76 02 68 4708 ------- extensions ---------- 4709 printber -s 616 pkix-ex1.ber 4710 get 0, len=46 (662 bytes in file) 4711 0000 30 2c 44: SEQUENCE 4712 0002 02 14 20: . INTEGER 4713 : 9d 2d 0c 75 ec ce 01 79 25 4c cd 7b dc fc 17 0e 4714 : 0f 2a 22 ef 4715 0024 02 14 20: . INTEGER 4716 : 80 61 6f fb dc 71 cf 3f 09 62 b4 aa ad 4b 8c 28 4717 : 68 d7 60 fe 4719 D.2 Certificate 4721 This section contains an annotated hex dump of a xxx byte version 3 4722 certificate. The certificate contains the following information: 4723 (a) the serial number is 18 (12 hex); 4724 (b) the certificate is signed with DSA and the SHA-1 hash algorithm; 4725 (c) the issuer's distinguished name is OU=nist;O=gov;C=US 4726 (d) and the subject's distinguished name is CN=Tim 4727 Polk;OU=nist;O=gov;C=US 4728 (e) the certificate was valid from July 30, 1997 and will expire on 4729 December 1, 1997; 4730 (f) the certificate contains a 1024 bit DSA public key; 4731 (g) the certificate is an end entity certificate unless external 4732 information is provided, as the basic constraints extension is not 4733 present; 4734 (h) the certificate includes one alternative name - an RFC 822 4735 address. 4737 D.2.1 Basic ASN.1 Dump of "End Entity" Certificate 4739 ---------- 4741 get 0, len=697 (697 bytes in file) 4742 0000 30 82 02 b5 693: SEQUENCE 4743 0004 30 82 02 75 629: . SEQUENCE 4744 0008 a0 03 3: . . [0] 4745 0010 02 01 1: . . . INTEGER 2 4746 0013 02 01 1: . . INTEGER 18 4747 0016 30 09 9: . . SEQUENCE 4748 0018 06 07 7: . . . OID 1.2.840.10040.4.3: dsa-with-sha 4749 0027 30 2a 42: . . SEQUENCE 4750 0029 31 0b 11: . . . SET 4751 0031 30 09 9: . . . . SEQUENCE 4752 0033 06 03 3: . . . . . OID 2.5.4.6: C 4753 0038 13 02 2: . . . . . PrintableString 'US' 4754 0042 31 0c 12: . . . SET 4755 0044 30 0a 10: . . . . SEQUENCE 4756 0046 06 03 3: . . . . . OID 2.5.4.10: O 4757 0051 13 03 3: . . . . . PrintableString 'gov' 4758 0056 31 0d 13: . . . SET 4759 0058 30 0b 11: . . . . SEQUENCE 4760 0060 06 03 3: . . . . . OID 2.5.4.11: OU 4761 0065 13 04 4: . . . . . PrintableString 'nist' 4762 0071 30 1e 30: . . SEQUENCE 4763 0073 17 0d 13: . . . UTCTime '970730000000Z' 4764 0088 17 0d 13: . . . UTCTime '971201000000Z' 4765 0103 30 3d 61: . . SEQUENCE 4766 0105 31 0b 11: . . . SET 4767 0107 30 09 9: . . . . SEQUENCE 4768 0109 06 03 3: . . . . . OID 2.5.4.6: C 4769 0114 13 02 2: . . . . . PrintableString 'US' 4770 0118 31 0c 12: . . . SET 4771 0120 30 0a 10: . . . . SEQUENCE 4772 0122 06 03 3: . . . . . OID 2.5.4.10: O 4773 0127 13 03 3: . . . . . PrintableString 'gov' 4774 0132 31 0d 13: . . . SET 4775 0134 30 0b 11: . . . . SEQUENCE 4776 0136 06 03 3: . . . . . OID 2.5.4.11: OU 4777 0141 13 04 4: . . . . . PrintableString 'nist' 4778 0147 31 11 17: . . . SET 4779 0149 30 0f 15: . . . . SEQUENCE 4780 0151 06 03 3: . . . . . OID 2.5.4.3: CN 4781 0156 13 08 8: . . . . . PrintableString 'Tim Polk' 4782 0166 30 82 01 b4 436: . . SEQUENCE 4783 0170 30 82 01 29 297: . . . SEQUENCE 4784 0174 06 07 7: . . . . OID 1.2.840.10040.4.1: dsa 4785 0183 30 82 01 1c 284: . . . . SEQUENCE 4786 0187 02 81 80 128: . . . . . INTEGER 4787 : d4 38 02 c5 35 7b d5 0b a1 7e 5d 72 59 63 55 d3 4788 : 45 56 ea e2 25 1a 6b c5 a4 ab aa 0b d4 62 b4 d2 4789 : 21 b1 95 a2 c6 01 c9 c3 fa 01 6f 79 86 83 3d 03 4790 : 61 e1 f1 92 ac bc 03 4e 89 a3 c9 53 4a f7 e2 a6 4791 : 48 cf 42 1e 21 b1 5c 2b 3a 7f ba be 6b 5a f7 0a 4792 : 26 d8 8e 1b eb ec bf 1e 5a 3f 45 c0 bd 31 23 be 4793 : 69 71 a7 c2 90 fe a5 d6 80 b5 24 dc 44 9c eb 4d 4794 : f9 da f0 c8 e8 a2 4c 99 07 5c 8e 35 2b 7d 57 8d 4795 0318 02 14 20: . . . . . INTEGER 4796 : a7 83 9b f3 bd 2c 20 07 fc 4c e7 e8 9f f3 39 83 4797 : 51 0d dc dd 4798 0340 02 81 80 128: . . . . . INTEGER 4799 : 0e 3b 46 31 8a 0a 58 86 40 84 e3 a1 22 0d 88 ca 4800 : 90 88 57 64 9f 01 21 e0 15 05 94 24 82 e2 10 90 4801 : d9 e1 4e 10 5c e7 54 6b d4 0c 2b 1b 59 0a a0 b5 4802 : a1 7d b5 07 e3 65 7c ea 90 d8 8e 30 42 e4 85 bb 4803 : ac fa 4e 76 4b 78 0e df 6c e5 a6 e1 bd 59 77 7d 4804 : a6 97 59 c5 29 a7 b3 3f 95 3e 9d f1 59 2d f7 42 4805 : 87 62 3f f1 b8 6f c7 3d 4b b8 8d 74 c4 ca 44 90 4806 : cf 67 db de 14 60 97 4a d1 f7 6d 9e 09 94 c4 0d 4807 0471 03 81 84 132: . . . BIT STRING (0 unused bits) 4808 : 02 81 80 a8 63 b1 60 70 94 7e 0b 86 08 93 0c 0d 4809 : 08 12 4a 58 a9 af 9a 09 38 54 3b 46 82 fb 85 0d 4810 : 18 8b 2a 77 f7 58 e8 f0 1d d2 18 df fe e7 e9 35 4811 : c8 a6 1a db 8d 3d 3d f8 73 14 a9 0b 39 c7 95 f6 4812 : 52 7d 2d 13 8c ae 03 29 3c 4e 8c b0 26 18 b6 d8 4813 : 11 1f d4 12 0c 13 ce 3f f1 c7 05 4e df e1 fc 44 4814 : fd 25 34 19 4a 81 0d dd 98 42 ac d3 b6 91 0c 7f 4815 : 16 72 a3 a0 8a d7 01 7f fb 9c 93 e8 99 92 c8 42 4816 : 47 c6 43 4817 0606 a3 1d 29: . . [3] 4818 0608 30 1b 27: . . . SEQUENCE 4819 0610 30 19 25: . . . . SEQUENCE 4820 0612 06 03 3: . . . . . OID 2.5.29.17: subjectAltName 4821 0617 04 12 18: . . . . . OCTET STRING 4822 : 30 10 81 0e 77 70 6f 6c 6b 40 6e 69 73 74 2e 67 4823 : 6f 76 4824 0637 30 09 9: . SEQUENCE 4825 0639 06 07 7: . . OID 1.2.840.10040.4.3: dsa-with-sha 4826 0648 03 2f 47: . BIT STRING (0 unused bits) 4827 : 30 2c 02 14 3c 02 e0 ab d9 5d 05 77 75 15 71 58 4828 : 92 29 48 c4 1c 54 df fc 02 14 5b da 53 98 7f c5 4829 : 33 df c6 09 b2 7a e3 6f 97 70 1e 14 ed 94 4831 -------- extensions ---------- 4833 printber -s 475 pkix-ex2.ber 4834 get 0, len=131 (697 bytes in file) 4835 0000 02 81 80 128: INTEGER 4836 : a8 63 b1 60 70 94 7e 0b 86 08 93 0c 0d 08 12 4a 4837 : 58 a9 af 9a 09 38 54 3b 46 82 fb 85 0d 18 8b 2a 4838 : 77 f7 58 e8 f0 1d d2 18 df fe e7 e9 35 c8 a6 1a 4839 : db 8d 3d 3d f8 73 14 a9 0b 39 c7 95 f6 52 7d 2d 4840 : 13 8c ae 03 29 3c 4e 8c b0 26 18 b6 d8 11 1f d4 4841 : 12 0c 13 ce 3f f1 c7 05 4e df e1 fc 44 fd 25 34 4842 : 19 4a 81 0d dd 98 42 ac d3 b6 91 0c 7f 16 72 a3 4843 : a0 8a d7 01 7f fb 9c 93 e8 99 92 c8 42 47 c6 43 4845 D.2.2 Pretty Print of "End Entity" Certificate 4847 ---------- 4848 decode: 0-OK, len=697 (697 bytes in file) 4849 Version: v3 4850 Serial Number: 18 4851 Signature Alg: dsa-with-sha (1.2.840.10040.4.3) 4852 Issuer: C=US, O=gov, OU=nist 4853 Validity: from 970730000000Z 4854 to 971201000000Z 4855 Subject: CN=Tim Polk, OU=nist, O=gov, C=US 4856 SubjectPKInfo: dsa (1.2.840.10040.4.1) 4857 params: 4858 02 81 80 d4 38 02 c5 35 7b d5 0b a1 7e 5d 72 59 4859 63 55 d3 45 56 ea e2 25 1a 6b c5 a4 ab aa 0b d4 4860 62 b4 d2 21 b1 95 a2 c6 01 c9 c3 fa 01 6f 79 86 4861 83 3d 03 61 e1 f1 92 ac bc 03 4e 89 a3 c9 53 4a 4862 f7 e2 a6 48 cf 42 1e 21 b1 5c 2b 3a 7f ba be 6b 4863 5a f7 0a 26 d8 8e 1b eb ec bf 1e 5a 3f 45 c0 bd 4864 31 23 be 69 71 a7 c2 90 fe a5 d6 80 b5 24 dc 44 4865 9c eb 4d f9 da f0 c8 e8 a2 4c 99 07 5c 8e 35 2b 4866 7d 57 8d 02 14 a7 83 9b f3 bd 2c 20 07 fc 4c e7 4867 e8 9f f3 39 83 51 0d dc dd 02 81 80 0e 3b 46 31 4868 8a 0a 58 86 40 84 e3 a1 22 0d 88 ca 90 88 57 64 4869 9f 01 21 e0 15 05 94 24 82 e2 10 90 d9 e1 4e 10 4870 5c e7 54 6b d4 0c 2b 1b 59 0a a0 b5 a1 7d b5 07 4871 e3 65 7c ea 90 d8 8e 30 42 e4 85 bb ac fa 4e 76 4872 4b 78 0e df 6c e5 a6 e1 bd 59 77 7d a6 97 59 c5 4873 29 a7 b3 3f 95 3e 9d f1 59 2d f7 42 87 62 3f f1 4874 b8 6f c7 3d 4b b8 8d 74 c4 ca 44 90 cf 67 db de 4875 14 60 97 4a d1 f7 6d 9e 09 94 c4 0d 4876 Public Key: 4877 00 02 81 80 a8 63 b1 60 70 94 7e 0b 86 08 93 0c 4878 0d 08 12 4a 58 a9 af 9a 09 38 54 3b 46 82 fb 85 4879 0d 18 8b 2a 77 f7 58 e8 f0 1d d2 18 df fe e7 e9 4880 35 c8 a6 1a db 8d 3d 3d f8 73 14 a9 0b 39 c7 95 4881 f6 52 7d 2d 13 8c ae 03 29 3c 4e 8c b0 26 18 b6 4882 d8 11 1f d4 12 0c 13 ce 3f f1 c7 05 4e df e1 fc 4883 44 fd 25 34 19 4a 81 0d dd 98 42 ac d3 b6 91 0c 4884 7f 16 72 a3 a0 8a d7 01 7f fb 9c 93 e8 99 92 c8 4885 42 47 c6 43 4886 issuerUID: 4887 subjectUID: 4888 1 extensions: 4889 Exten 1: subjectAltName (2.5.29.17) 4890 30 10 81 0e 77 70 6f 6c 6b 40 6e 69 73 74 2e 67 4891 6f 76 4892 Signature Alg: dsa-with-sha (1.2.840.10040.4.3) 4893 Sig Value: 368 bits: 4894 30 2c 02 14 3c 02 e0 ab d9 5d 05 77 75 15 71 58 4895 92 29 48 c4 1c 54 df fc 02 14 5b da 53 98 7f c5 4896 33 df c6 09 b2 7a e3 6f 97 70 1e 14 ed 94 4898 -------- extensions ---------- 4900 printber -s 619 pkix-ex2.ber 4901 get 0, len=18 (697 bytes in file) 4902 0000 30 10 16: SEQUENCE 4903 0002 81 0e 14: . [1] 4904 : 77 70 6f 6c 6b 40 6e 69 73 74 2e 67 6f 76 4905 Note: This subjectAltName data is IMPLICIT TAGS - is that correct? 4907 printber -s 651 pkix-ex2.ber 4908 get 0, len=46 (697 bytes in file) 4909 0000 30 2c 44: SEQUENCE 4910 0002 02 14 20: . INTEGER 4911 : 2b 82 c9 2d 79 9c a4 16 97 22 b1 48 16 03 c2 ed 4912 : 31 65 99 d5 4913 0024 02 14 20: . INTEGER 4914 : 3f 90 79 17 f8 9d 50 fb f3 5d 70 b7 40 31 a3 74 4915 : 31 d7 b1 30 4917 D.3 End-Entity Certificate Using RSA 4919 This section contains an annotated hex dump of a 675 byte version 3 4920 certificate. The certificate contains the following information: 4921 (a) the serial number is 2; 4922 (b) the certificate is signed with RSA and the MD5 hash algorithm; 4923 (c) the issuer's distinguished name is OU=esCert- 4924 UPC;O=UPC;L=Barcelona;STREET=Catalunya;C=ES 4925 (d) and the subject's distinguished name is 4926 CN=escert.upc.es;OU=esCert- 4927 UPC;O=UPC;L=Barcelona;STREET=Catalunya;C=ES 4928 (e) the certificate was issued on May 21, 1996 and will expire on May 4929 21, 1997; 4930 (f) the certificate contains a 768 bit RSA public key which is 4931 intended for generation of digital signatures; 4932 (g) the certificate is an end entity certificate (not a CA 4933 certificate); 4934 (h) the certificate includes two alternative names - an RFC 822 4935 address, and a URL. 4937 sequence length 029f=671 bytes 4938 30 82 02 9f 4939 sequence length 0208h=520 bytes 4940 30 82 02 08 4941 explicit tag 00 "Version" 4942 a0 03 4943 integer length 1 value 2 [version is 3] 4944 02 01 02 4945 integer length 1 value 2 [serial number 2] 4946 02 01 02 4947 sequence length 13 [signature] 4948 30 0d 4949 object identifier length 9 {1 2 840 113549 1 1 4} 4950 {iso(1) member-body(2) us(840) etc.} 4951 06 09 2a 86 48 86 f7 0d 01 01 04 4952 null [null parameters] 4953 05 00 4954 sequence length 88 [issuer] 4955 30 58 4956 RDN length 11 4957 31 0b 4958 sequence length 9 4959 30 09 4960 object identifier length 3 { 2 5 4 6 } 4961 06 03 55 04 06 4962 printable string length 2 "ES" 4963 13 02 45 53 4964 RDN length 18 4965 31 12 4966 sequence length 16 4967 30 10 4968 object identifier length 3 { 2 5 4 9 } 4969 06 03 55 04 09 4970 printable string length 9 "Catalunya" 4971 13 09 43 61 74 61 6c 75 6e 79 61 4972 RDN length 18 4973 31 12 4974 sequence length 16 4975 30 10 4976 object identifier length 3 { 2 5 4 7 } 4977 06 03 55 04 07 4978 printable string length 9 "Barcelona" 4979 13 09 42 61 72 63 65 6c 6f 6e 61 4980 RDN length 12 4981 31 0c 4982 sequence length 10 4983 30 0a 4984 object identifier {2 5 4 10 } 4985 06 03 55 04 0a 4986 printable string length 3 "UPC" 4987 13 03 55 50 43 4988 RDN length 19 4989 31 13 4990 sequence length 17 4991 30 11 4992 object identifier {2 5 4 13 } 4993 06 03 55 04 0b 4994 printable string length 10 "esCERT-UPC" 4995 13 0a 65 73 43 45 52 54 2d 55 50 43 4996 sequence length 0x1e= 30 4997 30 1e 4998 UTCTime "960521095826Z" 4999 17 0d 39 36 30 35 32 31 30 39 35 38 32 36 5a 5000 UTCTime "979521095826Z" 5001 17 0d 39 37 30 35 32 31 30 39 35 38 32 36 5a 5002 sequence length 5003 30 70 5004 31 0b 5005 30 09 5006 { 2 5 4 6 } 5007 06 03 55 04 06 5008 "ES" 5009 13 02 45 53 5010 RDN 5011 31 12 5012 30 10 5013 { 2 5 4 9 } 5014 06 03 55 04 09 5015 "Catalunya" 5016 13 09 43 61 74 61 6c 75 6e 7961 5017 RDN 5018 31 12 5019 30 10 5020 { 2 5 4 7 } 5021 06 03 55 04 07 5022 "Barcelona" 5023 13 09 42 61 72 63 65 6c 6f 6e 61 5024 RDN 5025 31 0c 5026 30 0a 5027 { 2 5 4 10 } 5028 06 03 55 04 0a 5029 "UPC" 5030 13 03 55 50 43 5031 RDN 5032 31 13 5033 30 11 5034 { 2 5 4 11 } 5035 06 03 55 04 0b 5036 "esCERT-UPC" 5037 13 0a 65 73 43 45 52 54 2d 55 50 43 5038 RDN 5039 31 16 5040 30 14 5041 { 2 5 4 3 } 5042 06 03 55 04 03 5043 "escert.upc.es" 5044 13 0d 65 73 63 65 72 74 2e 75 70 63 2e 65 73 5045 subjectPublicKeyInfo 5046 30 7c 5047 algorithmIdentifier 5048 30 0d 5049 { 1 2 840 113549 1 1 1} 5050 06 09 2a 86 48 86 f7 0d 01 01 01 5051 null parameters 5052 05 00 5053 { subject's public key } 5054 03 6b BIT STRING length 107 bytes (856 bits) 5055 0030 6802 6100 beaa 8b77 54a3 afca 779f 5056 2fb0 cf43 88ff a66d 7955 5b61 8c68 ec48 5057 1e8a 8638 a4fe 19b8 6217 1d9d 0f47 2cff 5058 638f 2991 04d1 52bc 7f67 b6b2 8f74 55c1 5059 3321 6c8f ab01 9524 c8b2 7393 9d22 6150 5060 a935 fb9d 5750 32ef 5652 5093 abb1 8894 5061 7856 15c6 1c8b 0203 0100 01 5062 explicit tag 3 "extensions" length 0x84=132 5063 a3 81 84 5064 sequence 129 bytes 5065 30 81 81 5066 sequence 12 bytes 5067 30 0b 5068 id-ce-keyUsage = { 2 5 29 15 } 5069 06 03 55 1d 0f 5070 by default, critical = FALSE 5071 octet string 5072 04 04 03 02 07 80 5073 30 09 5074 id-ce-basicConstraints = { 2 5 29 19 } 5075 06 03 55 1d 13 5076 by default, critical = FALSE 5077 octet string 5078 04 02 5079 null sequence - by default, subject is end entity 5080 30 00 5081 30 3d 5082 id-ce-subjectAltName = { 2 5 29 17 } 5083 06 03 55 1d 11 5084 by default, critical = FALSE 5085 octet string 5086 04 36 5087 30 34 5088 rfc822name 5089 a1 1a 5090 IA5String "escert-upc@escert.upc.es" 5091 16 18 65 73 63 65 72 74 2d 75 70 63 40 65 73 63 5092 65 72 74 2e 75 70 63 2e 65 73 5093 uniformResourceIdentifier 5094 a6 16 5095 IA5String "http://escert.upc.es" 5096 16 14 68 74 74 70 3a 2f 2f 65 73 63 65 72 74 2e 5097 75 70 63 2e 65 73 5098 30 28 5099 id-ce-certificatePolicies = { 2 5 29 32 } 5100 06 03 55 1d 20 5101 by default, critical = FALSE 5102 octet string 5103 04 21 5104 30 1f 5105 30 1d 5106 06 04 2a 84 80 00 5107 { 2 2 32768 } 5108 30 15 5109 30 07 5110 { 2 2 32768 1 } 5111 06 05 2a 84 80 00 01 5112 30 0a 5113 { 2 2 32768 2 } 5114 06 05 2a 84 80 00 02 5115 02 01 0a 5116 sequence 5117 30 0d 5118 { 1 2 840 113549 1 1 4 } 5119 06 09 2a 86 48 86 f7 0d 01 01 04 5120 null parameters 5121 05 00 5122 bit string length 129 (signature) 5123 03 81 81 005b fdc2 a704 d483 4e17 6da6 fa27 e7c6 5124 f8ab b95d 9fd0 a1df d797 9fe0 20a6 c57a 5125 64cd 522f e9ae dabe 9ce4 d597 edf1 84c0 5126 d0fe 9bef 54b1 80e5 bf3c c9ed 9320 2d52 5127 21e9 bcb9 e34f ac11 650e 8fa1 6899 6347 5128 e53d e442 7313 fac5 c834 8cc0 4118 89d5 5129 e6a0 185b 5d86 1c1e c670 d80e 8964 9483 5130 8e3b 407c 59cf 2b2f b7ce 9798 1215 ef13 5131 d4 5133 D.4 Certificate Revocation List 5135 This section contains an annotated hex dump of a version 2 CRL with 5136 one extension (cRLNumber). The CRL was issued by OU=nist;O=gov;C=us 5137 on July 7, 1996; the next scheduled issuance was August 7, 1996. The 5138 CRL includes one revoked certificates: serial number 18 (12 hex). 5139 The CRL itself is number 18, and it was signed with DSA. 5141 printber pkix-crl.ber 5142 get 0, len=189 (189 bytes in file) 5143 0000 30 81 ba 186: SEQUENCE 5144 0003 30 7c 124: . SEQUENCE 5145 0005 02 01 1: . . INTEGER 1 5146 0008 30 09 9: . . SEQUENCE 5147 0010 06 07 7: . . . OID 1.2.840.10040.4.3: dsa-with-sha 5148 0019 30 2a 42: . . SEQUENCE 5149 0021 31 0b 11: . . . SET 5150 0023 30 09 9: . . . . SEQUENCE 5151 0025 06 03 3: . . . . . OID 2.5.4.6: C 5152 0030 13 02 2: . . . . . PrintableString 'US' 5153 0034 31 0c 12: . . . SET 5154 0036 30 0a 10: . . . . SEQUENCE 5155 0038 06 03 3: . . . . . OID 2.5.4.10: O 5156 0043 13 03 3: . . . . . PrintableString 'gov' 5157 0048 31 0d 13: . . . SET 5158 0050 30 0b 11: . . . . SEQUENCE 5159 0052 06 03 3: . . . . . OID 2.5.4.11: OU 5160 0057 13 04 4: . . . . . PrintableString 'nist' 5161 0063 17 0d 13: . . UTCTime '970801000000Z' 5162 0078 17 0d 13: . . UTCTime '970808000000Z' 5163 0093 30 22 34: . . SEQUENCE 5164 0095 30 20 32: . . . SEQUENCE 5165 0097 02 01 1: . . . . INTEGER 18 5166 0100 17 0d 13: . . . . UTCTime '970731000000Z' 5167 0115 30 0c 12: . . . . SEQUENCE 5168 0117 30 0a 10: . . . . . SEQUENCE 5169 0119 06 03 3: . . . . . . OID 2.5.29.21: reasonCode 5170 0124 04 03 3: . . . . . . OCTET STRING 5171 : 0a 01 01 5172 0129 30 09 9: . SEQUENCE 5173 0131 06 07 7: . . OID 1.2.840.10040.4.3: dsa-with-sha 5174 0140 03 2f 47: . BIT STRING (0 unused bits) 5175 : 30 2c 02 14 9e d8 6b c1 7d c2 c4 02 f5 17 84 f9 5176 : 9f 46 7a ca cf b7 05 8a 02 14 9e 43 39 85 dc ea 5177 : 14 13 72 93 54 5d 44 44 e5 05 fe 73 9a b2 5179 printber -s 143 pkix-crl.ber 5180 get 0, len=46 (189 bytes in file) 5181 0000 30 2c 44: SEQUENCE 5182 0002 02 14 20: . INTEGER 5183 : 9e d8 6b c1 7d c2 c4 02 f5 17 84 f9 9f 46 7a ca 5184 : cf b7 05 8a 5185 0024 02 14 20: . INTEGER 5186 : 9e 43 39 85 dc ea 14 13 72 93 54 5d 44 44 e5 05 5187 : fe 73 9a b2 5189 Security Considerations 5191 This entire memo is about security mechanisms. 5193 Author Addresses: 5195 Russell Housley 5196 SPYRUS 5197 PO Box 1198 5198 Herndon, VA 20172 5199 USA 5200 housley@spyrus.com 5202 Warwick Ford 5203 VeriSign, Inc. 5204 One Alewife Center 5205 Cambridge, MA 02140 5206 USA 5207 wford@verisign.com 5209 Tim Polk 5210 NIST 5211 Building 820, Room 426 5212 Gaithersburg, MD 20899 5213 USA 5214 wpolk@nist.gov 5216 David Solo 5217 BBN 5218 150 CambridgePark Drive 5219 Cambridge, MA 02140 5220 USA 5221 solo@bbn.com