Internet X.509 public key infrastructure (RFC2459 Chinese translation)

xiaoxiao2021-03-05 23

Organizational: China Interactive Publishing Network (http://www.china-pub.com/) RFC Document Chinese Translation Plan (http://www.china-pub.com/compters/emook/aboutemook.htm )E-mail: Ouyang@china-pub.com Translator: NetDebug InternetDebug@clong.com) Translation time: 2001-7-14 Copyright: Chinese Interactive Publishing Network. Can be used for non-commercial use free reprint, but the translation and copyright information of this document must be retained.

Network Working Group R. HousleyRequest for Comments: 2459 Spyruscategory: Standards TRACK W. FORD VERISIGN W. POLK NIST D. Sol Citicorp January 1999

Internet X.509 Public Key Infrastructure Certificate and CRL Introduction (Internet X.509 Public Key InfrastructureCertificate and CRL PROFILE)

Memorandum Present Sports This document requires an Internet community to further discuss and improve the Internet test standard protocol. For the Standardization and Status of this document, please refer to the current version of the Internet Official Agreement Standard (STD1). This memorandum distribution is unrestricted.

Abstract This memo describes the X.509 V3 certificate applied in the Internet and X.509 V2CRL (a list of certificate revocations) to introduce a proximity review and model. X.509 V3 Certificate Format is depicted as the format and semantic additional information on the Internet name (eg, IP address) is depicted. Standard certificate extensions are depicted and new Internet-Specific (unique extensions) are defined. A certificate extension is specified. At the same time, the X.509 V2 CRL format is depicted and a set of extensions is defined. A set of X.509 certificates path confirmation algorithms are described. The public key and digital signature of the general Internet public key cryptode algorithm (ie, RSA, DSA, and Diffie-Hellman) are provided in complementary information. ASN.1 modules and examples are provided in the appendix.

Convention: Keywords "Must", "Must Not", "Required", "SHALL", "SHALL NOT", "Shove", "Should Not", "Recommended", "BoLD", "Recommended", "Should Not", "Recommended", "Optional" The meaning of the description in RFC 2119 [3] is the same. Please mail the comments on this article to the IETF-PKIX@imc.org post list.

The translator's reading RFC2459 readers should first understand the knowledge about cybersecurity, such as cryptographic knowledge (encryption, decryption, signature, verification, security protocol, etc.), all data structures in the RFC2459 document use ASN1 syntax description and Coding and decoding (the specific implementation is the case), so the reader is best familiar with the ASN1 language. RFC2459 is an experimental document in the RFC class, describing the Internet X.509 public key infrastructure certificate and CRL knowledge, there are many content covered (many of the content in documentation is suggested), and the specific details are relatively small The readers of interest can be guided to understand, learn, and study the details of their related content in this document, as this document is comparable. Translators try to retain the original ideas of the original text when translating this document, using direct transliteration, have a translator's annotation for obscuring or guided reading, I hope to help readers. Due to the short period of translation and limited translators, there will be many improper and missed or even mistakes, I hope the readers will be entertained, thank you.

Zhang Haibin

2001-7-9

Directory 1 Introduction 52 Requirements and Assumption 62.1 Accept and Topology 62.2 Acceptable Standard (Acceptability Criteria) 62.3 User expectation 72.4 Administrative staff expect 73 Overview 73.1 X.509 V3 Certificate 83.2 Certificate Path and Trust 93.3 Undo 103.4 Operation Agreement 113.5 Management Agreement 114 certificate and certificate extensions outline the basic certificate fields 134.1.1 124.1 certificate fields 144.1.1.1 tbsCertificate 144.1.1.2 signatureAlgorithm 144.1.1.3 signatureValue 154.1.2 tBSCertificate 154.1.2.1 154.1.2.2 version serial number signature 164.1.2.4 154.1.2.3 issuer 164.1 .2.5 Validity 194.1.2.5.1 Utctime 194.1.2.5.2 GeneralizedTime 194.1.2.6 Topic 204.1.2.2 Theme Public Key Information 204.1.2.8 Unique Identifier 214.1.2.9 Extension 214.2 Standard Certificate Extension 214.2.1 Standard Expansion 224.2.1.1 Authoritative Key Identifier 224.2.1.2 Topic Key Identifier 234.2.1.3 Key Use 244.2.1.5 Private Key Usage Certificate 254.2.1.5 Certificate Policy 264.2.1.6 Policies 284.2.1.7 Topics Replacement Name 284.2.1.8 Publisher Replacement Name 304.2.1.9 Topic Directory Service System Properties 304.2.1.10 Basic Constraint 314.2.1.11 Name Constrained 314.2.1.12 Policy Constraint 334.2.1.13 Expand Key Usage 334.2.14 CRL Publishing Point 354.2.2 Private Internet Extension 354.2.2.1 Authority Information access 365 CRL and CRL extensions Introduction 375.1 CRL field 375.1.1 CertificateList field tbsCertList 385.1.1.2 signatureAlgorithm 395.1.1.3 signatureValue 395.1.2 certificate list 385.1.1.1 "To Be Signed" 395.1.2.1 395.1.2.2 signature 405.1.2.3 release version Name 405.1.2.4 Update 405.1.2.5 Next Update 405.1.2.6 Undo Certificate 415.1.2.7 Expansion 415.2 CR L Scalable 415.2.1 Authoritative key identifier 425.2.2 issuer replacement name 425.2.3 CRL Number 425.2.2 Delta CRL Identifier 435.2.5 Release Point 435.3 CRL Entry Extension 445.3.1 Reason code 445.3.2 Keep instructions Code 455.3.3 Invalid Date 455.3.4 Certificate issuer 466 Certificate Path Approve 466.1 Basic Path Approval 476.2 Extended Path Approve 507 Algorithm Technical Support 507.1 One-way Hash Function 507.1.1 MD2 One-way Hash Function 517.1.2 MD5 One-way Hash Function 517.1.3 SHA1 One-way Hash Function 517.2 Signing Algorithm 517.2.1 RSA Signing Algorithm 527.2.2 DSA Signing Algorithm 537.3 Topic Publication Key Algorithm 537.3.1 RSA Key 547.3.2 Diffie-Hellman Key Exchange Key 547.3.3 DSA Signing Key 568 Reference 579 Intellectual Property 5910 Safety Consideration 59 Appendix A. PsuedoAsN.1 Structure and OIDS 61A.1 Explicit Target Module (Explicitly Tagged Module), 1988 Syntax 61A.2 Implicit Target Module (IMPLICITLY TAGGED) Module, 1988 syntax 76 Appendix B. 1993 ASN.1 Structure And OIDS 83B.1 Explicit Tagitly Tagged Module, 1993 Syntha 83B.2 Tag Target Module (IMPLICITLY TAGGED MODULE)

, 1993 syntonym 101 Appendix C. ASN.1 annotation 109 Appendix D. Example 110D.1 Certificate 111D.2 Certificate 114D.3 RSA Algorithm Terminal Certificate 117D.4 Certificate Revoke List 121 Appendix E. Authors' Addresses 122 Appendix F. Complete Copyright Declaring 1231 Introduction This article is part of the X.509 public key infrastructure (PKI) standard family in the Internet, and also separate files; additional standard execution may continue to separate from other parts.

This article describes the formats and semantics applications where the Internet PKI certificate and certificate revocation list is applied. Describe the processing of the certificate path in the Internet environment, providing coding rules of the cryptographic algorithm. Finally, all data structural definitions of this article are described in the ASN.1 grammar in the appendix.

This paper depicts the assumption that the passion and influence of this document can be protonally improving. Article 3 The module of a structure and depicts them and the previous IETF and ISO / IECITU standards. In particular, this article IETF PEM describes the relationship between ISO / IEC ITU X.509 documentation.

This article describes the X.509 V3 certificate in section 4; the X.509 V2 certificate revocation list (CRL) is introduced in part 5. Includes the definition of ISO / IEC / ITU and ANSI extensions in Internet PKI. This article uses a summary syntax notes defined in 1988 (ASN.1) instead of the grammar standards defined in ISO / IEC / ITU in 1994.

The path confirmation process is also described herein in section 6. These processes are based on definitions on the ISOIEC / ITU, but issues that assume one or more self-signed trusted CA certificates, only the same result is required without the need to develop specific processing procedures.

Part 7 of this paper depicts the procedure for confirmation and encoding of the public key content and digital signature. No special cryptographic algorithm is required, but it needs to be identified (this) algorithm, which can be identified and can be encoded.

Finally, IMPLEMENTERS is provided in the four appendices. Appendix A contains all ASN.1 structures within or recommended in this article. As mentioned above, the description of these data structures applies 1988's summary syntax notes 1 (ASN.1), not 1994 syntax. Appendix B contains the same information, which uses 1994 ASN.1 annotations for the IMPLEMENTERS service for updated Toolsets (Applications). However, Appendix A takes a time order to prevent conflict. Appendix C contains not least familiar features that use Asn.1 notes within this document. Appendix D contains examples of certificates and CRLs.

2 requirement and assumption

The goal of this article is to provide help to facilitate the use of X.509 technology to apply for the use of X.509 technology in those Internet communities. These applications include WWW, email, user provell, and IPsec. In order to alleviate some obstacles to the X.509 certificate, this paper defines the contour of promoting the development of the certificate management system; the development of the application tool; and the strategy that can be developed by both parties.

For additional (additional) approval, guarantees, or operational requirements in line with specialized applications, or the environmental requirements, some communities will need to be supplemented, may replace this article (certain) description. However, for basic applications, those representatives that are often used and shared are defined so that developers can obtain the necessary knowledge, regardless of the issuer of the certificate or certificate revocation (CRL).

Before trusting, a certificate user should browse the certificate policy, authorized by the certificate authority (CA, CA, below CA), which is linked to the public key in a specific certificate. For this purpose, this standard does not define the rules or duties of legal bundles. When the supplementary authorization and attribute management tools appear, such as attribute certificates, it is suitable to limit the certificate of authorized attributes within a certificate. These (other, assistive) management tools provide a more suitable way to express many attribute authorizations.

2.1 Communication and Topology

Users who use certificates will operate in the wide range of users of users in their communication topology environment. This article supports possibilities users without high bandwidth, real-time IP connection, or high connection availability. In addition, this article allows the firewall or (other) to filter the presence of communication devices.

This article does not assume the development of the X.500 directory service system. This article does not prohibit the use of the X.500 directory service system, but the (other) of the issuance certificate and certificate revocation list (CRLS) can be used.

2.2 Acceptable standards (Acceptability criteria)

The target of the Internet Public Key Infrastructure (PKI) is to meet the demand for DETERMINISTIC, automated confirmation, authentication, and access control authorization. Support for these services is bound by consisting of properties contained in the certificate, as well as some subordinate control information, such as the policy data and certificate paths in the certificate.

2.3 User expectations

Internet PKI users are people and processes using customer software and theme names in the certificate. They include those readers and authors, WWW browser customers, WWW servers, and routers that use email readers and authors, and IPSec. This article identifies users who use limitations and users who are limited to the world. This is responsible for the minimal user (eg trusted CA key, rule), which is clearly used in the certificate, the certificate path constraint, and the automatic verification validity function, so that users protect users from many malicious behaviors.

2.4 Administrative staff expects that the Internet PKI is an individual that supports usually operated CAS. Providing administrative personnel with unsound choices to reduce the wider damage results of CA administrative personnel subtle mistakes. At the same time, there is no marginal choice to process and verify the complexity of the effectiveness software for issuing certificates by the CA Center. 3 Overview The following is a hypothetical view of the assumed structure in accordance with PKIX standard.

--- | C | ------------ | E | <------------------> | End Entity | | R | Operational ------------ | T | Transactions ^ | | | | TRANSACTIONS | Transactions | | | ---------------- - ------------------------------------------------------------------------------------ L | ^ ^ | | | | PKI Management | | V | Entities | R | ------ | | E | <------------------- - | RA | <--- | | P | Publish Certificate ------ | | | | | | | | | | T | ------------ | O | <--------------------------- - | CA | | R | Publish certificate ------------ | Y | Publish CRL ^ | | | - MANAGEMENT | Transactions | V ------ | CA | ------ Figure 1-PKI entity

This model component includes: • End entry: PKI certificate or user user;? CA: CA: Certificate Authorization Center; • RA: Certificate Registration Center, an optional manner with CA delegation Representative system; storage: a system or collected allocation system, store certificates and CRLs assigned to end entities, and services. 3.1 X.509 V3 certificate

The user of the public key will be a remote body (person or system) that is determined by the private key, which will use the encryption or signature algorithm. Trust is obtained by the use of the public key in the certificate, and the certificate is a data structure that binds the public key to the subject information. Bundles By trusted CA digital signature, CA can be based on such technical means (A.K.a.a.a.a.a., Posession "assertion, or a description of a private key asserted in accordance with the subject. Each certificate has a lifestyle in its signature content. Because the signature of each certificate and the client used by the certificate are independently inspected, the certificate (can) can transfer in the custom-free communication and server system to use non-secure storage in the certificate usage system.

ITU TX.509 (past ccitt X.509) or ISO / IEC ITU9594-8 defines a standard certificate format [X.509], first published as part of the recommended X.500 directory service system in 1988. The certificate format in the 1988 standard is called version 1 (V1) format. When the X.500 is fixed in 1993, an additional two fields are added in version 2 (V2) format. These two fields can be used to support access control of the directory service system.

The Internet Privacy Enhancement Mail (PEM) RFCS published in 1993 is included on the basis of the X.509 V1 certificate [RFC 1422]. Experience in the attempt to deploy RFC 1422 explicitly indicate that the V1 and V2 certificate formats are insufficient in several ways. The most important thing is that in PEM design and application experience have proven to carry more information. In the face of these new requirements, ISO IEC / ITU and ANSI X9 have developed an X.509 version 3 (V3) certificate format. The V3 format is added to the V2 to add an additional field (extension field) by extending. Special extension field types can be defined and registered in the standard or may be defined and registered with any organization or community. In June 1996, the standardization of basic V3 format was completed [X.509].

At the same time ISO IEC / ITU, and ANSI X9 use development standards in V3 extension fields [X.509] [X9.55]. These extensions can express data such as additional subject confirmation information, key attribute information, policy information, and certificate path constraints.

However, ISO IEC / ITU and ANSI X9 standard extensions are very broad in their applications. In order to develop Internet using the X.509 V3 system, it is necessary to specify a common operation of both sides, which is necessary for the use of X.509 V3 to expand the use of the Internet. It is a goal of this article, specifies a text as an Internet WWW, email, and IPsec app. At the same time, as an additional requirement environment can be constructed or can replace it.

3.2 Certificate Path and Trust

Users as a security service typically require a public key to obtain and require knowledge of public key verification certificates. If the public key user does not have a public key copy, CA name and related information (such as validity period and name constraint) issued by the CA, and then it may require an additional certificate to obtain an open key. In general, a series of multiple certificates issued by CA issued a multi-certificate public key owner (end entity) and other CAS issued or more additional CAS certificates. Such a chain is referred to as a certificate path because a public key user is issued only by the number of limited CAs.

CAS can have different ways to be configured to disclose the key user to find the certificate path. In PEM, RFC 1422 defines the structure of the stringent hierarchy system of CAS. There are three types of PEM certificate Authorization Center: (a) Internet Policy Registration Authorization Center (IPRA): This Authorization Center As the root of the PEM certificate rating system (level 1), the power of bazedal internet society. For the next level, the certificate is called PCAS. All certificates start with IPRA.

(b) Policy Authorization Center (PCAS): Each PCA is authorized by the IPRA rating system, and PCAS is at level 2 in the level development. PCA will establish and publish a statement on confirming the user or subordinate authentication authority (authorities) policy. Different PCAS objectives are in line with different users. For example, a PCA (a tissue PCA) can support the needs of universal email business organizations, while another PCA (high-assocaration) can have a more stringent strategy design to meet the signature requirements of the legal bundled numbers. .

(c) Authorization Center (CAS): CAS is Level 3 at the level system, possibly also at a low level. PCAS is authorized by PCAS level 3. CAS represents special organizations, such as units of specific organizations, such as regions, organizations, sectors, or specific geographic areas.

In addition, the RFC 1422 has a word lower-level definition rule that requires a CA only a certificate (in the X.500 name tree) for the name (in the X.500 name tree). Using the PCA name means linked trust and a PEM certificate path. Name subordinate definition rules ensure that CASs below PCA are sensitive to their dependent entities (for example, a CA can only verify entities in that particular organization name tree). The certificate user system has the ability to use the machine to check the rules defined by the name under the name.

RFC 1422 uses the X.509 V1 certificate format. The limitations of X.509 V1 require a few structures that clearly limit the combined strategy or limit the function of the certificate. These restrictions include:

(a) accompanied by all the pure up-down (top-down) rating system from the certificate path starting from IPRA;

(b) Limit a CA's theme name subordinate naming rule;

(c) Use knowledge of knowledge that requires personal PCAS to construct a certificate logic to verify the concept of verification chain. The knowledge of personal PCAS decides whether the chain can be accepted.

After the RFC 1422 called request to use the certificate extension, use X.509 V3 without limiting the use of the CA structure. In particular, the certificate extension of the certificate policy is excluded from the needs of PCAS and the need for extended constraints exclude subordinate name definition rules. Therefore, this article supports more elastic certificate structures, including:

(a) The certificate path can start with the public key of the public key or the top of the CA's public key or the top of the CA's own domain. The public key of the CA began in its own domain of the user does have an advantage. In some environments, the local area is the most trusted.

(b) Name constraints can be explicitly received by the name constraints in the certificate, but not as required.

(c) Policy extension and policy mapping replace the automated PCA concept allowed to a certain degree. The application should be able to decide whether to accept the certificate path to establish a directory of a certificate that replaces the prior knowledge of PCAS. This allows automation of the certificate chain processing.

3.3 revoked

When a certificate is issued, it is expected to be used throughout its validity period. However, a variety of conditions may cause a certificate to become invalid before the validity period. This situation contains changes in the name, combined between the subject and CA (for example, an employee ends in an organization's work), and damage or doubt the corresponding private key. In this case, CA needs to revoke the certificate.

X.509 Defines a way to revoke a certificate. This method requires CA to periodically publish the data structure called the CA signature of the certificate revocation list (CRL). The CRL is a list of free release of the CA signature that covers the time seal to identify the revocated certificate. Each revocation certificate is identified by the certificate serial number in the CRL. When a certificate uses a certificate (for example, verifying a digital signature of a remote user), the system not only needs to verify the certificate signature and validity and need to verify the verification sequence number in the recently released CRL. The "recently released" is likely to change the local policy, but it usually means the most recent CRL. CA releases a new CRL in accordance with normal cycle (eg, every hour, daily or week). It is also possible that the next new information will be added to the CRL as the revocation notice comes. This moment may appear shortly after a normal CRL release cycle, and stay away from the next release. This advantage of this canceled algorithm is that CRLs can accurately and post the same approach via untrusted communication and server systems.

A limitations of the CRL revocation algorithm are the time particle size of the CRL issuance cycle with untrusted communications and servers. For example, if the revocation is released, the revocation will not guarantee the notification certificate application until the next cycle CRL is released, which may be an hour, one day or week, CA release CRS depends on the frequency.

As with the X.509 V3 certificate format, in order to facilitate tools to operate from multiple vendors, the X.509 V2CRL format should be the description of the contour for the Internet. This is (specified) a goal of this article. However, this article does not require CAS to issue CRLs. Support online revocation notification information format and protocol can be defined in other PKIX text (found). The online method of revoking notifications can be applicable to the environment where you can choose X.509 CRL. Online revocation checks can be reduced in considerable extent to (a copy) between revocation reports and information allocation dependence on both sides. Once the receptible report is reliable and effective, any online service issue will correctly reflect the revocation certificate approval. However, these methods require new security requirements; when the repository should not be trusted, the certificate effectiveness will count on online approval services.

3.4 Operation Agreement

The operation protocol requires the certificate and CRLS (or status information) to the customer certificate application. Different transfer are provided for a variety of certificates and CRLs, including the release process based on LDAP, HTTP, FTP, and X.500. A draft that supports these operations is explained in other PKIX text descriptions. These documents describe the information format and the environment that supports all of the above operations, including definitions suitable for the MIME content type or the reference process.

3.5 Management Agreement

The management protocol needs to support online interactions between PKI users and management entities. For example, the management protocol can be used between the CA and the client system as the associated key pair, or cross-authentication between the two CAs. This set of features should potentially follow the management protocol, including:

(a) Register: This is a process, and it is known to the CA published certificate by itself, where the CA is "directly or passed RA).

(b) Initialization: Before a customer system can safely operate, it is necessary to install the key to other places whose key suitable for the storage key is necessary. For example, the customer should safely use the public key of trusted CA (S) and another insured information to initialize the valid certificate path. In addition, a customer (typ) should be initialized with its own key.

(c) Certification: This is a process, where CA issues a certificate for a user's public key, and passes the certificate to the user's client system and / or posts the certificate in the warehouse. (d) Key pair recovery: As an option, the user client key (for encrypted user private key) can be backed up by the CA or key backup system. If the user needs to recover these backup keys, (for example, when you forget the password or lose the key chain file), a online communication protocol that supports such recovery is required.

(e) Key pair updates: All key pairs require regular updates. For example, replace a new key pair, publish a new certificate.

(f) Undo request: An authorized person notifies that CA requires a certificate that will be in an abnormal situation.

(g) Cross-certification: Two CAS exchange knowledge is used to establish a cross-certification certificate. The cross-certification certificate is a certificate issued by a CA that has been given to another CA.

Note that the online protocol is not the only way to perform the above functions, as well as the offline method of the same result, which is described herein as an invisible online protocol. For example, when the hardware device is used, many features can be implemented as part of the physical device. Furthermore, some of the above functions can be merged into protocol exchange (Protocol Exchange). Special, two or more registration, initialization, and certificate functions can be combined into an protocol exchange.

The text description of the PKIX series can define a set of standard information formats to support the future text of the above features. If so, the protocols expressing these information (eg, online, file transfer, E-mail, and www) will be depicted in those texts.

4 certificates and certificate extensions

This part puts forward the open key certificate summary, which will help development can be operated by both sides and reuse the PKI system. This part is based on the X.509 V3 certificate standard format and the standard certificate extension is defined on [X.509]. ISO IEC / ITU file uses a 1993 version of ASN.1 syntax; however, this article uses 1988 asn.1 syntax, but certificate coding and standard extensions are equivalent. This part also defines a private extension that supports the Internet community PKI system.

Certificates can be used in a wide application environment that covers broadly operated by both parties as an environment in the target and a wide range of operations and certification requirements. The goal of this paper is to establish a shared baseline for a wide range of environments requiring a common operation and limited special purpose purposes. In particular, emphasizing the Support X.509 V3 certificate application in informal Internet email, IPsec, and WWW.

4.1 Basic certificate field

The basic syntax of the X.509 V3 certificate is as follows. To the signature calculation, the certificate is passed according to the ASN.1 Syntax (DER) [X.208] rule. ASN.1 DER encoding is a label, length, value encoding system corresponding to each element.

Certificate :: = sequence {Tbscertificate Tbscertificate, SignatureAlgorithm Algorithmidentifier, SignatureValue bit string}

TBSCertificate :: = SEQUENCE {version [0] EXPLICIT Version DEFAULT v1, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, - If present, version shall be v2 OR V3 SubjectUnique [2] Implicit Uniqueidentifier Optional, - IF present, Version Shall Be V2 or V3 Extensions [3] Explicit Extensions Optional - IF present, Version Shall Be v3} version :: = integer} version :: = integer {v1 (0), V2 (1), V3 (2)}

CertificateserialNumber :: = integer

Validity :: = sequence {Notbefore Time, NOTAFTER TIME}

Time :: = choice {utctime utctime, generaltime generalizedtime}

UNIQUEIDENTIFIER :: = Bit String

SubjectpublicKeyInfo :: = sequence {Algorithm Algorithmidentifier, SubjectPublicKey bit string}

Extensions :: = sequence size (1..max) of extension

Extension :: = sequence {EXTNID Object Identifier, critical boolean default false, ext nValue octet string}

The following sessile items define the X.509 V3 certificate used in the Internet.

4.1.1 certificate field

Certificate is a field of three serials. These fields will be drawn in detail in the following sections.

4.1.1.1 Tbscertificate

This field contains the names of the subject and issuers, the open key, validity period, and other related information linked to the topic. Fields are described in detail in Section 4.1.2; field TBSCERTIFICATE can also include the extensions described in Section 4.2. 4.1.1.2 SignaRgorithm

The SignatureAlgorithm field contains a CA issued a password algorithm identifier used. Section 7.2 lists the supported signature algorithms.

A algorithm identifier is determined by the following ASN.1 structure:

Algorithmidentifier :: = Sequence {Algorithm Object Identifier, Parameters Any Defined by Algorithm Optional}

Algorithm identifier is used to identify algorithms of password. The Object Identifier component identifies (eg, the DSA) algorithm of SHA 1). The content of the optional parameter field will be changed according to the identified algorithm. Section 7.2 lists the algorithms supported by this article.

This field must (MUST) contains the same algorithm identifier in the sequence TBSCERTIFICATE (see 4.1.2.3).

4.1.1.3 SignatureValue

The SignatureValue field includes a digital signature encoded for TBSCertificate's ASN.1 DER. TBSCERTIFICATE ASN.1 DER Encoding as an input parameter for signature functions. This signature result value is then encoded as an ASN.1 of the bit string type and includes in the signature field of the certificate. This process is described in detail for each support algorithm (performed) in Section 7.2.

By generating digital signatures, CA can prove the validity of information in the TBSCERTIFICATE field. In particular, CA can authenticate the binding of the subject of the key and certificate in the certificate.

4.1.2 TBSCERTIFICATE

Sequence TBSCERTIFICATE contains information linked to the topic of the CA issuance certificate. Each TBSCertificate contains the name of the subject and the issuer; and the public key, validity period, version number, and serial number associated with the topic; some optional unique identifier fields. This part of the remaining part describes the syntax and semantics of these fields. TBSCERTIFICATE can also include an extension. The extended portion is depicted in Internet PKI (in part) 4.2.

4.1.2.1 Version

This field depicts the version of the coded certificate. When the extension is used, the X.509 version 3 (value 2) is used as expected in this article. But if there is no extension, UNIQUEIDENTIFIER will exist, when using version 2 (value 1). If only the basic field exists, use version 1 (as the default value, the version number will be deleted in the certificate).

(Certificate System Application) The tool should be prepared to accept any version of the certificate. Minimum, the tool (MUST) must be able to identify the certificate of the third edition.

The generation of the second version is not a description object expected in this article.

4.1.2.2 serial number

The serial number is CA assigned an integer to each certificate. It must (MUST) is the only identification of a certificate issued by a particular CA (ie, the issuer name and serial number uniquely identify a certificate).

4.1.2.3 Signature

This field contains an algorithm identifier, which is an algorithm for signing the CA on the certificate.

This field must (MUST) contains the same algorithm identifier as the SignatureAlgorithm field in the sequence certificate (see 4.1.1.2). The content of the optional parameter field will be changed according to the identified algorithm. Section 7.2 lists the supported signature algorithms. 4.1.2.4 Publisher

The issuer field is used to identify entities that sign and issued on the certificate. The issuer field must be (MUST) contains a non-empty ability to identify the name (DN). Define the publisher field as the X.501 type name. [X.501] The name is determined by the following ASN.1 structure:

Name :: = choice {rdnsequence}

RDNSEQUENCE :: = sequence of relativeiStinguishedName

RelativedistinguishedName :: = set of attributeTypeAndValue

AttributeTypeAndValue :: = sequence {Type AttributeType, Value AttributeValue}

AttributeType :: = Object Identifier

Attributevalue :: = any defined by attributetype

DirectoryString :: = CHOICE {teletexString TeletexString (SIZE (1..MAX)), printableString PrintableString (SIZE (1..MAX)), universalString UniversalString (SIZE (1..MAX)), utf8String UTF8String (SIZE (1 .. Max)), bmpstring bmpstring (size (1..max))}

Name (Name) depicts the name property of a grade system, such as the national name and the corresponding value, such as US. The ingredient of Type AttributeValue is determined by AttributeType; generally it will be a DirectoryString (type).

The DirectoryString type is defined as a choice for PrintableString, TeletexString, BmpString, Utf8String, and UniversalingTring. UTF8String encoding is the preferred code of DirectoryString, and all certificates issued after December 31, 2003 (Must) use UTF8String encoding (just as indicated below). Until that date, CAS must be selected in the following selection when creating a distinguished name, including themselves:

(A) If the character set is sufficient, the character can be described as a printableString;

(B) Failure (a), if the bmpstring character set is sufficient, the characters can be described as a bmpstring; and (c) fail (a) and (b), the character must be described as a UTF8String. If (a) or (b) is satisfied, the CA can (may) still prefer to describe the character as a UTF8String.

Exceptions from UTF8 coding requirements on December 31, 2003 are as follows:

(A) CAS can issue "Name Rollover" ("Name Rollover") supports a migration certificate that has always been UTF8String encoded. Such a certificate will contain CA as an issuer UTF8String encoded name and an old name encoding as the subject, or vice versa.

(B) CAS indicates in Section 4.1.2.6, the subject field must (MUST) There is a non-empty recognizable name that is matched by the topic CA regardless of the issuer field in all certificates issued.

TeletexString and Universalingtring are contracted (sexually) and should not be used for new topics. However, these types can be used in the certificate existing before the name. The certificate user should be prepared to accept the certificate in these types.

In addition, many legacy tools support the names in the ISO 8859-1 character set (Latin1String), but use TeletexString as their label. Latin1String is included in the Western European countries that are not part of the TELETEXSTRING character set. Processing TeletexString tools should be prepared to handle the entire ISO 8859-1 character set. [ISO 8859-1]

Again, the identifiable name consists of attributes. This article explains that no limitations can appear attribute types. However, the tool must be prepared to accept the certificate with the issuer name, and the issuer name contains the following identified attribute type. This article shows that additional properties are also supported.

Standard set properties are defined in the X.500 series of documents. The [X.520] tool for this article must be prepared to accept the following standard attribute types in the issuer name (included): national, organizational, organizational unit (Organizational-unit), qualifyable name , National or provincial name and common name (such as "Susan Housley"). In addition, the tool described herein should be prepared to receive the following in the issuer's name: region, topic, surname, name, starting letter and generating limitations (such as "JR.", 3rd "or" iv "). These attribute type syntax and phantom identifiers (OIDs) provide instructions in ASN.1 modules in Appendix A and B.

In addition, the tools described herein must accept the domaincomponent attribute as the [RFC 2247] defined. The Nameserver system (DNS) is provided as a method for labeling the tag rating system. This attribute is provided to organize a convenient mechanism that would like to use DNS and their DNS name parallel. This is not an alternative to the DNSNAME component of the replacement name field. The tool does not need to turn this name into a DNS name. This attribute type syntax and the combined OID are provided in the ASN.1 module in Appendix A and B. The certificate user must (MUST) is a name chain (part 6) that is prepared to process the issuer identifier name and the subject identification name (see 4.1.2.6) to execute the active path of the certificate (part 6). The name chain is executed by the name issuer that can be identified in a certificate with the CA certificate theme name.

This article describes only one subset name that is similar to the functionality of the functionality in the X.500 series document. Make the tools as follows:

(A) can be assumed to represent different characters, the attribute value is encoded in different types (such as PrintableString, and BMPString);

(B) In addition to the PrintAbleString type, the attribute value is case sensitive (this allowed attribute value and binary object match);

(C) In the printablestring, the attribute value is not case sensitive (for example, "Marianne Swanson" and "Marianne Swanson"); and

(D) After removing spaces of the head and tail and the conversion of one or more consecutive spaces in the inner substring are a single space, the attribute values in printableString can be compared.

These name comparisons allow a certificate user to verify the validity of the certificate that is not familiar with the certificate user or the certificate issued.

In addition, the tools described herein can use these comparisons to use these comparisons to process unfamiliar attribute types. This allows tools to handle certificates with attributes that are not familiar with in the issuer's name.

Note that the comparison rules defined in the X.500 Series document indicate that the character set used to encode the data encoded in the identifiable name is irrelevant. Character (them) itself is compared and does not care about encoding. Allow this article to use the comparison algorithm defined in the X.500 series document. Such a tool will recognize the matching name superchard through the previously specified algorithm.

4.1.2.5 Validity

The validity period of the certificate is time interval, during which CA guarantees it will keep information about the status. Describe the field as a series of sequence: NOTBEFORE and date certificate validity period ends (Notafter). NOTBEFORE and NOTIAFTER can be encoded as utctime or generalizedtime type.

In this article, the CAS must be used as a UTCTIME type encoding in 2049; in 2050 or after the certificate validity date (MUST) is encoded as GeneralizedTime type.

4.1.2.5.1 Utctime

World Time (UNIVER TIME) type, Utctime is a standard ASN.1 type as an international application because local time is not suitable for international applications. UTCTIME is specified by two low order numbers and specified to a minute to one minute or second. UTCTIME contains (Zulu or Greenwich Time) Z or a time differentiation.

In this description, the UTCTIME value must be (MUST) is the Greenwich Time Representation (Zulu) and must (MUST) contains seconds (ie, time (format) YYMMDDHHMMMSSZ), or even the number of seconds is equal to zero. The system must (Must) Explain the Year Field (YY): When YY is equal to 50, the year will be considered 19yy; and

When YY is less than 50, the year will be considered 20yy.

4.1.2.5.2 GeneralizedTime

Universal time type, GeneralizedTime is a standard ASN.1 type of time variable accuracy. Feelings, the GeneralizedTime field can contain a representative of time differentiation between local and Greenwich time.

For the goal of this article, the generalizedtime value must be (MUST) is the Greenwich Time Representation (Zulu) and must (MUST) contains seconds (ie, the time format is YYYMMDDHHMMMMSSZ), even the number of seconds is equal to zero. The generalizedtime value must not contain the decimal second (Fractional Seconds).

4.1.2.6 Theme

The subject field identifier is associated with a key entity stored in the topic public key field. The subject name and / or it is included in the SubjectAltAme extension. If the theme is a CA (for example, as discussed in 4.2.1.10, the basic constraint extension existence and the value of the CA are true (TRUE), the subject field must be (MUST) is an identifiable name with a non-empty recognition The existence, the certificate of the issuer (see 4.1.2.4) is matched in all the subject CAs (see 4.1.2.4). If the topic name information exists only (for example, a key is limited to an email address or URI), then the subject name must be an empty sequence and the SUBJECTALTNAME extension must be critical.

In its non-empty place, the subject field must contain an X.500 recognizable name (DN). DN must (MUST) for each subject entity is the only CA certificate defined by the issuer name field. A CA can issue multiple certificates with the same topic entity with the same DN.

The subject name field is defined as the X.501 type name. Tools (Applications) Requirements This field is defined by those issuer fields (see 4.1.2.4). When encoding the type DirectoryString property value, the encoding rules for the issuer field must be executed (MUST). The tools described herein must be prepared to receive the subject name of the attribute type recommended for the issuer field. The tool described herein should be prepared to receive the topic name containing the type of property that is recommended for the issuer field. These attribute type syntax and the combined object identifier (OIDS) are provided in Appendix A and the BASN.1 module. The tools described herein can use these similar rules to deal with these similar rules are not familiar with the property type (for example, for the name chain). This allows the tool to handle certificates in the subject names that are not familiar with attribute.

In addition, legacy tools are present in a RFC 822 name as the EmailAddress property being embedded in the identifiable name. As the ia5String type EmailAddress property value allows the character '@', which is not in the PrintableString character set. The EmailAdDress property value is not case sensitive (for example, "fanfeedback@redsox.com" is the same as Fanfeedback@redsox.com). As the email address enables a new certificate tool (MUST) to use RFC822Name (see 4.2.1.7) name depiction using RFC822NAME (see 4.2.1.7) in the topic field. At the same time, the EmailAddress property values that can be identified in the subject can be used to support legacy tools to be opposed, but allow (ie no prohibition).

4.1.2.7 Topic Publication Key Information

Use this field to carry the identifier of the public key and key using the algorithm. The algorithm is used to specify the Algorithmidentifier structure in Section 4.1.1.2. The object identifier is specified in section 7.3 as an encoding algorithm and method supporting the public key material (public key and parameters).

4.1.2.8 Unique identifier

These fields may only appear in version 2 or 3 (see 4.1.2.1). The unique identifier of the subject and issuers exists in the certificate to deal with the possibility of reuse of the time theme and / or the issuer name. This article recommends names that are not reused in different entities and the unique identifier of the Internet certificate is not used. CAS follows this article should not use a unique identifier to generate a certificate. Compliance with this article (program) should be a syntax that can parse the unique identifier and compare.

4.1.2.9 expansion

This field may appear only in version 3 (see 4.1.2.1). If there is, this field is one or more certificate extensions of a series. The format and content of the certificate extension in the Internet PKI will be defined in 4.2.

4.2 Standard Certificate Extension

A method of providing additional properties combined with a user or a public key and a certificate management rating system in an X.509 V3 certificate extension definition. The X.509 V3 certificate format also allows the community (a specific application environment - translator's note) defines the private scope for those communities carry unique information. Each extension in a certificate can be critical or non-critical. If you encounter a key extension that cannot be identified, the application system must refuse to accept this certificate; however, if the item that is not recognized is non-critical expansion, it can be ignored. The following sections are recommended to use extensions within Internet certificates and standard information. However, the community can choose to use additional extensions (for custom extensions for specific application environments - translator's note); however, should be careful to use any key expansion in the certificate, which can hinder in the general background (certification is universal application environment - - Certificate application in the translator's note.

Each extension contains an OID and an ASN.1 structure. When an extension occurs in a certificate, the OID is used as a field EXTNID and the corresponding ASN.1 structure in accordance with the value of the OCTET STRING EXTNVALUE. Only one specific extension can appear in a specific certificate. For example, a certificate can contain only one authority key identifier (see 4.2.1.1). An extension contains the Boolean type key value, the default value is false. The text specifies the value that accepts the key field for each extension.

CAS must support key identifiers (see 4.2.1.1 and 4.2.1.2), basic constraints (see 4.2.1.3), key applications (see 4.2.1.5) and certificate strategy (see 4.2.1.5) expansion . If the CA issues a null sequence topic certificate, the CA must support the option extension (see 4.2.1.7). Support remaining extensions is optional. CAS can support extended identifiers that are not recognized within this document; remind the certificate issuer to suppress such an extended mark key to suppress the common operation of both parties. Minimum, the application of this article must be identified in this article or possible extension. These extensions are: key applications (see 4.2.1.3), certificate strategy (see 4.2.1.7), basic constraint (see 4.2.1.10), name constraint (see 4.2.1.11) ), Strategy constraints (see 4.2.1.12) and key application extensions (see 4.2.1.13).

In addition, refommends supports the application extension of authority and topic key identifiers (see 4.2.1.1 and 4.2.1.2).

4.2.1 Standard Expansion

This section describes the standard certificates defined in the Internet PKI app [X.509]. [X.509] Each extension in the definition is linked to an OID. These OIDs are members of ID-ARC, defined as follows:

Translator Note: OID is the abbreviation of the Object Identifier, which is an object definition of global standards defined by international organizations. It is a tree structure, ID-ARC is a tree structure defined by ISO organization, interested Readers Please read the relevant documentation.

ID-CE Object Identifier :: = {Joint-ISO-CCIT (2) DS (5) 29}

4.2.1.1 Authoritative Key Identifier

The authoritative key identifier extension provides a means of identifying a means of public key corresponding to using a private key on a certificate. This extension is used for a distributor with multiple signature keys (also due to multiple simultaneous keywords or due to key replacement). The identifier can be built on any key identifier (the subject key identifier in the issuer's certificate) or on the distributor name and serial number.

The AuthorityKeyIdentifier extension The keyidentifier field must be included in all the certificates generated by the CAS compliance to make the chain build. There is an exception: A CA assigns its public key in the form of a "self-signature" certificate, and the authority key identifier can be deleted. In this case, the subject and authority key identifier will be exactly the same (equivalent).

The value of the KeyIdentifier field should be obtained from the public key that verifies the certificate signed or a method of generating a unique value (the value of the KeyIdentifier field generates algorithm - Translator Note). Two universal methods from the public key generated key identifier are described in 4.2.1.2. A general method that produces a unique value is described in Section 4.2.1.2. Because a key identifier has not yet been established, this paper recommends a use of KeyIdentifiers in these methods.

This article recommends (use) algorithms for all certificates users support key identifiers.

This extension must not be mounted as a key (Must NOT).

id-ce-authorityKeyIdentifier OBJECT IDENTIFIER :: = {id-ce 35} AuthorityKeyIdentifier :: = SEQUENCE {keyIdentifier [0] KeyIdentifier OPTIONAL, authorityCertIssuer [1] GeneralNames OPTIONAL, authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL}

KeyIdentifier :: = o o c o

4.2.1.2 Topic Key Identifier

The subject key identifier extension provides a means of identifying a certificate including a specific public key.

In order to facilitate the chain (certificate chain), this extension must appear in all CA certificates, that is, all certificates contain basic constraints (see 4.2.1.10) The value of its CA is TRUE. The value of the subject key identifier must be (MUST) is a key identifier field that is placed in accordance with the subject value of this certificate (see Section 4.2.1.1).

Like the CA certificate, the subject key identifier should be obtained from the public key or the unique value method. The two general methods from the public key generated key identifier are as follows:

(1) Keyidentifier consists of 160-bit Sha1 hash values of the value of Bit String SubjectPublicKey (excluding tag, length, and BITS number).

(2) Keyidentifier four bit type field value is 0100 and subsequently consists of the last 60 bits connection in the value of the value of Bit String SubjectPublicKey SHA 1 hash.

A universal method that generates a unique value is an integer Monotomically incremented sequence.

For a terminal entity certificate, the subject key identifier extension provides a means of identifying a certificate contained in an application using a specific public key. One-end entity has received multiple certificates, especially from multiple CAS, the subject key identifier, provides a resort that includes a specific public key certificate. To help identify the end entity certificate in application, this expansion should be included in all end entities.

For a terminal entity certificate, the subject key identifier should be obtained from the public key (SHOULD). Two general methods from the public key generated key identifier are described above.

Because a key identifier has not yet been established, this document describes a key identifier that generates these methods.

This extension must not be tagged as the key.

ID-CE-SUBJECTKEYIDENTIFIER OBJECT IDENTIFIER :: = {ID-CE 14}

SubjectKeyIdentifier :: = Keyidentifier

4.2.1.3 Key Use

The key uses the extension definition to include the purpose of the key to the certificate (eg, encryption, signature, signature). When a key can be used to exceed one operation (beyond the key application range-translator note), the key usage limit can be used. For example, when an RSA key should be used only for signature, the DigitalSignature and / or NonRepudiation bit (valid, set to 1 - translator's note). Similarly, when a RSA key should be used only for key management, the KeyEncipherment bit will be asserted. This extension should be marked as the key when used. ID-CE-Keyusage Object Identifier :: = {ID-CE 15}

Keyusage :: = bit string {DigitalSignature (0), NonRepudiation (1), Keyencipherment (2), DataENCIPHERMENT (3), Keyagreement (4), KeyCertsign (5),

CRLSIGN (6), Encipheronly (7), Decipheronly (8)}

Use the middle bits (BITS) in the Keyusage type:

The DigitalSignature bit is asserted that when the subject disclosure key uses a number of signature algorithms to support security services rather than resistance (bit 1), signature certificate (bit 5) or signature cancellation information (bit 6). Digital signature algorithms are often authenticated for entities and data origin (done) integrity.

The NonRepudiation bit is asserted that when the subject disclosure key is used to verify the digital signature provided by the defendable service, its signature entity avoids the hazards caused by some of the faked rejection, these actions exclude the signing certificate or CRL.

The KeyEncipherment bit is asserted that when the subject disclosure key is used for key transmission. For example, when a RSA key is used for key management, then this bit will be asserted.

When the subject disclosure key is used (in addition to the cryptographic key), the DataEncipherment bit is asserted.

The Keyagreement bit is asserted that when the subject disclosure key is used for the key protocol. For example, when a Diffie Hellman key is used for key management, then this will be asserted.

When the subject disclosure key is used to verify the signature used on the certificate, the KeyCertsign bit is asserted. This can be asserted only in the CA certificate.

When the subject disclosure key is used to verify the use of cancellation information (such as a CRL) signature, the CRLSign bit is asserted.

The Encipheronly bit is defined when there is no Keyagreement bit (absent). When the Encipheronly bit is asserted and the KeyAgreement bit is also set, the subject public key can be used only to use data encryption (encryption) and perform the key protocol. The Decipheronly bit is defined when there is no Keyagreement bit (absent). When the Decipheronly bit is asserted and the Keyagreement bit is also set, the topic public key can be used only to translate data (decryption) and perform the key protocol.

This article is not limited to the binding of those bits in the Keyusage extension example. However, the designated suitable value is expanded as a specific algorithm key in section 7.3.

4.2.1.4 Private Key Use Period

This article is recommended against this expansion. CAS complies with this article must generate a certificate when a private key usage period is a key expansion.

Private Key Use Period Extensions Allow certificate issuers to distinguish different validity cycles for private key compared to certificates. This extension intends to use to use the signature key for numbers. This is extended by two optional components, Notbefore and Notafter. The private key associated with the certificate should not be used in advance or after the time specified by the two ingredients. CAS unless at least two components, comply with this article must generate a certificate when it exists in a private key.

Where used, as in section 4.1.2.5.2, it is described as GeneralizedTime (MUST) to specify NOTBEFORE and NOTAFTER.

ID-CE-privateKeyusagePeriod Object Identifier :: = {ID-CE 16}

PrivateKeyusagePeriod :: = sequence {notbefore [0] generalizedTime Optional, Notafter [1] generalizedtime optional}

4.2.1.5 Certificate Strategy

The certificate policy extension includes one or more policy information entries, each of which is identified by an object identifier (OID) and an optional language. These strategy information clauses indicate the purpose of the policy and certificate issued under its certificate to be used. An optional qualifier that can be present is not expected to change the definition of the policy.

It is expected that there is a list of strategic requirements, and compare the policy OIDS and the list in the certificate. If this extension is critical, the path verification software must be understood by understanding this (including optional qualifiers) extended, otherwise the certificate must be discarded.

In order to promote the interoperability of both parties, the Recommends policy information entries are composed of only one OID. In the case of insufficient OID, this paper strongly recommends that those limitations are identified in this section.

This article is two policy qualifications that have been defined by the certificate policy writing and certificate issuer. Limitable types are CPS Pointer and User Notice.

The CPS Pointer Library contains a pointer to the certification (CPS) certificate (CPS) certificate (CPS) certificate. The pointer is the format of the URI.

When the certificate is used, User NOTICE will display the dependent part. Application (Software) should show all users of the Certificate path (USER NOT), in addition to the copy demand, if the Note is represented. In order to obstruct this copy, this limiting is only in the CA certificate existing in the end entity (end-entry) certificate and issuing it to other organizations. Users Note (user notice) There are two optional fields: NoticeRef fields and ExplicitText fields.

If you use the NoticeRef field through a number (a statement of the special original text of the organization), you will be named. For example, it can identify organizational "Certsrus" and Number 1. In a typical tool, the application (software) will have one to contain the current note (notices) certificate: Application will pick attention from the file and display it. Information can be a specific language information to select a specific language information in a variety of language.

The ExplicitText field directly contains the statement of the original text. The ExplicitText field is a string of up to 200 characters.

If you are included in a qualified language in NOTICEREF and ExplicitText and if the application can find the text that follows the NoticereF option indicates a note, then the text should be displayed; in addition, the ExplicitText characters should be displayed.

ID-CE-CERTIFICATEPOLICIES OBJECT IDENTIFIER :: = {ID-CE 32}

CertificatePolicies :: = Sequence size (1..max) of policyinformation

PolicyInformation :: = sequence {policyid, policyqualifiers sequence size (1..max) of policyqualifierinfo optional}

CertpolicyID :: = Object Identifier

PolicyqualifierInfo :: = Sequence {PolicyQualifierid PolicyqualifierId, Qualifier Any Defined by PolicyqualifierId}

- PolicyQualifierids for Internet Policy QualifierS

ID-Qt Object Identifier :: = {ID-PKIX 2} ID-QT-CPS Object Identifier :: = {ID-QT 1} ID-QT-UNOTICE OBJECT Identifier :: = {ID-Qt 2}

PolicyQualifierid :: = Object Identifier (ID-QT-CPS | ID-QT-UNOTICE)

Qualifier :: = choke {cpsuri cpsuri, usernotice usernotice} cpsuri :: = ia5string

UserNotice :: = sequence {Noticref NoticReference Optional, ExplicitText Displaytext Optional}

NoticReference :: = sequence {Organization Displaytext, NoticenumBers Sequence of Integer}

Displaytext :: = kice {visibleString VisibleString (size (1..200)), bmpstring bmpstring (size (1..200)), uTF8String Utf8String (Size (1..200))}

4.2.1.6 Policy mapping

This extension is used in the CA certificate. It lists one or more pairs of OIDs; each pair contains IssuerDomainPolicy and SubjectDomainPolicy. Pairing instructions for issuing CA think it's IssuerDomainPolicy is equal to SUBJECTDOMAINPOLICY for the subject CA.

A user who is issued for a particular application can accept a IssuerDomainPolicy. Policy mapping The CA user of the policy that issues associated with the topic CA can be compared to the policies they accept.

This extension can be supported by CAS and / or application, and it must be non-critical.

ID-CE-PolicyMappings Object Identifier :: = {ID-CE 33}

Policymappings :: = sequence size (1..max) of sequence {issuerdomainPolicy CertPolicyId, SubjectDomainPolicy CertpolicyId}

4.2.1.7 Topic Replacement Name

The subject replacement name extension allows additional identifiers as the subject of the certificate. Definition options contains Internet email addresses, DNS names, IP addresses, and Uniform Resource Identifier (URI). Other options exist and include a complete local definition. Multi-name forms and multiple cases of each name can be included. Whenever the same identifier is to be bound into a certificate, the subject optional name (or the issuer can replace the name) extension must be used.

Because the subject replacement name is considered to be combined with the public key, all parts of the subject optional name must be verified by CA.

Further, if only the topic identity is included in the certificate, it is an alternative name form (such as an email address), then the subject recognizable name must (Must) is empty (empty sequence) and the SubjectAltName extension must exist. If the topic field contains a nacular sequence, the SubjectAltName extension must be a markup.

When the SubjectAltAme extension includes an Internet post address, the address must be included as an RFC822NAME. The format of RFC822NAME is a "addr-spec" as defined in RFC 822 [RFC 822]. The AddR-SPEC format is "local-part @ domain". Note that there is no (for example, a universal name) phrase before ADDR-SPEC, there is no Comment (Text Surrounded In ParentheSes) and there is no "<" and ">" surrounded. Note that the uppercase and lowercase characters in RFC 822 AddR-SPEC are allowed, which is not case sensitive. When the SubjectAltName extension contains an ipdress, the address must be specified in RFC 791 [RFC 791], stored in the "NetWork Byte Order" eight characters. The least significant bit (LSB) of each eighth is the LSB of the corresponding byte in the network address. As the IP version 4 specified in RFC 791, the eight characters must contain exactly four eight digits. As the IP version 6 specified in RFC 1883, the eight characters must be (MUST) contains just sixteen eight [RFC 1883].

When the SubjectAltName extension includes a domain name service tag, the domain name must be stored in DNSNAME (IA5String). The name must be as specified by RFC 1034 [RFC 1034], in "Preferred Name Syntax". Note that uppercase and lowercase characters are allowed in the domain name, and in this case it is not case sensitive. Also "" (space) is a legitimate character in the domain name, while the SubjectAltAme extension "" (space) of DNSNAME is not allowed. Finally, the use of DNS represents the Internet post address (instead of WPOLK.NIST.GOV) is not allowed; such an identifier is to be encoded as RFC822NAME.

When the SubjectAltName extension contains a URI, the name must be stored in UniformResourceIdentifier (IA5String). The name (MUST) is unrelated to the URL and must (MUST) The URL syntax and coding rules defined in [RFC 1738]. The name must contain two modes (such as "http" or "ftp") and scheme-specific-part. Scheme-Specific-Part must contain a full qualified domain name or IP address as a host.

As in [RFC 1738] defined, the schema name is not case-sensitive (for example, "http" is equal to "http"). The host part is not sensitive, but other ingredients of Scheme-Specific-Part can be sensitive. When comparing URIs, the guaranteed tool must (MUST) compare Scheme and host regardless of case, but think that the remaining parts of Scheme-Specific-Part is sensitive. The subject replacement name is as constrained in the same manner as the subject identification name is intended in part 4.2.1.11.

If the SubjectAltName extension exists, the sequence must contain at least one entry. Unlike the topic field, the CAS follows must be issued with SubjectAltNames with empty generalname fields with empty generalname fields. For example, describe RFC822NAME as IA5String. While an empty string is effective IA5String, such RFC822NAME is not allowed herein. When the customer (software) is processed, the customer (software) is not defined herein.

Finally, the aquaryism (e.g., a topic of a set of names) is not in this article. As specific requirements applications can use such names, but to define semantics.

ID-CE-SUBJECTAME OBJECT Identifier :: = {ID-CE 17}

Subjectaltname :: = generalnames

Generalnames :: = sequence size (1..max) of generalname

GeneralName :: = CHOICE {otherName [0] OtherName, rfc822Name [1] IA5String, dNSName [2] IA5String, x400Address [3] ORAddress, directoryName [4] Name, ediPartyName [5] EDIPartyName, uniformResourceIdentifier [6] IA5String, iPAddress [ 7] OcTet string, registeredid [8] Object Identifier}

Othername :: = sequence {type-id object identifier, value [0] explicit any defined by type-id}

EDIPARTYNAME :: = sequence {namessigner [0] DirectoryString Optional, PartyName [1] DirectoryString} 4.2.1.8 Publissers can replace the name

Like 4.2.1.7, use this extension to link Internet Type Identifiers and certificate issuers. The issuer replaces the name (MUST) is the way it is described in Section 4.2.1.7.

Current situation, this extension should not be labeled as the key.

ID-CE-ISSUERALTNAME OBJECT IDENTIFIER :: = {ID-CE 18}

Issueraltname :: = generalnames

4.2.1.9 Topic Directory Service System Properties

The subject directory service system attribute extension is not recommended as part of this article, but it can be used in the local environment. This expansion must be non-critical.

ID-CE-SUBJECTDIRECTORTTRIBUTES Object Identifier :: = {ID-CE 9}

SubjectDirectoryAttributes :: = sequence size (1..max) of attribute

4.2.1.10 Basic constraint

Basic constraint extensions identify whether the subject of the certificate is a CA and a certificate path through CA.

Only if the CA is set to True, then the PathlenConstraint field is meaningful. In this case, it gives the number of the maximum CA certificate (the length of the certificate chain - the translator's note), which can be coming from the certificate in a certificate path. Zero Value Indicates that only one end entity can enter along the path. It appears where the PathlenConstraint field must be greater than or equal to zero. PathlenConstraint does not appear, in fact, there is no limit to the allowable length of the certificate path.

This extension must appear to be key expansion in all CA certificates. This expansion should not appear in the end entity certificate.

ID-CE-BasicConstraints Object Identifier :: = {ID-CE 19}

BasicConstraints :: = sequence {CA Boolean Default False, Pathlenconstraint Integer (0..max) Optional}

4.2.1.11 Binding of the name

Name Constrained Extensions Indicates a word space, must (Must) is only used in a CA certificate, in a certificate path, the subject name in the subsequent certificate will be found. Restrictions can apply an identifiable name or a subject replacement name on the subject. Application is filed only when the specified name is present. If there is no type of name in the certificate, the certificate is acceptable.

Restrictions are defined in the name of the name of the name permitted or excluded. Regardless of the information that appears in PermittedSubtrees, any name that is equivalent to the ExcludedSubtrees field restrictions is invalid. This extension must be critical (MUST).

Within this paper, the lowest and largest field domains are not applied as any name, and therefore the lowest is always zero, and the maximum limit is always not present.

The constraint applies for URIS to the host part. Constraints can specify a host or domain. The example can be "foo.bar.com" and ".xyz.com". When constraints begin with a separator, it can be an expansion of one or more subdomains. That is to say, "XYZ.COM" is met by ABC.xyz.com and abc.def.xyz.com. However, constraints ".xyz.com" is not met "xyz.com". When the constraint does not start with a separator, it specifies a host. Constraints for the INTERNAT post address can specify a specific mailbox, all in a particular host address or all mailboxes in a domain. Indicates a specific mailbox and constraint is a complete post address. For example, "root@xyz.com" indicates the mailbox on the host "xyz.com". Description All Internet Postal Address on a particular host, specify constraints as host name. For example, constraint "xyz.com" is satisfied by any post address in the host "xyz.com". Specifies any address within the domain, specified with a lead partition constraint (and URIS). For example, ". Xyz.com" indicates that all Internet post addresses in the "XYZ.com" domain, but the Internet post address is on the host "XYZ.com".

DNS name restrictions are represented as foo.bar.com. Any subdomain satisfies the name constraint. For example, www.foo.bar.com will satisfy the constraint, but Bigfoo.Bar.com is not satisfied.

Legacy tools are present in the properties of RFC 822 embedded in a type EmailAddress (see 4.1.2.6) to identify the name topic. When the RFC822 name is limited, the certificate does not contain the topic replacement name, the RFC822 name constraint must be applied to the attribute of the EmailAddress type in the subject identification name. The EmailAddress ASN.1 syntax and the corresponding OID are supplemented in Appendix A and B.

The restrictions of form DirectoryName must be applied to the SubjectAltName extension applied to the subject fields and DirectoryName types in the certificate. The restrictions of form X400Address must be (MUST) is an SubjectAltName extension applied to the type X400Address.

When the application form DirectoryName is limited, the tool must compare the DN property (MUST). At a minimum, the tool must be fulfilled in Section 4.1.2.4 Specifies the DN comparison rules. CAS issued by the DirectoryName restricted certificate should not be trusted to trust the entire ISO DN name comparison algorithm. This hint name limit will be present in the same manner as the encoding used in the topic field or SubjectAltName extension.

The iPaddress's syntax must be as specifically depicted as in paragraphs 4.2.1.7. For IPv4 addresses, GeneralName's iPadDress field must (MUST) contains eight (8) OcTes, encoding in the RFC 1519 (CIDR) in the style of address. For IPv6 addresses, the iPadDress field must be (MUST) contains the same 32 OCTETS encoding. For example, for "Class C" name Constrained subnet 10.9.8.0 will be 0A 09 08 00 FF FF 00OCTS as an eight-bit representative, and the CIDR annotation represents 10.9.8.0/255.255.255.0. Unreasonable is defined herein as Othername, eDipartyname, and registered name constraints syntax and semantic.

ID-CE-NameConstraints Object Identifier :: = {ID-CE 30}

NameConstrains :: = sequence {permittedsubtrees [0] generalsubtrees optional, ExcludedSubtrees [1] generalsubtrees optional}

Generalsubtrees :: = sequence size (1..max) of generalsubtree

Generalsubtree :: = sequence {base generalname, minimum [0] Basedistance default 0, Maximum [1] Basedistance Optional}

Basedistance :: = integer (0..max)

4.2.1.12 Strategy Constraint

The policy constraint extension can be used in the issued CAS certificate. Policy constraint extension in two ways forced path verification. It can be used to prohibit policy maps or require that each certificate in the path contains an acceptable policy identifier.

If the InhiboLicymapping field exists, the value indicates the number of paths that can appear in the additional certificate before the policy mapping is no longer allowed. For example, a value indication policy mapping can be handled in a certificate issued in the subject of this certificate, but is not attached to the path.

If the RequireExPlicitPolicy field exists, the subsequent certificate will contain an acceptable policy identifier. Before a display policy is required, the value of RequireExPlicitPolicy indicates the number of additional certificates that can appear on the path. A acceptable policy identifier is a user who passes a certificate path or an identifier that is announced by policy mapping to a policy demand identifier.

Enable the CAS in accordance with the certificate to be issued in the policy constraint empty sequence. That is to say, at least one must (must) in the inhibolicymapping field or the RequireExPlicitPolicy field. When encountering an empty strategy constraint field, the behavior of the customer (software) is not described herein.

This expansion can be critical or non-critical.

ID-CE-PolicyConstraints Object Identifier :: = {ID-CE 36}

Policyconstraints :: = sequence {required {required [0] skipcepts optional, inhibolicymapping [1] Skipcerts Optional} Skipcerts :: = Integer (0..max)

4.2.1.13 Expanding key usage

This field indicates that one or more confirmed public keys increase or instead of the basic key to use the extension field indicated in the extension field. This field is defined as follows:

ID-CE-EXTKEYUSAGE OBJECT IDENTIFIER :: = {ID-CE 37}

EXTKEYUSAGESYNTAX :: = Sequence size (1..max) of keypurposeid

Keypurposeid :: = Object Identifier

The key purpose can be defined by any requirement. The object identifier is identified that the key purpose will be uniformly assigned to IANA or ITU TREC.X.660 | ISO IEC / ITU 9834-1.

This expansion can be extended in the options for the certificate issuer, and is both key and key.

If the extension is a key, the certificate must be used only one for the purpose of the destination.

If the extension is marked as a non-critical, it indicates that the preset purpose of the key may be used in the appropriate key / certificate in the entity that has multiple key / certificates. It is a consultant field and does not imply the limit of the use of the key to the authority of the certificate. Although such a certificate application can require a special purpose to indicate that the application can be accepted for that application.

If a certificate contains a key key to use the field and a key extended key to use the field, then the two fields must be independently processed and the certificate must be used only for the two fields. If there is no destination with two fields, then the certificate must not be used for any purpose.

This article determines the following key use:

ID-KP Object Identifier :: = {ID-PKIX 3}

id-kp-serverAuth OBJECT IDENTIFIER :: = {id-kp 1} - TLS Web server authentication - Key usage bits that may be consistent: digitalSignature, - keyEncipherment or keyAgreement - id-kp-clientAuth OBJECT IDENTIFIER :: = {ID-KP 2} - TLS Web Client Authentication - Key Usage Bits That May Be Consistent: DigitalSignature and / OR - Keyagreement - ID-KP-CODESIGNING Object Identifier :: = {ID-KP 3} - Signing of downloadable executable code - Key usage bits that may be consistent: digitalSignature - id-kp-emailProtection OBJECT IDENTIFIER :: = {id-kp 4} - E-mail protection - Key usage bits that may be consistent: DigitalSignature, - NonRepudiation, And / OR (KeyEncipherment - or Keyagreement) - ID-KP-TIMESTAMPING Object Identifier :: = {ID-KP 8} - Binding The Hash of An Object To a Time Fro M an AGREED-UPON TIME - Source. Key Usage Bits That May Be Consistent: DigitalSignature, - NonRepudiation4.2.1.14 CRL Release Point

The CRL publish point extension identifies how CRL information is obtained. The extension should be non-critical, but this paper is recommended to support this extension by CAS and applications. A further discussion of CRL management is included in the portion 5.

If CRLDISTRIBUTIONPOINTS extensions contain one type of URI's DistributionPointName, the following semantics must be assumed: URI is the reason and the current CRL that will be bonded to CRLISSUER. The expected value of the URI is defined in section 4.2.1.7. Processing rules about other values is not defined herein. If DistributionPoint deletes a reason, the CRL must (MUST) revokes all reasons. If DistributionPoint deletes crlissuer, the CRL must (MUST) is sent by the CA of the issuance certificate.

ID-CE-CRLDISTRIBUTIONPOINTS Object Identifier :: = {ID-CE 31}

CRLDISTRIBUTIONPOINTS :: = {CRLDistPointssyntax}

CRLDistPointsSyntax :: = SEQUENCE SIZE (1..MAX) OF DistributionPointDistributionPoint :: = SEQUENCE {distributionPoint [0] DistributionPointName OPTIONAL, reasons [1] ReasonFlags OPTIONAL, cRLIssuer [2] GeneralNames OPTIONAL}

DistributionPointName :: = cho1 {fullname [0] generalnames, NameRelativeToCrlissuer [1] relativedistinguishedname}

Reasonflags :: = bit string {unused (0), Keycompromise (1), Cacompromise (2), AffiliationChanged (3), Superseded (4), CassationOfoperation (5), CertificateHold (6)}

4.2.2 Private Internet Extension

This part defines a new extension for use in the Internet public key basis. This extension can be directly applied (Direct Applications) to identify the issuance of the application support for online approval services. When the information can be valid in multiple forms, each extension is a series of IA5String values, each represents a URI. The URI does not expressly specify the location and format of the information and method of obtaining information.

An object identifier is defined for private extensions. Connect the object identifier and private extension to the ARC ID-PE within the ID-PKix namespace below is defined below. Any future extension defined for Internet PKI will also be defined below the ARC ID-PE.

ID-PKIX Object Identifier :: = {ISO (1) Identified-Organization (3) DOD (6) Internet (1) Security (5) Mechanisms (5) PKIX (7)}

ID-pe Object Identifier :: = {ID-PKIX 1}

4.2.2.1 Authoritative Information Access

Authoritative information Access extension indicates how to access the CA information and services to the issuer that extends in the certificate. Information and services can include online license services and CA policy data. (CRLS position is not specified in this extension; that information is provided by the CRLDISTRIBUTIONPOINTS extension) This extension can be included in the topic or CA certificate, and it must be non-critical.

ID-PE-AuthorityInfoAccess Object Identifier :: = {ID-PE 1}

AuthorityInfoAccessSyntax :: = sequence size (1..max) of accessDescriptionAccessDescription :: = sequence {accessMethod Object Identifier, AccessLocation generalname}

ID-AD Object Identifier :: = {ID-PKIX 48}

ID-ad-caissuers object identifier :: = {ID-ad 2}

Each in the Sequence AuthorityInfoAccessSysysysysysysysysyssentax entry depicts the format and location of the information about CA, which releases the certificate that appears. The type and format of the information is specified by the AccessMethod field; the AccessLocation field specifies the location of the information. The recovery mechanism means you can use AccessMethod or by AccessLocation.

This article defines an OID for AccessMethod. When the additional information lists the CA status of CAS, ID-Ad-Caissuers OID is used to expand. Referring to the CA publisher to help certificate users in the certificate path of the certificate user trust termination point.

When ID-ad-caissuers appears as AccessInfotype, the AccessLocation field depicts the recommended server and access protocol to obtain reference depiction. Define the AccessLocation field as GeneralName that can take several formats. The AccessLocation must (Must) is a UniformResourceIdentifier via HTTP, FTP or LDAP information. Where information is available via Directory Service System Access Protocol (DAP), the AccessLocation must (Must) is a DirectoryName. When the information is available via email, the AccessLocation must (MUST) is a RFC822NAME. Not commended in this article, other name formats (when AccessMethod are ID-Ad-Caissuers).

Additional access descriptors can be defined in other PKIX text descriptions.

5 CRL and CRL expansion profile

As with the previous depiction, a target of X.509 V2CRL This article is to help development created a useful Internet PKI that can be operated by both sides and reuse. To achieve this goal, the guide to extend use is specified and some of the assumption information about the essence contained in the CRL.

CRLS can be used in a wide range of operational and warranty requirements in a wide range of applications and even wider range of applications and even wider range of applications. This article provides a shared baseline for applications requiring broadly operated by both sides. This article defines a baseline kit to be expected in each CRL. At the same time, this paper is defined as well as a general location within the CRL of the currently used attributes to be used for these attributes.

This article does not define any private InternetCRL extension or CRL entry extension.

As additional or special purpose requirements environment can be established on the basis of this paper or can replace it.

If other canceled or certificate status algorithms are provided, the CRS is not required to follow CAS. The CAS must (MUST) in accordance with the release of CRLS (MUST), and the CAS must contain the date in the NextUpdate field (see 5.1.2.5), CRL (see 5.2.3) and Authoritative key logo extension (see 5.2.1). Follow the application needs to process the 1st and 2 Edition CRLs. 5.1 CRL field

The X.509 V2CRL syntax is as follows. Calculated for signature, data to be signed is ASN.1 DER encoding. ASN.1 DER encoding is a label, length, an encoding system for each element value.

CertificateList :: = sequence {TBSCERTLIST TBSCERTLIST, SIGNATUREALGORITHM Algorithmidentifier, SignatureValue Bit String}

TBSCertList :: = SEQUENCE {version Version OPTIONAL, - if present, shall be v2 signature AlgorithmIdentifier, issuer Name, thisUpdate Time, nextUpdate Time OPTIONAL, revokedCertificates SEQUENCE OF SEQUENCE {userCertificate CertificateSerialNumber, revocationDate Time, crlEntryExtensions Extensions OPTIONAL - if present, SHALL BE V2} Optional, CRLEXTensions [0] Explicit Extensions Optional - IF Present, Shall Be V2}

Version, time, CertificateSerialNumber and extensions are defined in paragraph 4.1 in Asn.1.

Algorithmidentifier is defined in paragraph 4.1.1.2.

The following items depict X.509 V2CRL in Internet PKI.

5.1.1 CertificateList field

CertificateList is a series of three demand fields (Three Required Fields). Fields are drawn in detail in the following sections.

5.1.1.1 Tbscertlist

The first field in the sequence is TBSCERTLIST. This field is its own sequence, with the issuer's name, the date of issuance, the next list (CRL) issuance date, the revocation certificate list, and the optional CRL extension. Further, each of the inlets in the undo certificate is determined by a series of user certificates, undo date, and optional CRL entry extensions. 5.1.1.2 SignaRgorithm

The SignatureAlgorithm field is an algorithm that contains the algorithm identifier and signs the CA in the CERTIFICATELIST. The field has the type ALGORITHMIDENTIFIER that is defined in section 4.1.1.2. Sections 7.2 are listed in the algorithm for the description of this article. CAS must (MUST) guarantees the algorithm identifier defined in paragraph 7.2 when signing is signed.

This field must (MUST) contains the same reference numeral identifier in sequence TBSCERTLIST (see 5.1.2.2).

5.1.1.3 SignatureValue

The SignatureValue field contains a digital signature calculation on the ASN.1 DER encoded TBSCERTLIST. Use the ASN.1 DER encoding TBSCERTLIST as the input to the signature function. That is ASN.1 as a bit string to encode this value value and contained in the SignatureValue field of the CRL. Details of this process in part 7.2 for each support.

5.1.2 List of Certificate "To Be Signed"

The signed certificate list or TBSCERTLIST is a must-selectable field of a series of sequence. The VRL issuer must identify the CRL issuer, using an algorithm on the CRL, the date and time of the CRL, and the date and time of the next CRL will be issued in CA.

Optional fields contain a list of revocations and CRL extensions. The revocation of the certificate is that its CA has not revoked any optional proof of certificates its issued certificate. This article requires CAS to ensure that CRLNUMBER extension is used in all CRLs issued.

5.1.2.1 version

This optional field depicts the version encoding the CRL. When expanding, as needed in this article, this field must (MUST) is existing and must be specified version 2 (integer value 1).

5.1.2.2 Signature

This field contains an algorithm identifier for using the name algorithm on the CRL. Segment 7.2 describes a list of most popular signature algorithms used in Internet PKI.

This field must (MUST) contains the same as the SignatureAlgorithm field algorithm identifier in the sequence CertificateList (see section 5.1.1.2).

5.1.2.3 Publisher Name

The issuer name identifies the entity that has been signed and issued on the CRL. The issuer entity is taken in the issuer's name field. Alternative name formats can also occur in IssueraltName extensions (see 5.2.2). The issuer's name field must be (MUST) contains an X.500 distinguished name (DN). The issuer's name field is defined as an X.501 type name and must (MUST) to comply with the encoding rules of the issuer name field in the certificate (see 4.1.2.4).

5.1.2.4 Update

This field indicates the release date of this CRL. Thisupdate can be encoded as utctime or generalizedtime.

The CAS must be called thisupdate as Utctime prior to 2049. CAS complies with the release of CRLs in this article must be used as GeneralizedTime in the year 2050 or later.

As a UTCTIME encoded, (MUST) is required to specify that thisUpdate is as defined and explained in Section 4.1.2.5.1. As a place for GeneralizedTime encoding, (MUST) is required to specify that thisupdate is as defined and explained in Section 4.1.2.5.2. 5.1.2.5 Next Update

This field indicates the date that is issued in the next CRL, before the indication date, the next CRL can be emitted, but it will not be issued after the indication date or afterwards. The CAS should be published in the CRLS in a NEXTUPDATE time compared to all the previous CRLs. NextUpdate can be encoded as utctime or generalizedtime.

This document describes NEXTUPDATE in all CRLs that must be emitted in CAS. Note TBSCERTLIST ASN.1 syntax depicts this optional field, which is consistent with the ASN.1 defined by [X.509]. Processing CRLS Delete NextUpdate Customer (Software) Behavior is not described herein.

The CAS must be called thisupdate as Utctime prior to 2049. CAS complies with the release of CRLs in this article must be used as GeneralizedTime in the year 2050 or later.

5.1.2.6 Undo Certificate

The revocation certificate is listed. Name the revocation certificate through their serial number. The certificate serial number uniquely identifies the revocated certificate. The date of cancellation occurs is specified. The RevocationDate time must be represented as depicted in Section 5.1.2.4. Additional information can be provided in the CRL entry extension; the CRL entry extension is discussed in Section 5.3.

5.1.2.7 expansion

This field only appears in version 2 (or higher) (see 5.1.2.1). If there is, this field is one or more CRL extensions of the sequence. CRL extensions are discussed in Section 5.2.

5.2 CRL extension

Extensions are defined by the ANSI X9 and ISO / IEC / ITUs for X.509 V2CRLS [X.509]. [X9.55] Provides a method of linked additional properties and CRLs. The X.509 V2CRL format also allows the community to define private scope to carry out extension of unique information of those communities. The extension in the CRL can be critical or non-critical. If it encounters a key extension that it doesn't know how to handle it, the CRL approval must fail. However, non-critical expansion that is not recognized can be ignored. The following sections propose those extensions used within InternetCrls. The community can choose to include not defined in the CRLS in this article. However, any key expansion in CRLs that can be used in general background should be used.

The CAS confirmation of the release of CRLs contains the Key identifier (see 5.2.1) and the CRL digital extension in all released CRLs (see 5.2.3).

5.2.1 Authoritative Key Identifier

The authoritative key identifier extension provides a means of identifying a means of public key corresponding to using a private key on a CRL. Verify that the key identifier (the subject key identifier in the CRL signer) can be established on the basis of any one. A issuer has more than a key pair due to multiple simultaneous occurs or is especially useful for the replacement of the key.

CAS Follow the key identifier method and must be included in all released CRLs in all released CRLs. This CRL extension syntax is defined in Section 4.2.1.1.

5.2.2 Punker can replace the name

The issuer replaces the name extension allows additional identification and the issuer of the CRL. Define options contains a RFC822 name (email address), a DNS name, an IP address, and a URI. A multi-instance of a word and multiple name format can be included. Whenever such an identifier is used, the issuer can replace the name extension (MUST) is used.

IssueraltName extension should not be tagged as a key.

This CRL extension OID and syntax are defined in Section 4.2.1.8.

5.2.3 CRL NUMBER

CRL Number is a non-critical CRL extension emitted by CA, which is a monotonically increasing serial number per CRL expression. This expansion allows users to easily decide when a specific CRL replaces another CRL. CAS complies with this article (MUST) contains this extension in all CRLs.

ID-CE-CRLNUMBER OBJECT IDENTIFIER :: = {ID-CE 20}

CRLNUMBER :: = INTEGER (0..max)

5.2.4 Delta CRL identifier

The Delta CRL identifier is a key CRL extension that identifies a Delta-CRL. The use of DELTA-CRL can increase the processing time in which the application (program) increased than the CRL structure is considerably largely extent. This allows change to be added to the local database, and ignore the unchanged information (which is already in the local database).

When a Delta-CRL is sent, the CAS must (MUST) simultaneously issues a complete CRL.

BasecrlNumber's value identifies that the CRL number is used as the starting point in the Delta-CRL. Delta-CRL contains a change between group CRL and current CRL (either in Delta-CRL). It is determined by CA to provide Delta-CRL. Again, a Delta-CRL must not be issued without a corresponding full CRL. The value of CRLNUMBER is Delta-CRL and the corresponding complete CRL value must be identical.

If the CRLNumber received by delta-CRL is the last Delta-CRL of the last processed, a CRL user must (MUST) believes that the CRL acquired from Delta-CRLs is incomplete and unused.

ID-CE-DELTACRLINDICATOR OBJECT IDENTIFIER :: = {ID-CE 27}

Deltacrlindicator :: = basecrlNumber

BasecrlNumber :: = CRLNUMBER

5.2.5 Release Publishing Point

The issuance release point is a key CRL extension that identifies the CRL publishing point for a specific CRL, and it indicates whether the CRL is only a terminal entity certificate, which is only the CA certificate or a limited restriction (Limitied) Reason code coverage. Although the extension is the key, it is not required to ensure that the tool supports this expansion.

Signing on the CRL using the private key using CA. The CRL publishing point does not have their own key pair. If the CRL is stored in the X.500 directory service system, it is stored in a directory entity corresponding to the CRL publishing point, and can be different from the CA's directory entity.

The reason why the code and the release point association will be specified in ONLYSOMEREASONS. If ONLYSOMEREASONS does not appear, the publishing point will contain all revocation reasons. CAS can use the CRL publishing point to deliver the CRL partition based on damage and conventional (COMPROSE AND ROUTINE). This situation, along with the reason codes keyCompromise (1) and cACompromise (2) revocation appears in a release point, and there are other reasons for the revocation codes appear in another distribution point. The IssuingDistributionPoint extension includes a URL, the following semantics must be assumed: the object is a pointer to the most current CRL emitted through this CA. URI system FTP, HTTP, Mailto [RFC1738] and LDAP [RFC1778] are defined for this purpose. The URI must (MUST) is an absolute, unrelated path name and must be specified for the host (MUST).

ID-CE-ISSUINGDISTRIBUTIONPOINT OBJECT IDENTIFIER :: = {ID-CE 28}

issuingDistributionPoint :: = SEQUENCE {distributionPoint [0] DistributionPointName OPTIONAL, onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, onlySomeReasons [3] ReasonFlags OPTIONAL, indirectCRL [4] BOOLEAN DEFAULT FALSE}

5.3 CRL entry expansion

The CRL entry extension that has been defined by the ANSI X9 and ISO / IEC / ITUs for X.509 V2CRLS is provided to additional properties and CRL portal [X.509] [x9.55]. The X.509 V2CRL format also allows the community to define a private CRL entry extension to carry all the specific information of those communities. Each extension in the entrance to the CRL can be critical or non-critical. If you don't know how to deal with key CRL entry extensions, CRL approval must fail. However, an unidentified non-critical CRL entry extension can be ignored. The following part proposes that the recommended extension is used within the location of the InternetCRL entry and the standard information. The community can choose to use additional CRL entry extensions; however, should be cautious in adoption of any key expansion in the entrance of CRLs in the general background.

All CRL entry extensions are not critical in this document. Support for these extensions Because it is optional for CAS and application assurance. However, whenever this information is available, the release of CRLs should include reason code (see 5.3.1) and invalidated dates (see 5.3.3).

5.3.1 Reason Code

ReasonCode is a non-critical CRL entry extension, which identifies the reasons for certification revocation. CAS is strongly encouraged to include meaningful reason code in the CRL entrance; however, the reason code CRL entry extension should be (Should) does not exist instead of using non-specific (0) ReasonCode values.

ID-CE-CRLREASON OBJECT Identifier :: = {ID-CE 21}

- ReasonCode :: = {CRLREASON}

CRLREASON :: = Enumerated {Unspecified (0), Keycompromise (1), Cacompromise (2), AffiliationChanged (3), SuperSeded (4), CassationOfoperation (5), CertificateHold (6), RemoveFromCRL (8)} 5.3.2 Keep Indicate code

Keeping the instruction code is a non-critical CRL entry extension, which provides an registration indicator identifier, which indicates that the action is taken on the effort (HOLD) after encountering a certificate.

ID-CE-HOLDINSTRUCODE OBJECT IDENTIFIER :: = {ID-CE 23}

HoldInstructioncode :: = Object Identifier

The following instructions are defined. Applications (Program) to the Processing (Program) Keep must recognize the following instructions.

Holdinstruction Object Identifier :: = {ISO (1) Member-body (2) US (840) X9-57 (10040) 2}

id-holdinstruction-none OBJECT IDENTIFIER :: = {holdInstruction 1} id-holdinstruction-callissuer OBJECT IDENTIFIER :: = {holdInstruction 2} id-holdinstruction-reject OBJECT IDENTIFIER :: = {holdInstruction 3}

Applied an ID-HOLDINSTRUCTION-Callissuer (program) guarantee (MUST) to call or discard the certificate issuer. Applied an ID-HOLDINSTRUCTION-REJECT (program) guarantee that the certificate must be discarded (MUST). Indicates ID-HOLDINSTRUCTION-NONE is equivalent to a HoldInstructioncode in a semantic, and its use is strongly opposed to Internet PKI.

5.3.3 Invalid date

The invalid date is a non-critical CRL entry extension, and its definition date is known or suspected that its private key is leaked or the certificate becomes ineffective. This date can be earlier than the revocation date in the entrance of the CRL, and its recently is the date of revocation in its CA. When a cancellation passed the CA after the first time in the CRL, the invalid date can be before the earlier CRLS date, but the revocation date should not be before the earlier CRLS date. Whenever this information is available, CAS is strongly promoted to share it with CRL users.

The generalizedtime value must be (MUST) is the Greenwich standard time indicates that (Must) is specified in this field as defined and explained in Section 4.1.2.5.2. ID-CE-IVALIDITYDATE OBJECT Identifier :: = {ID-CE 24}

INVALIDITYDATE :: = generalizedtime

5.3.4 Certificate issuer

This CRL entry extension identifies a certificate issuer associated with an indirect CRL entry (indirect CRL means, for example, an INDIRECTCRL indicator embedded to its issued release point extension). If this expands does not exist in the first entry point in a CRL, the certificate issuer defaults the CRL issuer. On a subsequent entry point in a CRL, if this expansion does not exist, the certificate issuer of the entry is the same as the front entry. This field is defined as follows:

ID-CE-CERTIFICATEISSUER OBJECT IDENTIFIER :: = {ID-CE 29}

Certificateissuer :: = generalnames

This extension is always critical if CAS guarantees the use of CRLs. If the tool ignores this extension, it does not correctly pay the CRL entry to the certificate. This article recommends tool identifying this extension.

6 certificate path approval

Approve the certificate path to the process of Internet PKI, based on paragraph 12.4.3, [X.509]. Certificate Path Process Verification In Topic Identification Name and / or Rule can be used as a replacement name between the subject public key. Binds are constrained to limit in certificates including paths. Basic constraints and policy constraints Extend allow certificate path processing to automate the decision process.

This part depicts an algorithm for a valid certificate path. The tools described herein ensure that this algorithm is not necessary, but from the processing process must be equivalent to the result of external behavior (MUST). As long as it gets the correct result, any algorithm can be used by a special tool.

In part 6.1, the text is depicts the basic path approval. The text believes that all effective paths begin with a single "most trusted CA" ("Most-Trusted CA"). The algorithm requires the public key of the CA, the name of the CA, the validity of the public key, and any set of constraints on a set path that can use this key.

"The most trusted CA" is a policy problem: it can be a root CA in the PKI of the hierarchy; CA of the certificate (S) of the certificate (S); or any other CA in a network PKI. The path approval process is the same regardless of the "most trusted CA" ("Most Trusted CA.").

Segment 6.2 depicts the expansion of the basic path approval algorithm. Both situations are discussed: One case refers to the path of several trusted CASs; the other case is required to compatibility with PEM structure.

6.1 Basic path approval

Text assumes that trusted public key (and related information) is contained in a "self-signed" certificate in the "Self-Signed" certificate depiction of this simplified path processing process. Note that the signature on the self-signed certificate does not provide any security services. The trusted public key (and related information) can be obtained in other formats; information is trusted by other processes in the past.

The path-approved goal is to verify the binding between a topic identification name or the subject, and the binding of the subject public key as the subject public key is, the entity certificate is built in "most trusted CA" ("MOST) -Trusted CA ") on the basis of the public key. This needs to get a series of certificates that support that binding. Performing this consequence is beyond the scope of this section.

The following sections of the text also assume that the certificate does not use the topic or unique identifier field or a private key expansion in this paper. However, if these ingredients appear in the certificate, they must be processed (MUST). Finally, the strategy limits are neglected for transparency. A certificate path is a series of N certificates:

* for all x in {1, (n-1)}, The Subject of Certificate X 1. * Certificate X = 1 Is the the Self-Signed Certificate, And * Certificate X = N IS The End Entity Certificate.

This part of the false directional path processing logic provides the following inputs:

(A) a certificate path length n;

(B) a set of initial policy identifiers (each comprising a series of policy elements identifiers) identifying one or more certificate policies, any one will be accepted for the certificate path or special value "any-policy" Strategy;

(D) Time T of the validity of the path should be determined. (This can be the current date / time, or some in the past.

From the input, the process initializes five status variables:

(A) Acceptable policy settings: A set of certificates, or (multiple) policies, or (multiple) policies, or (multiple) policies, or (multiple) policies that are considered to be a policy or (multiple) policies admitted to the policy or (multiple) policies. The initial value of acceptable policy settings is a special value "any-policy".

(B) Limit the subtree: a set of defines a set of subtots in the root name descent in all the theme names in the certificate path. The initial value is "unbounded".

(C) Excluding the subtree: Define a set of sub-trees, and then there is no root name to fall within the certificate in the certificate path. The initial value is "EMPTY".

(D) Clear strategy: Indicates that if a clear policy identifier is an integer that needs. Integers indicate the first certificate in this need to be utilized. Once set, this variable can be reduced but may not be increased. (That is to say, if a certificate in the path demand clear policy identifier, subsequent certificates cannot remove this demand). The initial value is n 1.

(E) Policy mapping: An indication if the policy map is allowed. An integer indicates which policy mapping at the last certificate (Last Certificate) can be applied. Once set, this variable can be reduced but may not be increased. (That is to say, if a certificate specified in the path is not allowed to be allowed, it cannot be subsequent certificate Overriden. The initial value is n 1.

The action is described below, and the path processing software is performed for each certificate i = 1. The self-signed certificate is the certificate i = 1, the end physical certificate is i = n. Processing is continuously executed, so the processing certificate I has an impact on the processing certificate (i 1) state variable. Note That Action (G) is not suitable for end physical certificates (certification N) by (L).

The path processing action executed is:

(A) Verify the basic certificate information, including: (1) Signing on the certificate using the public key from the certificate I-1 topic (in special case i = 1, this step can be deleted; if not, use from the same Certificate Theme Publication Key). (2) The certificate containing the time T validity period. (3) The certificate has not been revoked and the time T is not currently held at time T. (This can be determined by obtaining a suitable CRL or status information, or the OUT-OF-BAND mechanism is determined). And (4) theme and the publisher name chain correct (that is, the issuer of this certificate is the topic of the previous certificate).

(B) Verify that theme name and SubjectAltName extension (key or non-critical) are consistent with the status of the subtree state variables.

(C) Verify that theme name and SubjectaltName extension (key or non-critical) are uniformly consistent with the exclusion subtree state variable.

(D) Verify policy information is consistent with the initial policy device:

(1) If the explicit policy status variable is less than it is equal to I, the policy identifier in the certificate will be in the initial policy device; and (2) If the policy mapping variable is less than being equal to I, the policy identity may not be mapping.

(E) Verify policy information is consistent with acceptable strategic devices:

(1) If the certificate policy extension is marked as a key, the intended and acceptable policy, the intersection of the policy, will be non-null;

(2) Allocate the results intersection of the acceptable policy device as its new value.

(F) Verify the intersection of the acceptable strategy device and the initial policy device is non-null.

(G) Identify and processed any other key expansion in the certificate.

(H) Verification (as specified in a BasicConstraints extension or as Out-of-Band Verification) The certificate is a CA certificate.

(I) If PermittedSubtrees exists in the certificate, the substrust state variable of the constraint is its previous intersection value and the value in the extended field.

(J) If ExcludedSubtrees exists in the certificate, the exclusion subtree state variable is the previous integration value and the value indicated in the extended field.

(K) If a strategy constraint extension is included in the certificate, modify the clear policy and policy mapping status variables as follows:

(1) If RequireExPlicitPolicy exists and value R, the explicit policy status variable is set to its current value minimum and the sum of R and I (current certificate in the sequence).

(2) If INHIBITPOLICYMAPPING exists and value q, the policy mapping status variable is set to its current value minimum and the sum of Q and I (current certificate in the sequence).

(L) If the key is used to use the extension tag, it is guaranteed that the KeyCertsign bit is set.

If any of the above tests fail, the process ends. Returns a failure indication and a suitable reason. If the inspection on the end entity does not fail, the process is terminated, along with a set of all strategic qualifiers to the certificate to return success instructions.

6.2 Approval path approval

The path approval algorithm deposited in 6.1 is based on several simplified assumptions (for example, all valid paths start in a single trusted CA). This algorithm can be extended to a case where it is not supported. This process can be extended to a multi-trusted CAS that provides a self-signed certificate to the approval module. In this case, a valid path can start with any self-signed certificate. The limitations in the trust path can be entered for any special key to be used by the self-signed certificate. In this way, the visa allows the path approval module to automatically enter the local security policies and requirements.

It also specifies the extended version of the above certificate path processing, which is possible to exactly the same default behavior as PEM [RFC 1422]. In this extended version, the input to the process is one or more policies to prove the checklist of the authority (PCAS) name and a indicator of the location in the PCA is expected. In the named PCA location, the CA name is compared to this list. If a one identified PCA name is found, then a SubordInateToca's constraint is not confused for the remaining part assumed certificate path and processing. If there is no valid PCA name being identified, and if the certificate path cannot be valid based on the identified policy, then the certificate path is invalid.

7 algorithm technical support

This section describes the cryptographic algorithm that can be used herein. This part depicts a one-way hash function and a digital signature algorithm that can be used on the certificate and CRLS and identify OIDS for the public key containing a certificate.

Compliance with CAS and applications do not need to support the algorithm or algorithm identifier in this section. However, using the CAS and application guarantees for identifying algorithms here (MUST) support them as specified.

7.1 unidirectional hash functions

This part is a one-way hash function used in Internet PKI. The unidirectional hash function is also called a information abstract algorithm. SHA 1 is a more popular unidirectional hasxirectional hasxirection for Internet PKI. However, PEM is used as certification MD2 [RFC 1422] [RFC 1423] and MD5 in other legacy applications. To this end, MD2 and MD5 are included in this article.

7.1.1 MD2 One-way Hash Function

MD2 is RSA Data Security (RSA Data Security) Ron Rudest inventions. RSA data security has not yet placed the MD2 algorithm in the open field. Also, RSA data security has agreed to use MD2 licenses for non-commercial Internet private enhancements (Internet Privacy-enhanced Mail). To this end, MD2 can continue to be used in the PEM certificate, but SHA 1 is preferred. MD2 produces an output 128-bit "haveh". MD2 is fully depicted in RFC 1319 [RFC 1319].

In May 1995, there is a selection area (SELECTED AREAS), Rogier and Chauvaud, which have almost discovered conflicts [RC95]. When one can find two different information that produces the same information summary, the conflict occurs. One checksum and operation in MD2 is the only obstacle to the attack on the attack. To this end, MD2 is discouraged in new applications. It is still reasonable to use MD2 verification existing signatures, when conflict is found in MD2, you cannot make an attacker can find new information is the same as the previous calculated hash value.

7.1.2 MD5 unidirectional hash function

MD5 is developed by RSA data secure Ron Rivest. RSA data security has placed the MD5 algorithm into the public domain. MD5 produces an output 128-bit "hash". MD5 is fully depicted in RFC 1321 [RFC 1321].

Den Boer and Bosselaers [DB94] have found a Pseudo-Collisions conflict for MD5, but in fact there is no other known password analysis result. MD5 is discouraged for the use of new applications. Verify that existing signs using MD5 is still reasonable.

7.1.3 SHA1 One-way Hash Function

SHA 1 is developed by the US government. SHA 1 produces a 160-bit "haveh" of the output. SHA 1 is fully depicted in FIPS 180-1 [FIPS 180-1]. SHA 1 is a one-way hash has-port as a selected one-way hash function as an RSA and a DSA signature algorithm (see 7.2).

7.2 Signing Algorithm

Certificates and CRLs depicted in this standard can be signed with any public key signature algorithm. Certificate or CRL indicates an algorithm identifier, which appears in a certificate or the SignaRgorithm field in the CertificateList. This algorithm identifier is an OID and an optional combined parameter. This part identifies the algorithm identifier and parameters, which will be used in the SignatureAlgorithm field in a certificate or CertificateList.

RSA and DSA are the most popular signature algorithms in the Internet. The signature algorithm is always used with a one-way hash function described in Section 7.1.

The signature algorithm and the one-way haveh function are often signed on a certificate or the use of an algorithm identifier on a certificate or CRL. An algorithm identifier is an OID and a combination parameter that can be included. This part identifies the OIDS for RSA and DSA. The content change of each algorithm parameter component: provides details to each algorithm.

Data is signed (for example, a one-way hash function output value) is used by the formatted signature algorithm. A private key operation (eg, RSA encryption) is then executed to generate a signature value. The signature value is then encoded as a bit string type as a bit string type and is included in the certificate or CertificateList in the signature field.

7.2.1 RSA signature algorithm

About the RSA algorithm patent statement is provided later.

The RSA algorithm is named to commemorate its inventors: Rivest, Shamir and Adleman (combination of three people name head letters - translator's note). This article contains three signature algorithms based on the RSA asymmetric encryption algorithm. The signature algorithm combines RSA with MD2, MD5 or SHA 1 unidirectional hasidah.

The signature algorithm of the MD2 and RSA encryption algorithm is defined in PKCS # 1 [RFC 2313]. As defined in RFC 2313, ASN.1 OID is used to identify this signature algorithm:

Md2withrsaencryption Object Identifier :: = {ISO (1) Member-body (2) US (840) RSADSI (113549) PKCS (1) PKCS-1 (1) 2}

The signature algorithm of the MD5 and RSA encryption algorithm is defined in PKCS # 1 [RFC 2313]. As defined in RFC 2313, ASN.1 OID is used to identify this signature algorithm:

MD5withrsaencryption Object Identifier :: = {ISO (1) Member-body (2) US (840) RSADSI (113549) PKCS (1) PKCS-1 (1) 4}

The signature algorithm of the SHA 1 and RSA encryption algorithm is applied in PKCS # 1 [RFC 2313] by using a padding or encoding. Information Summary is calculated using SHA 1 hash algorithm. Use the ASN.1 object identifier to identify this signature algorithm:

SHA-1WITHRSAENCRYPTION Object Identifier :: = {ISO (1) MEMBER-BODY (2) US (840) RSADSI (113549) PKCS (1) PKCS-1 (1) 5} When any of these three OIDs appear in ASN. 1 Type Algorithmidentifier, the component of the type parameter will be an ASN.1 type NULL.

The RSA signature generation process and the result of the encoding are detailed in the RFC 2313.

7.2.2 DSA signature algorithm

About the DSA patent declaration is described later herein.

Digital signature algorithm (DSA) is called a digital signature standard (DSS). DSA is developed by the US government, and DSA is used in combination with SHA 1 one-way hash function. DSA is fully depicted in FIPS 186 [FIPS 186]. ASN.1 OIDS is used to identify this signature algorithm:

ID-DSA-with-sha1 id :: = {ISO (1) Member-body (2) US (840) X9-57 (10040) X9cm (4) 3}

The ID-DSA-WITH-SHA1 algorithm identifier appears in Algorithmidentifier as an algorithm field, and the algorithm field will delete the parameter field. That is, Algorithmidentifier will be a series of components - The Object Identifier ID-DSA-with-sha1.

The issuer's DSA parameters in the SubjectPublicKeyInfo field of the certificate will propose a verification application for the signature.

When signing, the DSA algorithm generates two values. These values are typically referred to as R and S. It is easy to transfer these two values, they will be ASN.1 encoding using the following ASN.1 structure:

DSS-SIG-VALUE :: = SEQUENCE {R integer, s integer}

7.3 Topic Publication Key Algorithm

According to this document, the certificate can be transmitted to any public key algorithm. The certificate is indicated by an algorithm identifier. This algorithm identifier is a combination of an OID and optional parameters.

This part identifies the preferred OIDs and parameters for RSA, DSA and Diffie Hellman algorithms. When the certificate is issued, when the disclosure key is included, the CAS guarantee the application (program) to identify the OIDS. At least the OID identifier is to be identified.

7.3.1 RSA Keys

PKCS-1 Object Identifier :: = {ISO (1) MEMBER-BODY (2) US (840) Rsadsi (113549) PKCS (1) 1}

Rsaencryption Object Identifier :: = {PKCS-1 1}

Planning to let RSAENCryption OID are used in the value of the type of Algorithmidentifier. The parameter field will have an ASN.1 type NULL for this algorithm identifier.

The RSA public key will be encoded using an ASN.1 type RSapublicKey:

RsapublicKey :: = sequence {modulus integer, - n publicExponent Integer - E -} Model N, and PUBLICEXPONENT is the number of public key quality E. DER encoding RSAPublicKey is the value of Bit String SubjectPublicKey.

This OID is in the public key certificate, that is, in the RSA signature key, and is also used in the RSA encryption key. The application of the key can be indicated in the key in the field (see 4.2.1.3). When a single key is used for signature and encryption purposes, it is not recommended, but it is not disabled.

If the Keyusage extension is existing in a end entity certificate that is transmitted to a RSA public key, any of the following values can exist: DigitalSignature; NonRepudiation; KeyEncipherment; and DataEncipherment. If the Keyusage extension is existing in a CA certificate that transmits an RSA public key, any following value combination can exist: DigitalSignature; nonRepudiation; KeyEncipherment; KeyCertsign; and CRLSign. However, this article is recommended if keycertsign or crlsign exists, KeyEncipherment and DataEncipherment should not exist.

7.3.2 Diffie-Hellman Key Exchange Key

In this article, Diffie Hellmanoid supports is defined by ANSI X9.42 [X9.42].

DHPUBLICNUMBER Object Identifier :: = {ISO (1) MEMBER-BODY (2) US (840) ANSI-X942 (10046) Number-Type (2) 1}

Planning the DHPUBLICNUMBER OID is used in the value of the type Algorithmidentifier. The type of parameter field of that type is any this algorithm definition (Any Defined by), there is an ASN.1 type DomainParameters.

Domainparameters :: = sequence {p integer, - odd prime, p = jq 1 g Integer, - Generator, g q integer, - factor of p-1 j integer Optional, - Subgroup Factor ValidationParms ValidationParms Optional}

ValidationParms :: = sequence {seed bit string, pgencounter integer}

Type DomainParameters has the following definitions:

p Identify the number P in the Galois field.

g Specify the multiplication of the multiplier group of the order G;

q Specify factor factor P-1;

j Optional specified value, which satisfies the optional verification of the equation P = JQ 1 support group parameters; seeds arbitrarily specify as a bit character parameter as a seed system parameter generation process; and

Pgencounter will assign an integer value output as a part of the system parameter.

If any parameter generating component (Pgencounter or seed) is provided, others will exist.

The Diffie-Hellman public key will be encoded as an ASN.1 integer type; this encoding will be the content (ie value) of the SubjectPublic KeectPublicKeyInfo data element.

DHPUBLICKEY :: = INTEGER - PUBLIC Key, Y = g ^ x mod p

If the KeyUSAGE extension exists in a certificate that transmits a DH public key, the following values can exist: keyagreement; Encipheronly; and Decipheronly. Up to one Encipheronly and Decipheronly will exist in the Keyusage extension.

7.3.3 DSA signature key

The digital signature algorithm (DSA) is also known as a number of digital signature standards (DSS). DSA OID is based on this paper

ID-DSA ID :: = {ISO (1) Member-body (2) US (840) X9-57 (10040) X9cm (4) 1}

The ID-DSA algorithm syntax contains an optional parameter. These parameters are typically referred to as P, Q, and G. When deleted, the parameter ingredient will be completely deleted. That is, Algorithmidentifier will be a series of components - object identifier ID-DSA.

If the DSA algorithm parameter is existing in the SubjectPublicKeyInfo Algorithmidentifier, the parameter is included using the following ASN.1 structure:

DSS-PARMS :: = SEQUENCE {P INTEGER, Q INTEGER, G Integer}

If the DSA algorithm parameter is not in SubjectPublicKeyInfo Algorithmidentifier and CA, the DSA parameter of the certificate issuer is applied to the topic's DSA key. If the DSA algorithm parameter is not in SubjectPublicKeyInfo Algorithmidentifier and CA, the Signing of the Topics In addition to the DSA signature algorithm, the DSA parameter of the subject is released by another means. If the SubjectPublicKeyInfo Algorithmidentifier field deletes the parameter ingredients and CA signed topics With the DSA signature algorithm, the customer will discard the certificate.

When signing, the DSA algorithm generates two values. These values are usually called r and s. Easy to pass two values for signatures, their ASN.1 encodes the following ASN.1 structure:

DSS-SIG-VALUE :: = SEQUENCE {R integer, s integer}

The encoding signature is transmitted in a certificate or CertificateList to be transmitted in a Bit String Type Signature value.

The DSA public key will be an ASN.1 DER as an integer type encoding; this encoding will be the content of the SubjectPublicKey component (A bit string) SubjectPublicKeyInfo data element (ie, value) is used. DSAPUBLICKEY :: = Integer - Public Key, Y

If the Keyusage extension is in a terminal entity certificate that exists in a DSA public key, any following value combination can exist: DigitalSignature; and NonRepudiation.

If the Keyusage extension is existing in a CA certificate that transmits a DSA public key, any of the following values can exist: DigitalSignature; NonRepudiation; KeyCertsign; and CRLSIGN.

8 References

[FIPS 180-1] Federal Information Processing Standards Publication (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995. [SuperSedes Fips Pub 180 Dated 11 May 1993.]]

[FIPS 186] Federal Information Processing Standards Publication (FIPS PUB) 186, Digital Signature Standard, 18 May 1994.

[RC95] Rogier, N. And Chauvaud, P., "The Compression Function of MD2 IS Not Collision Free," Presented At SELECTED AREAS IN CRYPTOGRAPHY '95, May 1995.

[RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

[RFC 822] CROCKER, D., "Standard for the format of arpa internet text message", STD 11, RFC 822, August 1982.

[RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.

[RFC 1319] Kaliski, B., "THE MD2 Message-Digest Algorithm," RFC 1319, April 1992.

[RFC 1321] RiveSt, R., "The MD5 Message-Digest Algorithm," RFC 1321, April 1992.

[RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management," RFC 1422, February 1993. [RFC 1423] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, And Identifiers, "RFC 1423, February 1993.

[RFC 1519] Fuller, V., LI, T., YU, J. And K. Varadhan. "Classless Inter-Domain Routing (CIDR): An Address Assignment and Aggregation Strategy, RFC 1519, September 1993.

[RFC 1738] Berners-Lee, T., Masinter L., And M. McCahill. "Uniform Resource Locators (URL)", RFC 1738, December 1994.

[RFC 1778] HOWES, T., KILLE S., YEONG, W. AND C. Robbins. "The String Representation of Standard Attribute Syntaxes," RFC 1778, MARCH 1995.

[RFC 1883] Deering, S. And R. Hinden. "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, DECEMBER 1995.

[RFC 2119] BRADNER, S., "Key Words for Use in RFCS to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC 2247] Kille, S., Wahl, M., Grimstad, A., Huber, R. And S. Sataluri. "Using Domains in LDAP / X.500 DISTINGUISHED NAMES", RFC 2247, January 1998.

[RFC 2277] AlvesTrand, H., "Ietf Policy On Character Sets and Languages, RFC 2277, January 1998.

[RFC 2279] Yergeau, F., "UTF-8, A Transformation Format of ISO 10646", RFC 2279, January 1998.

[RFC 2313] Kaliski, B., "PKCS # 1: RSA Encryption Version 1.5", RFC 2313, March 1998. [SDN.701] SDN.701, "Message Security Protocol 4.0", Revision A 1997-02-06.

[X.208] CCITT Recommendation X.208: Specification Of Abstract Syntax Notation One (ASN.1), 1988.

[X.501] ITU-T Recommendation X.501: Information Technology - Open Systems Interconnection - The Directory: Models, 1993.

[X.509] ITU-T Recommendation X.509 (1997 E): Information Technology - Open Systems Interconnection - The Directory: Authentication Framework, June 1997.

[X.520] ITU-T Recommendation X.520: Information Technology - Open Systems Interconnection - The Directory: Selected Attribute Types, 1993.

[X9.42] ANSI X9.42-199X, Public Key Cryptography For the Financial Services Industry: Agreement of Symmetric Algorithm Keys Using Diffie-Hellman (Working Draft), December 1997.

[X9.55] ANSI X9.55-1995, PUBLIC Key Cryptography for the Financial Services Industry: Extensions to public Key Certificates and Certificate Revocation Lists, 8 December, 1995.

[X9.57] ANSI X9.57-199X, Public Key Cryptography for the Financial Services Industry: Certificate Management (Working Draft), 21 June, 1996.

9 intellectual property

IETF has notified that some or all of the proposed intellectual property declarations included in this article. For more information, check the online list of request information.

IETF's validity or scope of any intellectual property or other rights may not be positioned, which can be required to obtain a tool or used in this article or extend to any license to it or not effective; it It does not mean that it has made any effort to think that any rights are equivalent. Information documentation on IETF's Standards-Track and Standards-Related) can be found in BCP 11. Copy declaration rights are available for publication and any guaranteed license, or try to get a universal licensed result or by tools to approve the rights of all people or users used in this article from the IETF secretary. 10 Safety consideration

Most of this document is dedicated to the format and content of the certificate and CRLs. Since the certificate and CRLS are digital signatures, no additional integrity services are inevitable. Regardless of the certificate or CRLS, it is not necessary to maintain a secret, and unlimited and anonymous access certificates and CRLs have no security intensity.

However, security factors exceeding the scope of this article will affect the guarantee provided to the certificate user. This part emphasizes serious problems and should be considered by tools, administrative personnel and users.

The binding of the identity of their public key that is very approved by the CAS and RAS execution process should be put into the guarantee of the certificate. Relying on party that can want to review CA's certificate practice statement (CERTIFICATE PRACTICETEMENT). This can be particularly important when the certificate is distributed to other CAS.

A single key pair is intensively block used for signatures and other purposes. The independent key is provided for the user's use of the user for the use of the signature and key management. Unlike the loss or expiration of the key management key, link the derivative of the results and the signature key or expire. Use a stand-alone key to allow a balanced and elastic answer. Similarly, for each key to different validity periods or key lengths can be suitable in some applications. Unfortunately, some legacy (traditional) applications (such as SSL) use a single key pair for signature and key management.

To provide a private key is a key factor in maintaining security. In a small size, the user's unable to defend their private key will allow an attacker to pretend to be them or decompipsed their personal information. Large-scale, a private signature key for a CA can have a disaster. If an attacker gets a private key (not noticed), an attacker can issue a fake certificate and CRLS. The fake certificate and the existence of CRLs will damage the trust on the system. If the damage is aware, all of the issued CA certificates will be canceled to prevent service between users and users of other CAS. After such damage, the reconstruction will be problematic, so it is recommended that CAS performs a combination of strong technical measures (such as the codenic modules of anti-interference (Tamper-Resistant) and the management process that avoids such an event (for example Separation of responsibilities).

The loss of a private signature key for a CA may also have problems. CA will not produce CRLS or perform normal key roll over. It is recommended that the CAS maintains the backup of the signature key. The security of the key backup process is a key factor in avoiding key damage.

The effectiveness of the revocation of information and the refresh will affect the level of warranty should be placed in a certificate. While the certificate is naturally expired, it can occur in its natural life event, which is negative between the subject and the public key. If the revocation information is not suitable or unaffected, the guarantee is significantly reduced and the binding link. Similarly, the tools that delete the revocation check of the path approval algorithm in paragraph 6 provide less guarantees than those that support it.

The path approval algorithm depends on the public key (and other information) about one or more trusted CAS determination knowledge. When it finally determines the certificate provided by trust, it is an important decision to trust a CA when it is trustworthy. Authorization (usually in the form of a "self-signed" certificate) is a key security, which exceeds the process range described herein.

In addition, the key damage or CA fails to be a trusted CA, and the user will need to modify, provide information to the path approval. Choosing too many trusted CAs will make trusted CA information difficult to maintain. On the other hand, only one trusted CA is limited to only one community is valid, unless global PKI appears. The quality of the tool to publish the certificate can also affect the extent to which the guarantee is provided. In paragraph 6, the integrity of the path approval algorithm is described with trusted CA information, and the integrity of the special disclosure key and the combination of trusted CAS. A attacker can deceive users to accept false certificates by replacing the public key (relatively private key of its attacker).

Binding between a key and certificate subject cannot be a stronger than the password module tool and algorithm to generate a signature. Short key length or weakchid algorithm will limit the function of a certificate. CAS is facilitated in the progress of cryptography, so they can use high-intensity cryptography technology. In addition, CAS should refuse to issue certificates to the production of weakly signed CAS or end entities.

The inconsistency application of the name comparisons may result in an accepted invalid X.509 certification path result or reject the valid certificate path. The text description of the X.500 series defines a comparative comparison of rules that compare unique names regardless of these situations, character sets, multiple characters (multi-character) blank strings or head and end blank characters. This article describes these needs and requires support for binary comparisons at a minimum.

CAS will be encoded in the Identification of Names in the topic field of a CA certificate in the issuer field in the issuer field in the certificate issued after the latter CA. If CAS uses a different Encodings (rule), the tool described in this article may fail to identify the name chain with the path containing this certificate. Therefore, the effective path will be rejected.

In addition, it will be configured to identify the identifiable name name to the encoding in the same manner to the subject field or the SubjectAltAme extension. If not, (1) as an ExcludedSubtrees name constraint statement will not match and invalid path will be received, (2) and as a permittedSubtrees name constraint indicate that the mismatch and the valid path will be rejected. Avoid accepting invalid paths, CAS should state confinement of names that may be identified as PermittedSubtrees.

Appendix A. Psuedoasn.1 Structure and OIDS

This part depicts the data object and is consistent with the PKI component in the "ASN.1-Like" syntax. This sentence is a mixture of 1988 and 1993 ASN.1 syntax. The 1993 Universal Type Universalsalingtring, BmpString, and Utf8String, 1988 ASN.1 syntax.

The ASN.1 syntax does not allow in the ASN.1 module, including type statements, and 1993 ASN.1 standards are not allowed to use a new universal type of new universal types of 1988 syntax in the module. Therefore, this module does not follow any version of the ASN.1 standard.

This appendix can be converted to the 1988 ASN.1 by capturing the universal type with 1988 "ANY" instead of DEFINTIONS.

A.1 Explicit Tagged Module, 1988 syntax

PKIX1EXPLICIT88 {ISO (1) Identified-Organization (3) DOD (6) Internet (1) Security (5) Mechanisms (5) PKIX (7) ID-mod (0) ID-PKIX1-EXPLICIT-88 (1)}

Definitions expendit tags :: = begin

- exports all -

- IMPORTS NONE -

- universal type defined in '93 and '98 asn.1 - But Required by this specification

Universaling :: = [Universal 28] Implicit OcTet String - UniversalingTRING IS Defined in AsN.1: 1993

Bmpstring :: = [Universal 30] Implicit OcTed string - bmpstring is the subtype of universaling and models - The Basic Multilingual Plane of ISO / IEC / ITU 10646-1

UTF8String :: = [Universal 12] Implicit OCTET STRING - The Content of this Type Conforms To RFC 2279.

---- Pkix Specific OIDS

ID-PKIX Object Identifier :: = {ISO (1) Identified-Organization (3) DOD (6) Internet (1)

Security (5) Mechanisms (5) PKIX (7)} - Pkix Arcs

ID-pe Object Identifier :: = {ID-PKIX 1} - Arc for private certificate extensions - qt object identifier :: = {id-pkix 2} - arc for policy qualifier typeesid-kp Object Identifier :: = {ID -pkix 3} - arc for extended Key Purpose Oidsid-Ad Object Identifier :: = {ID-PKIX 48} - Arc for Access Descriptors

- PolicyQualifierids for Internet Policy QualifierS

ID-QT-CPS Object Identifier :: = {ID-QT 1} - Oid for CPS Qualifierid-Qt-Unotice Object Identifier :: = {ID-Qt 2} - Oid for User NOTICE QUALIFIER

- Access Descriptor definitions

ID-Ad-Ocsp Object Identifier :: = {ID-AD 1} ID-Ad-Caissuers Object Identifier :: = {ID 2}

- Attribute data types -

Attribute :: = sequence {Type AttributeType, VALUES Set of AttributeValue - At Least One Value Is Required -} attributetype :: = Object Identifier

AttributeValue :: = any

AttributeTypeAndValue :: = sequence {Type AttributeType, Value AttributeValue}

- suggested naming attributes: Definition of the following-- information object set may be augmented to meet local-- requirements Note that deleting members of the set may-- prevent interoperability with conforming implementations .-- presented in pairs: the AttributeType followed. By The Corresponding AttributeValue

--Arc for standard naming attributesid-at object identifier :: = {Joint-ISO-CCITT (2) DS (5) 4}

- Attributes of type NameDirectoryStringid-at-name AttributeType :: = {id-at 41} id-at-surname AttributeType :: = {id-at 4} id-at-givenName AttributeType :: = {id-at 42} ID-At-Initials AttributeType :: = {ID-AT 43} ID-AT-GENERATION Qualifier AttributeType :: = {ID-AT 44}

X520name :: = CHOICE {teletexString TeletexString (SIZE (1..ub-name)), printableString PrintableString (SIZE (1..ub-name)), universalString UniversalString (SIZE (1..ub-name)), utf8String UTF8String (Size (1..ub-name)), bmpstring bmpstring (size (1..ub-name)}

ID-AT-CommonName AttributeType :: = {ID-AT 3} x520commonname :: = choاELETEXSTRING TELETEXSTRING (SIZE (1..UB-Common-name), Printablestring Printablestring (Size ))), Universalstring universalstring (size (1..ub-common-name)), UTF8String Utf8String (Size (1..UB-Common-name), bmpstring bmpstring (size (1..UB-compon-name)) }

ID-At-localityName AttributeType :: = {ID-AT 7}

X520LocalityName :: = CHOICE {teletexString TeletexString (SIZE (1..ub-locality-name)), printableString PrintableString (SIZE (1..ub-locality-name)), universalString UniversalString (SIZE (1..ub-locality- Name)), UTF8String Utf8String (Size (1..ub-locality-name), bmpstring bmpstring (size (1..UB-locality-name)}

ID-AT-stateorProvinCename AttributeType :: = {ID-AT 8}

X520StateOrProvinceName :: = CHOICE {teletexString TeletexString (SIZE (1..ub-state-name)), printableString PrintableString (SIZE (1..ub-state-name)), universalString UniversalString (SIZE (1..ub-state- Name)), utf8string utf8string (size (1..UB-state-name), bmpstring bmpstring (size (1..UB-state-name)}

ID-At-OrganizationName AttributeType :: = {ID-AT 10}

X520OrganizationName :: = CHOICE {teletexString TeletexString (SIZE (1..ub-organization-name)), printableString PrintableString (SIZE (1..ub-organization-name)), universalString UniversalString (SIZE (1..ub-organization- Name)), uTF8String Utf8String (Size (1..UB-Organization-name), bmpstring bmpstring (size (1..ub-Organization-name)}

ID-At-OrganizationalUnitName AttributeType :: = {ID-AT 11}

X520OrganizationalUnitName :: = CHOICE {teletexString TeletexString (SIZE (1..ub-organizational-unit-name)), printableString PrintableString (SIZE (1..ub-organizational-unit-name)), universalString UniversalString (SIZE (1 .. Ub-organizational-unit-name)), uTF8String Utf8String (Size (1..ub-Organizational-Unit-Name), bmpstring bmpstring (size (1..UB-Organizational-Unit-Name)}

ID-At-Title AttributeType :: = {ID-AT 12}

X520Title :: = CHOICE {teletexString TeletexString (SIZE (1..ub-title)), printableString PrintableString (SIZE (1..ub-title)), universalString UniversalString (SIZE (1..ub-title)), utf8String UTF8String (Size (1..ub-title), bmpstring bmpstring (size (1..ub-title)}

ID-At-DNQualifier AttributeType :: = {ID-AT 46} X520Dnqualifier :: = Printablestring

ID-At-CountryName AttributeType :: = {ID-AT 6} X520COUNTRYNAME :: = PrintableString (Size (2)) - IS 3166 CODES

- Legacy Attributes

PKCS-9 Object Identifier :: = {ISO (1) Member-body (2) US (840) RSADSI (113549) PKCS (1) 9}

EmailAddress AttributeType :: = {PKCS-9 1}

PKCS9EMAIL :: = IA5STRING (Size (1..ub-emaildress-length))

- Naming Data Types -

Name :: = choice {- only one possibility for now - rdnsequence rdnsequence}

RDNSEQUENCE :: = sequence of relativeiStinguishedName

DistinguishedName :: = rdnsequence

RelativedistinguishedName :: = set size (1 .. max) of attributeTypeAndValue

- Directory String Type -

- Certificate and CRL Specific Structure Begin Here

Certificate :: = sequence {Tbscertificate Tbscertificate, SignatureAlgorithm Algorithmidentifier, Signature Bit String}

TBSCertificate :: = SEQUENCE {version [0] Version DEFAULT v1, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, - If present, version shall be v2 or V3 SubjectUnique; - if present, Version Shall Be v2 or v3 extensions [3] Extensions Optional - IF present, Version Shall Be v3 -} version :: = integer {v1 (0), V2 (1), V3 (2)}

CertificateserialNumber :: = integer

Validity :: = sequence {Notbefore Time, NOTAFTER TIME}

Time :: = choice {utctime utctime, generaltime generalizedtime}

UNIQUEIDENTIFIER :: = Bit String

SubjectpublicKeyInfo :: = sequence {Algorithm Algorithmidentifier, SubjectPublicKey bit string}

Extensions :: = sequence size (1..max) of extension

Extension :: = sequence {EXTNID Object Identifier, critical boolean default false, ext nValue octet string}

- CRL STRUCTURES

CertificateList :: = sequence {Tbscertlist Tbscertlist, SignatureAlGorithm Algorithmidentifier, Signature Bit String}

TBSCertList :: = SEQUENCE {version Version OPTIONAL, - if present, shall be v2 signature AlgorithmIdentifier, issuer Name, thisUpdate Time, nextUpdate Time OPTIONAL, revokedCertificates SEQUENCE OF SEQUENCE {userCertificate CertificateSerialNumber, revocationDate Time, crlEntryExtensions Extensions OPTIONAL - if present, SHALL BE V2} Optional, CRLEXTensions [0] Extensions Optional - IF present, Shall Be V2 -} - Version, Time, CertificateSerialNumber, And Extensions Were - Defined Earlier for Use in the Certificate Structure

Algorithmidentifier :: = sequence {

Algorithm Object Identifier, Parameters Any Defined by Algorithm Optional} - Contains a Value of The Type - Registered for Use with the - Algorithm Object Identifier Value

- Algorithm Oids and Parameter Structure

PKCS-1 Object Identifier :: = {ISO (1) MEMBER-BODY (2) US (840) Rsadsi (113549) PKCS (1) 1}

Rsaencryption Object Identifier :: = {PKCS-1 1}

Md2withrsaencryption Object Identifier :: = {PKCS-1 2}

MD5withrsaencryption Object Identifier :: = {PKCS-1 4}

SHA1WITHRSAENCRYPTION Object Identifier :: = {PKCS-1 5}

ID-DSA-with-sha1 Object Identifier :: = {ISO (1) MEMBER-BODY (2) US (840) x9-57 (10040) x9algorithm (4) 3} DSS-SIG-VALUE:: = SEQUENCE {R Integer, s integer}

DHPUBLICNUMBER Object Identifier :: = {ISO (1) MEMBER-BODY (2) US (840) ANSI-X942 (10046) Number-Type (2) 1}

Domainparameters :: = sequence {p integer, - odd prime, p = jq 1 g Integer, - Generator, g teger, - Factor of P-1 J Integer Optional, - Subgroup Factor, J> = 2 ValidationParms ValidationParms Optional}

ValidationParms :: = sequence {seed bit string, pgencounter integer}

ID-DSA Object Identifier :: = {ISO (1) Member-Body (2) US (840) X9-57 (10040) X9algorithm (4) 1}

DSS-PARMS :: = SEQUENCE {P INTEGER, Q INTEGER, G Integer}

- x400 address syntax starts here - or name

ORAddress :: = SEQUENCE {built-in-standard-attributes BuiltInStandardAttributes, built-in-domain-defined-attributes BuiltInDomainDefinedAttributes OPTIONAL, - see also teletex-domain-defined-attributes extension-attributes ExtensionAttributes OPTIONAL} - The OR-address Is semantically absent from the or-name if the - built-in-standard-attribute sequence is empty and the-- built-in-domain-defined-attributes and extension-attributes are - Both OMIMITTED.

- Built-in Standard Attributes

BuiltInStandardAttributes :: = SEQUENCE {country-name CountryName OPTIONAL, administration-domain-name AdministrationDomainName OPTIONAL, network-address [0] NetworkAddress OPTIONAL, - see also extended-network-address terminal-identifier [1] TerminalIdentifier OPTIONAL, private-domain -name [2] PrivateDomainName OPTIONAL, organization-name [3] OrganizationName OPTIONAL, - see also teletex-organization-name numeric-user-identifier [4] NumericUserIdentifier OPTIONAL, personal-name [5] PersonalName OPTIONAL, - see also teletex-personal-name organizational-unit-names [6] OrganizationalUnitNames OPTIONAL - see also teletex-organizational-unit-names -} CountryName :: = [APPLICATION 1] CHOICE {x121-dcc-code NumericString (SIZE (ub- Country-name-numeric-length), ISO-3166-Alpha2-Code Printablestring (SIZE (UB-Country-Alpha-Length)}

AdministrationDomainName :: = [Application 2] choice {numeric numericString (size (0..UB-DOMAIN-NAME-length), Printable Printablestring (Size (0..UB-DOMAIN-NAME-length)

NetWorkaddress :: = x121address - See Also Extended-Network-Address

X121Address :: = numericString (size (1..UB-x121-address-length))

TerminalIdentifier :: = Printablestring (size (1..ub-terminal-id-length))

PrivateDomainName :: = choice {

Numeric NumericString (SIZE (1..ub-domain-name-length), Printable Printablestring (Size (1..ub-domain-name-length)}

OrganizationName :: = Printablestring (Size (1..ub-Organization-name-length) - See Also Telex-Organization-NameNumericUserIndifier :: = NumericString (Size (1..UB-NUMERIC-User-ID-length))

PersonalName :: = set {surname [0] Printablestring (size (1..ub-shipth), given-name [1] Printablestring (Size (1..ub-given-name-length) Optional, Initials [2] Printablestring (Size (1..ub-initials-length) Optional, Generation-Qualifier [3] Printablestring (Size (1..UB-generation-qualifier-length) optional} - See Also Teletex-Personal -Name

OrganizationalUnitNames :: = sequence size (1..ub-organizational-units) of OrganizationalUnitName - See Also Teletex-Organizational-Unit-Names

OrganizationalUnitName :: = Printablestring (Size (1..ub-Organizational-Unit-Name-length))

- Built-in Domain-Defined Attributes

BuiltindomainDefinedattributes :: = sequence size (1..ub-domain-defined-attributes) of builtindomainDefinedattribute

BuiltInDomainDefinedAttribute :: = SEQUENCE {type PrintableString (SIZE (1..ub-domain-defined-attribute-type-length)), value PrintableString (SIZE (1..ub-domain-defined-attribute-value-length))}

- Extension Attributes

Extensionattributes :: = set size (1..UB-extension-attributes) of extensionattribute

ExtensionAttribute :: = sequence {extension-attribute-type [0] integer (0..UB-EXTENSION-Attributes), extension-attribute-value [1] any defined by extension-attribute-type}

- EXTENSION TYPES AND TRIBUTE VALUES -

Common-name integer :: = 1

Commonname :: = Printablestring (SIZE (1..ub-compon-name-length))

Teletex-Common-Name Integer :: = 2

TeletexComMonname :: = TeletexString (Size (1..ub-compon-name-length))

Teletex-Organization-Name Integer :: = 3

Telexorganizationname :: = TeletexString (Size (1..ub-Organization-name-length))

Teletex-Personal-Name Integer :: = 4

TeletexPersonalName :: = set {surname [0] TeleXString (size (1..UB-Surname-length), given-name [1] TeletexString (size (1..UB-given-name-length) optional, Initials [2] TeleTexString (Size (1..ub-initials-length) Optional, Generation-Qualifier [3] TeleTexString (Size (1..UB-generation-qualifier-length) optional}

Teletex-Organizational-Unit-Names INTEGER :: = 5

TelexorganizationalUnitNames :: = sequence size (1..ub-Organizational-Units) of teletexorganizationalunitname

TelexorganizationalUnitName :: = TeletexString (Size (1..ub-Organizational-Unit-Name-length))

PDS-Name Integer :: = 7

PDSNAME :: = Printablestring (size (1..ub-pds-name-length) Physical-Delivery-Country-name integer :: = 8

PhysicalDeliveryCountryName :: = CHOICE {x121-dcc-code NumericString (SIZE (ub-country-name-numeric-length)), iso-3166-alpha2-code PrintableString (SIZE (ub-country-name-alpha-length))}

Postal-code integer :: = 9

Postalcode :: = choice {

Numeric-code numericString (Size (1..ub-postal-code-length), Printable-code Printablestring (Size (1..ub-postal-code-length)}

Physical-Delivery-Office-Name Integer :: = 10

PhysicalDeliveryOffIname :: = PDSPARETER

Physical-Delivery-Office-Number Integer :: = 11

PhysicalDeliveryOffInumber :: = pdsparameter

EXTENSION-OR-Address-Components Integer :: = 12

ExtensionoraDresComponents :: = PDSPARAMETER

Physical-Delivery-Personal-Name Integer :: = 13

PhysicalDeliveryPersonalName :: = PDSPARAMETER

Physical-Delivery-Organization-Name Integer :: = 14

PhysicalDeliveryorganizationName :: = pdsparameter

EXTENSION-Physical-Delivery-Address-Components Integer :: = 15

ExtensionPhysicalDeliveryAddressComponents :: = PDSPARAMETER

unformatted-postal-address integer :: = 16

UnformattedPostalAddress :: = SET {printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines) OF PrintableString (SIZE (1..ub-pds-parameter-length)) OPTIONAL, teletex-string TeletexString (SIZE (1..UB-unformatted-address-length) optional}

Street-address integer :: = 17

StreetAddress :: = pdsparameterpost-office-box-address integer :: = 18

PostOfficeBoxAddress :: = pdsparameter

Poste-Restante-Address Integer :: = 19

Posterestanteaddress :: = PDSPARAMETER

Unique-postal-name integer :: = 20

Uniquepostalname :: = PDSPARAMETER

Local-postal-attributes integer :: = 21

LocalPostalattributes :: = PDSPARAMETER

Pdsparameter :: = set {printable-string printablestring (Size (1..UB-PDS-Parameter-length) Optional, Teletex-String TeleXstring (Size (1..UB-PDS-Parameter-length) optional}

Extended-network-address integer :: = 22

ExtendedNetworkAddress :: = choic {e163-4-address sequence {number [0] numericString (size (1..UB-E163-4-Number-length), Sub-address [1] numericString (Size (1..UB -E163-4-sub-address-length) Optional}, psap-address [0] presentationAddress}

PresentationAddress :: = SEQUENCE {pSelector [0] EXPLICIT OCTET STRING OPTIONAL, sSelector [1] EXPLICIT OCTET STRING OPTIONAL, tSelector [2] EXPLICIT OCTET STRING OPTIONAL, nAddresses [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING}

TERMINAL-TYPE INTEGER :: = 23

TERMINALTYPE :: = Integer {Telex (3), Teletex (4), G3-Facsimile (5), G4-Facsimile (6), IA5-Terminal (7), VIDETEX (8)} (0..UB-INTEGER- Options

- Extension Domain-Defined Attributes

TeleTex-domain-defined-attributes integer :: = 6

TeletexDomainDefinedAttributes :: = SEQUENCE SIZE (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttributeTeletexDomainDefinedAttribute :: = SEQUENCE {type TeletexString (SIZE (1..ub-domain-defined-attribute-type-length)), value TeletexString

(SIZE (1..ub-domain-defined-attribute-value-length)}

- Specifications of Upper Bounds Shall Be Regarded As Mandatory - from Annex B of Itu-T X.411 Reference Definition Of MTS Parameter - Upper Bounds

- Upper boundsub-name integer :: = 32768UB-Common-name integer :: = 64ub-locality-name integer :: = 128ub-state-name integer :: = 128ub-organization-name integer :: = 64UB-Organizational- Unit-name integer :: = 64UB-TIGER :: = 64ub-match integer :: = 128

UB-EmailAddress-length integer :: = 128

Ub-common-name-length integer :: = 64ub-country-name-alpha-length integer :: = 2ub-country-name-numeric-length integer :: = 3UB-DOMAIN-Defined-attributes integer :: = 4UB- domain-defined-attribute-type-length INTEGER :: 8ub-domain-defined-attribute-value-length INTEGER :: = 128ub-domain-name-length INTEGER :: = 16ub-extension-attributes INTEGER :: = 256ub- = E163-4-Number-Length Integer :: = 15UB-E163-4-Sub-address-length integer :: = 40ub-generation-qualifier-length integer :: = 3UB-given-name-length integer :: = 16UB- initials-length INTEGER :: = 5ub-integer-options INTEGER :: = 256ub-numeric-user-id-length INTEGER :: = 32ub-organization-name-length INTEGER :: = 64ub-organizational-unit-name-length INTEGER :: = 32UB-Organizational-Units Integer :: = 4UB-PDS-Name-Length Integer :: = 16UB-PDS-Parameter-length Integer :: = 30UB-PDS-Physical-Address-Lines Integer :: = 6ub-Postal -code-length integer :: = 16UB-SURNAME-Length Integer :: = 40UB-TERMINAL-ID-length Integer :: = 24UB-Unformatted-address-length integer :: = 180ub-x121-address-length INTEGER :: = 16-- Note - upper bounds on string types, such as TeletexString, are-- measured in characters Excepting PrintableString or IA5String, a-- significantly greater number of octets will be required. To Hold

-. Such a value As a minimum, 16 octets, or twice the specified upper-- bound, whichever is the larger, should be allowed for TeletexString .-- For UTF8String or UniversalString at least four times the upper-- bound should be ALOWED.

End

A.2 Implicit Tagged Module, 1988 syntax

Pkix1 Implicit88 {ISO (1) Identified-Organization (3) DOD (6) Internet (1) Security (5) MECHANISMS (5) PKIX (7) ID-MOD (0) ID-PKIX1-Implicit-88 (2)} definitions Implicit tags :: =

Begin

- exports all -

Imports ID-PKIX, ID-PE, ID-QT, ID-KP, ID-QT-UNOTICE, ID-QT-CPS, ID-AD, ID-Ad-OCSP, ID-Ad-Caissuers, - Delete Following Line if "new" types are supported - BMPString, UniversalString, UTF8String, - end "new" types ORAddress, name, RelativeDistinguishedName, CertificateSerialNumber, CertificateList, AlgorithmIdentifier, ub-name, Attribute, DirectoryString FROM PKIX1Explicit88 {iso (1) identified- Organization (3) DOD (6) Internet (1) Security (5) Mechanisms (5) PKIX (7) ID-mod (0) ID-PKIX1-Explicit (1)};

- Iso Arc for Standard Certificate and CRL EXTENSIONS

ID-CE Object Identifier :: = {Joint-ISO-CCIT (2) DS (5) 29}

- Authority Key Identifier Oid and Syntax

ID-ce-authorityKeyidentifier Object Identifier :: = {ID-CE 35}

AuthorityKeyIdentifier :: = SEQUENCE {keyIdentifier [0] KeyIdentifier OPTIONAL, authorityCertIssuer [1] GeneralNames OPTIONAL, authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL} - authorityCertIssuer and authorityCertSerialNumber shall both - be present or both be absent

Keyidentifier :: = o o o i--s j i i i

ID-CE-SUBJECTKEYIDENTIFIER OBJECT IDENTIFIER :: = {ID-CE 14}

SubjectKeyIdentifier :: = Keyidentifier

- Key Usage Extension Oid And Syntax

ID-CE-Keyusage Object Identifier :: = {ID-CE 15}

KeyUsage :: = BIT STRING {digitalSignature (0), nonRepudiation (1), keyEncipherment (2), dataEncipherment (3), keyAgreement (4), keyCertSign (5), cRLSign (6), encipherOnly (7), decipherOnly (8 }

- Private Key Usage Period Extension Oid and Syntax

ID-CE-privateKeyusagePeriod Object Identifier :: = {ID-CE 16}

PrivateKeyusagePeriod :: = Sequence {NOTBEFORE [0] generalizedTime Optional, Notafter [1] generalizedtime optional} - Either NOTBEFORE ONOTAFTER Shall Be Present

- Certificate Policies Extension Oid And Syntax

ID-CE-CERTIFICATEPOLICIES OBJECT IDENTIFIER :: = {ID-CE 32}

CertificatePolicies :: = Sequence size (1..max) of policyinformation

PolicyInformation :: = sequence {policyid, policyqualifiers sequence size (1..max) of policyqualifierinfo optional}

CertpolicyID :: = Object Identifier

PolicyqualifierInfo :: = Sequence {PolicyQualifierid PolicyqualifierId, Qualifier Any Defined by PolicyqualifierId}

- Implementations That Recognize Additional Policy Qualifiers Shall - Augment The Following Definition for PolicyQualifieridPolicyQualifierId :: = Object Identifier (ID-QT-CPS | ID-QT-UNOTICE)

- CPS Pointer Qualifier

Cpsuri :: = ia5string

- User NOTICE Qualifier

UserNotice :: = sequence {Noticref NoticReference Optional, ExplicitText Displaytext Optional}

NoticReference :: = sequence {Organization Displaytext, NoticenumBers Sequence of Integer}

Displaytext :: = kice {visibleString VisibleString (size (1..200)), bmpstring bmpstring (size (1..200)), uTF8String Utf8String (Size (1..200))}

- Policy Mapping Extension Oid and Syntax

ID-CE-PolicyMappings Object Identifier :: = {ID-CE 33}

Policymappings :: = sequence size (1..max) of sequence {issuerdomainPolicy CertPolicyId, SubjectDomainPolicy CertpolicyId}

- Subject Alternative Name Extension Oid and Syntax

ID-CE-SUBJECTAME OBJECT Identifier :: = {ID-CE 17}

Subjectaltname :: = generalnames

Generalnames :: = sequence size (1..max) of generalname

GeneralName :: = CHOICE {otherName [0] AnotherName, rfc822Name [1] IA5String, dNSName [2] IA5String, x400Address [3] ORAddress, directoryName [4] Name, ediPartyName [5] EDIPartyName, uniformResourceIdentifier [6] IA5String, iPAddress [ 7] OcTet string, registeredId [8] Object Identifier} - AnotherName Replace} - Name :: = Type-Identifier, As - Type-Identifier IS Not Supported in the '88 Asn.1 Syntax

Anothername :: = sequence {

TYPE-ID Object Identifier, Value [0] Explicit Any Defined by Type-Id}

EDIPARTYNAME :: = Sequence {Nameassigner [0] DirectoryString Optional, Partyname [1] DirectoryString}

- Issuer Alternative Name Extension Oid And Syntax

ID-CE-ISSUERALTNAME OBJECT IDENTIFIER :: = {ID-CE 18}

Issueraltname :: = generalnames

ID-CE-SUBJECTDIRECTORTTRIBUTES Object Identifier :: = {ID-CE 9}

SubjectDirectoryAttributes :: = sequence size (1..max) of attribute

- Basic Constraints Extension Oid And Syntax

ID-CE-BasicConstraints Object Identifier :: = {ID-CE 19}

BasicConstraints :: = sequence {CA Boolean Default False, Pathlenconstraint Integer (0..max) Optional}

- Name Constraints Extension Oid and Syntax

ID-CE-NameConstraints Object Identifier :: = {ID-CE 30}

Nameconstrains :: = sequence {permittedSubtrees [0] generalsubtrees optional, Excludedsubtrees [1] generalsubtrees optional }tribubtrees :: = sequence size (1..max) of generalsubtree

Generalsubtree :: = sequence {base generalname, minimum [0] Basedistance default 0, Maximum [1] Basedistance Optional}

Basedistance :: = integer (0..max)

- Policy Constraints Extension Oid And Syntax

ID-CE-PolicyConstraints Object Identifier :: = {ID-CE 36}

PolicyConstrains :: = sequence {required {required {required [0] Skipcerts Optional,

Inhibolicymapping [1] Skipcerts Optional}

Skipcerts :: = integer (0..max)

- CRL Distribution Points Extension Oid and Syntax

ID-CE-CRLDISTRIBUTIONPOINTS Object Identifier :: = {ID-CE 31}

CRLDistPointssyntax :: = sequence size (1..max) of DistributionPoint

DistributionPoint :: = SEQUENCE {DistributionPoint [0] DistributionPointName Optional, Reasons [1] Reasonflags Optional, CRLISSUER [2] generalnames optional}

DistributionPointName :: = cho1 {fullname [0] generalnames, NameRelativeToCrlissuer [1] relativedistinguishedname}

Reasonflags :: = bit string {unused (0), Keycompromise (1), Cacompromise (2), AffiliationChanged (3), Superseded (4), CassationOfoperation (5), CertificateHold (6)}

- Extended Key Usage Extension Oid and Syntaxid-Ce-ExtKeyusage Object Identifier :: = {ID-CE 37}

EXTKEYUSAGESYNTAX :: = Sequence size (1..max) of keypurposeid

Keypurposeid :: = Object Identifier

- Extended Key Purpose Oidsid-Kp-ServerAuth Object Identifier :: = {ID-KP 1} ID-KP-ClientAuth Object Identifier :: = {ID-KP 2} ID-KP-CODESIGNING OBJECT IDENTIFIER :: = {ID KP 3} ID-KP-EMAILPROTECTION Object Identifier :: = {ID-KP 4} ID-KP-IPSECENDSYSTEM OBJECT IDENTIFIER :: = {ID-KP 5} ID-KP-IPSECTUNEL Object Identifier :: = {ID-KP 6 } ID-kP-ipsecuser object identifier :: = {ID-KP 7} ID-kP-timestamping object identifier :: = {ID-KP 8}

- Authority Info Access

ID-PE-AuthorityInfoAccess Object Identifier :: = {ID-PE 1}

AuthorityInfoAccesssyNTax :: = Sequence Size (1..max) of accessDescription

AccessDescription :: = Sequence {AccessMethod Object Identifier, AccessLocation Generalname}

- CRL Number Extension Oid and Syntax

ID-CE-CRLNUMBER OBJECT IDENTIFIER :: = {ID-CE 20}

CRLNUMBER :: = INTEGER (0..max)

- Issuing Distribution Point Extension Oid and Syntax

ID-CE-ISSUINGDISTRIBUTIONPOINT OBJECT IDENTIFIER :: = {ID-CE 28}

IssuingDistributionPoint :: = SEQUENCE {distributionPoint [0] DistributionPointName OPTIONAL, onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, onlySomeReasons [3] ReasonFlags OPTIONAL, indirectCRL [4] BOOLEAN DEFAULT FALSE}

ID-CE-DELTACRLINDICATOR OBJECT IDENTIFIER :: = {ID-CE 27}

- Deltacrlindicator :: = BasecrlNumberBasecrlNumber :: = CRLNUMBER

- CRL Reasons Extension Oid and Syntax

ID-CE-CRLREASONS Object Identifier :: = {ID-CE 21}

CRLREASON :: = Enumerated {Unspecified (0), Keycompromise (1), Cacompromise (2), Affiliationchanged (3), Superseded (4), CassationOfoperation (5), CertificateHold (6), RemoveFromCRL (8)}

- Certificate Issuer CRL Entry Extension Oid and Syntax

ID-CE-CERTIFICATEISSUER OBJECT IDENTIFIER :: = {ID-CE 29}

Certificateissuer :: = generalnames

- Hold Instruction Extension Oid And Syntax

ID-CE-HOLDINSTRUCODE OBJECT IDENTIFIER :: = {ID-CE 23}

HoldInstructioncode :: = Object Identifier

- ANSI X9 Holdinstructions

- ANSI X9 ARC HOLDINSTRUCTION Archoldinstruction Object Identifier :: = {Joint-ISO-ITU-T (2) MEMBER-BODY (2) US (840) X9cm (10040) 2}

- ANSI X9 holdinstructions referenced by this standardid-holdinstruction-none OBJECT IDENTIFIER :: = {holdInstruction 1} - deprecatedid-holdinstruction-callissuer OBJECT IDENTIFIER :: = {holdInstruction 2} id-holdinstruction-reject OBJECT IDENTIFIER :: = {holdInstruction 3}

- Invalidity Date CRL Entry Extension Oid And Syntax

ID-CE-IVALIDITYDATE OBJECT Identifier :: = {ID-CE 24}

INVALIDITYDATE :: = generalizedtime

End

Appendix B. 1993 ASN.1 Structure And Oids

B.1 Explicit Tagged Module, 1993 Syntha

PKIX1EXPLICIT93 {ISO (1) Identified-Organization (3) DOD (6) Internet (1) Security (5) Mechanisms (5) PKIX (7) ID-mod (0) ID-PKIX1-Explicit-93 (3)} definitions Explicit tags :: =

Begin

- exports all -

IMPORTS authorityKeyIdentifier, subjectKeyIdentifier, keyUsage, extendedKeyUsage, privateKeyUsagePeriod, certificatePolicies, policyMappings, subjectAltName, issuerAltName, basicConstraints, nameConstraints, policyConstraints, cRLDistributionPoints, subjectDirectoryAttributes, cRLNumber, reasonCode, instructionCode, invalidityDate, issuingDistributionPoint, certificateIssuer, deltaCRLIndicator, authorityInfoAccess, id-ce FROM PKIX1Implicit93 {ISO (1) Identified-Organization (3) DOD (6) Internet (1) Security (5) MECHANISMS (5) PKIX (7) ID-mod (0) ID-PKIX1-Implicit-93 (4)};

- - LOCALLY Defined Oids -

ID-PKIX Object Identifier :: = {ISO (1) Identified-Organization (3) DOD (6) Internet (1) Security (5) Mechanisms (5) PKIX (7)}

- pkix arcs - arc for private certificate extensionsId-pe object identifier :: = {id-pkix 1} - arc for policy qualifier typeesid-qt object identifier :: = {id-pkix 2} - arc for extended key purpose OIDSid-kp OBJECT IDENTIFIER :: = {id-pkix 3} - arc for access descriptorsid-ad OBJECT IDENTIFIER :: = {id-pkix 48} - policyQualifierIds for Internet policy qualifiersid-qt-cps OBJECT IDENTIFIER :: = {ID-QT 1} - Oid for CPS Qualifier

ID-QT-UNOTICE Object Identifier :: = {ID-Qt 2} - Oid for User NOTICE Qualifier

- Based on Excerpts from AuthenticationFramework - {Joint-Iso-CCITT DS (5) Modules (1) AuthenticationFramework (7) 2}

- public key certificate -

Certificate :: = SIGNED {SEQUENCE {version [0] Version DEFAULT v1, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, issuerUniqueIdentifier [1] IMPLICIT UniqueIdentifier OPTIONAL, --- if present, version shall BE V2 or V3 - SubjectUniqueIdentifier [2] Implicit UniqueIdentifier Optional, --- if present, Version Shall Be V2 or V3 - Extensions [3] Extensions Optional - IF present, Version Shall Be v3--}}

UNIQUEIDENTIFIER :: = bit string

Version :: = INTEGER {V1 (0), V2 (1), V3 (2)}

CertificateserialNumber :: = integer

Validity :: = sequence {NOTBEFORE TIME, NOTAFTER TIME} Time :: = choic {utctime utctime}

SubjectpublicKeyInfo :: = sequence {Algorithm Algorithmidentifier, SubjectPublicKey bit string}

Extensions :: = sequence size (1..max) of extension

Extension :: = sequence {EXTNID EXTENSITION. & ID ({EXTENSIONSET}), critical Boolean Default False, EXTNVALUE OCTT STRING} - Contains a der Encoding of a value of type

- & extntynpe for the - extension object identified by EXTNID -

- The Following Information Object Set Is Defined To Constrain The - Set of Legal Certificate Extensions.

ExtensionSet EXTENSION :: = {authorityKeyIdentifier | subjectKeyIdentifier | keyUsage | extendedKeyUsage | privateKeyUsagePeriod | certificatePolicies | policyMappings | subjectAltName | issuerAltName | basicConstraints | nameConstraints | policyConstraints | cRLDistributionPoints | subjectDirectoryAttributes | authorityInfoAccess} EXTENSION :: = CLASS {& id OBJECT IDENTIFIER UNIQUE, & ExtnType} WITH SYNTAX {SYNT AX & ExtNType Identified by & id}

- Certificate Revocation List -

CertificateList :: = SIGNED {SEQUENCE {version Version OPTIONAL, - if present, shall be v2 signature AlgorithmIdentifier, issuer Name, thisUpdate Time, nextUpdate Time OPTIONAL, revokedCertificates SEQUENCE OF SEQUENCE {userCertificate CertificateSerialNumber, revocationDate Time, crlEntryExtensions EntryExtensions OPTIONAL} OPTIONAL, CRLEXTensions [0] CRLEXTensions Optional}}

CRLEXTensions :: = sequence size (1..max) of crLlextension

CRLExtension :: = SEQUENCE {extnId EXTENSION & id ({CRLExtensionSet}), critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING.} - contains a DER encoding of a value of type - & ExtnType for the - extension object identified by extnId -

- The Following Information Object Set is defined to constrain the - set of legal crl extensions.

CRLEXTensionSet Extension :: = {AuthorityKeyIdentifier | IssueraltName | CRLNUMBER | DELTACRLINDICATOR | IssuingDistributionPoint}

- Extension Defined Above for Certificate

EntryExtensions :: = sequence size (1..max) of entryextension

EntryExtension :: = SEQUENCE {extnId EXTENSION & id ({EntryExtensionSet}), critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING.} - contains a DER encoding of a value of type - & ExtnType for the - extension object identified by extnId -

- The Following Information Object Set is defined to constrain the - set of legal crl entry extensions.

EntryExtensionSet Extension :: = {REASONCODE | INSTRUCTIONCODE | INVALIDITYDATE | CertificateInsuer}

- Information Object Classes Used in The Defintion - - Of Certificates and CRLs -

- Parameterized Type Signed - Signed {Tobesigned} :: = Sequence {Tobesigned Tobesigned, Algorithm Algorithmidentifier, Signature Bit String}

- Definition of Algorithmidentifier - Iso Definition WAS: -

- AlgorithmIdentifier :: = SEQUENCE {-. Algorithm ALGORITHM & id ({SupportedAlgorithms}), -. Parameters ALGORITHM & Type ({SupportedAlgorithms} - {@algorithm}) OPTIONAL} - Definition of ALGORITHM-- ALGORITHM :: = TYPE-IDENTIFIER

- The Following Pkix Definition Replace The X.509 Definition -

Algorithmidentifier :: = sequence {algorithm algorithm-id. & Id ({supportedalgorithms}), parameters algorithm-id. & Type ({supportedalgorithms} {@algorithm}) Optional}

- Definition of algorithm-id

Algorithm-id :: = Class {& ID Object Identifier Unique, & Type Optional} with syntax {oid & id [parms & type]}

- The definition of SupportedAlgorithms may be modified as this-- document does not specify a mandatory algorithm set In addition, -. The set is specified as extensible, since additional algorithms-- may be supported

SupportedAlgorithms ALGORITHM-ID :: = {..., - extensible rsaPublicKey | rsaSHA-1 | rsaMD5 | rsaMD2 | dssPublicKey | dsaSHA-1 | dhPublicKey} - OIDs and parameter structures for ALGORITHM-IDs used-- in this specification

RsapublicKey Algorithm-id :: = {Oid Rsaencryption Parms Null}

RSASHA-1 Algorithm-id :: = {Oid Sha1withrsaencryption Parms Null}

RSAMD5 Algorithm-id :: = {Oid MD5withrsaencryption Parms Null}

RSAMD2 Algorithm-id :: = {Oid Md2withrsaencryption Parms Null}

DSspublicKey Algorithm-id :: = {Oid ID-DSA PARMS DSS-PARMS}

DSASHA-1 Algorithm-id :: = {Oid ID-DSA-with-sha1}

DHPUBLICKEY Algorithm-id :: = {Oid DHPUBLICNUMBER PARMS Domainparameters}

- Algorithm Identifiers and Parameter Structures

PKCS-1 Object Identifier :: = {ISO (1) MEMBER-BODY (2) US (840) Rsadsi (113549) PKCS (1) 1}

Rsaencryption Object Identifier :: = {PKCS-1 1}

Md2withrsaencryption Object Identifier :: = {PKCS-1 2}

MD5withrsaencryption Object Identifier :: = {PKCS-1 4}

SHA1WITHRSAENCRYPTION Object Identifier :: = {PKCS-1 5}

ID-DSA-with-sha1 Object Identifier :: = {ISO (1) Member-body (2) US (840) x9-57 (10040) x9algorithm (4) 3}

DSS-SIG-VALUE :: = SEQUENCE {R integer, s integer}

DHPUBLICNUMBER Object Identifier :: = {ISO (1) Member-body (2) US (840) ANSI-X942 (10046) Number-Type (2) 1} Domainparameters :: = Sequence {P Integer, - Odd Prime, P = JQ 1 G Integer, - Generator, G teger, - Factor of P-1 J Integer Optional, - Subgroup Factor, J> = 2 validationParms ValidationParms Optional}

ValidationParms :: = sequence {seed bit string, pgencounter integer}

ID-DSA Object Identifier :: = {ISO (1) Member-Body (2) US (840) X9-57 (10040) X9algorithm (4) 1}

DSS-PARMS :: = SEQUENCE {P INTEGER, Q INTEGER, G Integer}

- the asn.1 in this section interface supports the name type - and the directoryattribute extension

- Attribute data types -

Attribute :: = sequence {type attribute. & Id ({supportedattributes}), Values Set size (1 .. max) of attribute. & Type ({supportedattributes} {@ type})}

AttributeTypeAndValue :: = Sequence {Type Attribute. & ID ({supportedattributes}), value attribute. & Type ({supportedattributes} {@ type})}

- Naming Data Types -

Name :: = choice {- only one possibility for now - rdnsequence rdnsequence}

RDNSEQUENCE :: = sequence of relativeiStinguishedName

RELATIVEDISTINGUISHEDNAME :: = set size (1 .. max) of attributetypendvalueid :: = Object Identifier

- Attribute Information Object Class Specification - NOTE: This Has Been Greatly Simplified for Pkix !!

Attribute :: = Class {& Type, & ID Object Identifier Unique} with Syntax {with Syntax & Type Id & id}

- suggested naming attributes-- Definition of the following information object set may be-- augmented to meet local requirements Note that deleting-- members of the set may prevent interoperability with-- conforming implementations..

SupportedAttributes ATTRIBUTE :: = {name | commonName | surname | givenName | initials | generationQualifier | dnQualifier | countryName | localityName | stateOrProvinceName | organizationName | organizationalUnitName | title | pkcs9email}

Name attribute :: = {

With syntax directoryString {ub-name} ID ID-at-name}

Commonname attribute :: = {with syntax directoryString {ub-common-name} ID ID-at-commonname}

Surname Attribute :: = {with syntax directoryString {ub-name} ID ID-at-spurname}

Givenname attribute :: = {with syntax directoryString {ub-name} id- at-givenname}

initials ATTRIBUTE :: = {WITH SYNTAX DirectoryString {ub-name} ID id-at-initials} generationQualifier ATTRIBUTE :: = {WITH SYNTAX DirectoryString {ub-name} ID id-at-generationQualifier}

DNQUALIFIER Attribute :: = {with syntax printablestring id id- at-dnqualifier}

CountryName Attribute :: = {with Syntax Printablestring (size (2)) - IS 3166 CODES ONLY ID ID - At-CountryName}

LocalityName Attribute :: = {with syntax directoryString {ub-locality-name} ID ID-at-localityname}

StateorProvincename Attribute :: = {with syntax directoryString {ub-state-name} ID ID-at-stateorprovincename}

OrganizationName Attribute :: = {with Syntax DirectoryString {UB-Organization-Name} ID ID-At-OrganizationName}

OrganizationAtName Attribute :: = {Ub-OrganizationAl-Unit-Name} ID-at-OrganizationalUnitName}

Title Attribute :: = {UB-TITLE} ID ID-At-Title}

- Legacy Attributes

PKCS9EMAIL Attribute :: = {with syntax phgstring, ID emaildress} phgstring :: = @String (Size (1..UB-Emailaddress-length)

PKCS-9 Object Identifier :: = {ISO (1) Member-body (2) US (840) RSADSI (113549) PKCS (1) 9}

EmailAddress Object Identifier :: = {PKCS-9 1}

- Object Identifiers for Name Type and Directory Attribute Support

- Object Identifier Assignments -

ID-AT Object Identifier :: = {Joint-ISO-CCIT (2) DS (5) 4}

- Attributes -

ID-AT-COMMONNAME Object Identifier :: = {ID-AT 3} ID-At-Surname Object Identifier :: = {ID-AT 4} ID-At-CountryName Object Identifier :: = {ID 6} ID At-localityName Object Identifier :: = {ID-AT 7} id-at-stateorProvincename Object Identifier :: = {ID-AT 8} ID-At-OrganizationName Object Identifier :: = {ID-AT 10} ID-At- OrganizationalUnitName Object Identifier :: = {ID-AT 11} ID-At-Title Object Identifier :: = {ID-AT 12} ID-At-Name Object Identifier :: = {ID-AT 41} ID-At-Givenname Object Identifier :: = {ID-AT 42} id-at-initials object identifier :: = {ID-AT 43} ID-at-generationqualifier object identifier :: = {ID-AT 44} ID-At-DNQualifier Object Identifier: : = {ID-AT 46}

- Directory String Type, Used Extensively in Name Types -

DirectoryString {INTEGER: maxSize} :: = CHOICE {teletexString TeletexString (SIZE (1..maxSize)), printableString PrintableString (SIZE (1..maxSize)), universalString UniversalString (SIZE (1..maxSize)), bmpString BMPString ( Size (1..maxsize)

- the asn.1 in this section.

- The OR-address is semantically absent from the OR-name if the-- built-in-standard-attribute sequence is empty and the-- built-in-domain-defined-attributes and extension-attributes are-- both omitted .

- Built-in Standard Attributes

AdministrationDomainName :: = [Application 2] choice {numeric numericString (size (0..UB-DOMAIN-NAME-length), Printable Printablestring (Size (0..UB-DOMAIN-NAME-length)

Networkaddress :: = x121address - See Also Extended-Network-AddRESS

X121Address :: = numericString (size (1..UB-x121-address-length))

TerminalIdentifier :: = Printablestring (size (1..ub-terminal-id-length))

PrivateDomainName :: = choice {numeric numericString (Size (1..ub-domain-name-length), Printable Printablestring (Size (1..ub-domain-name-length)}

OrganizationName :: = Printablestring (Size (1..ub-Organization-name-length) - See Also Telex-Organization-NameNumericUserIndifier :: = NumericString (Size (1..UB-NUMERIC-User-ID-length))

OrganizationalUnitNames :: = sequence size (1..ub-organizational-units) of OrganizationalUnitName - See Also Teletex-Organizational-Unit-Names

OrganizationalUnitName :: = Printablestring (Size (1..ub-Organizational-Unit-Name-length))

- Built-in Domain-Defined AttributesBuiltindomainDefinedAttributes :: = Sequence Size (1..ub-domain-defined-attributes) of BuiltinDefinedAttribute

BuiltInDomainDefinedAttribute :: = SEQUENCE {type PrintableString (SIZE (1..ub-domain-defined-attribute-type-length)), value PrintableString (SIZE (1..ub-domain-defined-attribute-value-length))}

- Extension AttributeSextensionAttributes :: = set size (1..ub-extension-attributes) of extensionattributeExtensionattribute :: = sequence {

extension-attribute-type [0] EXTENSION-ATTRIBUTE. & id ({ExtensionAttributeTable}), extension-attribute-value [1] EXTENSION-ATTRIBUTE. & Type ({ExtensionAttributeTable} {@ extension-attribute-type})}

Extension-attribute :: = Class {& ID Integer (0..UB-EXTENSION-Attributes) Unique, & Type} with syntax {& type identified by & id}

ExtensionAttributeTable EXTENSION-ATTRIBUTE :: = {common-name | teletex-common-name | teletex-organization-name | teletex-personal-name | teletex-organizational-unit-names | teletex-domain-defined-attributes | pds-name | physical-delivery-country-name | postal-code | physical-delivery-office-name | physical-delivery-office-number | extension-OR-address-components | physical-delivery-personal-name | physical-delivery-organization- name | extension-physical-delivery-address-components | unformatted-postal-address | street-address | post-office-box-address | poste-restante-address | unique-postal-name | local-postal-attributes | extended- Network-address | terminal-type}

- Extension Standard Attributes

Common-name extension-attribute :: = {CommonName Identified by 1}

Commonname :: = Printablestring (SIZE (1..ub-compon-name-length))

TELETEX-Common-name extension-attribute :: = {TeletexcommonName Identified by 2} TelexComMonname :: = TeletexString (Size (1..UB-case-name-length))

Teletex-Organization-Name Extension-Attribute :: = {TeleletExorganizationname Identified by 3}

Telexorganizationname :: = TeletexString (Size (1..ub-Organization-name-length))

Teletex-Personal-Name Extension-Attribute :: = {TeletexPersonalName Identified by 4}

Teletex-Organizational-Unit-Names Extension-Attribute :: = {TeletexorganizationAtNAmes Identified by 5}

TelexorganizationalUnitNames :: = sequence size (1..ub-Organizational-Units) of teletexorganizationalunitname

TelexorganizationalUnitName :: = TeletexString (Size (1..ub-Organizational-Unit-Name-length))

PDS-name extension-attribute :: = {pdsname ide17}

PDSNAME :: = Printablestring (size (1..ub-pds-name-length))

Physical-Delivery-Country-Name Extension-Attribute :: = {PhysicalDeliveryCountryName Identified by 8}

PhysicalDeliveryCountryName :: = CHOICE {x121-dcc-code NumericString (SIZE (ub-country-name-numeric-length)), iso-3166-alpha2-code PrintableString (SIZE (ub-country-name-alpha-length))} Postal-code extension-attribute :: = {Postalcode Identified by 9}

Postalcode :: = kice {numeric-code numericString (Size (1..ub-postal-code-length), printable-code printablestring (1..UB-postal-code-length)}

Physical-delivery-office-name extension-attribute :: = {PhysicalDeliveryOffIname Identified by 10}

PhysicalDeliveryOffIname :: = PDSPARETER

Physical-Delivery-Office-Number Extension-Attribute :: = {PhysicalDeliveryOffICenumber Identified by 11}

PhysicalDeliveryOffInumber :: = pdsparameter

EXTENSION-OR-Address-Components Extension-Attribute :: = {EXTENSIONORADDRESSCOMPONENTS Identified by 12}

ExtensionoraDresComponents :: = PDSPARAMETER

Physical-Delivery-Personal-Name Extension-Attribute :: = {PhysicalDeliveryPersonalName Identified by 13}

PhysicalDeliveryPersonalName :: = PDSPARAMETER

Physical-Delivery-Organization-Name Extension-Attribute :: = {PhysicalDeliveryOrganizationName Identified by 14}

PhysicalDeliveryorganizationName :: = pdsparameter

Extension-physical-delivery-address-Components Extension-Attribute :: = {ExtensionPhysicalDeliveryAddressComponents Identified by 15}

ExtensionPhysicalDeliveryAddressComponents :: = PDSPARAMETER

Unformatted-postal-address :: {unformattedpostaralddressIfied by 16}

StreetAddress :: = pdsparameter

Post-Office-Box-Address Extension-Attribute :: = {PostOfficeBoxAddress Identified by 18}

PostOfficeBoxAddress :: = pdsparameter

POSTE-RESTANTE-Address Extension-Attribute :: = {Posterestanteaddress Identified by 19}

Posterestanteaddress :: = PDSPARAMETER

Unique-postal-name extension-attribute :: = {UNIQUEPOSTALNAME IDENTIFIED by 20}

Uniquepostalname :: = PDSPARAMETER

Local-postal-attributes extension-attribute :: = {localpostalattributes ide1}

LocalPostalattributes :: = PDSPARAMETER

Pdsparameter :: = set {printable-string printablestring (Size (1..UB-PDS-Parameter-length) Optional, Teletex-String TeleXstring (Size (1..UB-PDS-Parameter-length) optional}

Extended-network-address extension-attribute :: = {ExtendedNetworkAddress Identified by 22}

ExtendedNetworkAddress :: = choic {e163-4-address sequence {number [0] numericString (size (1..UB-E163-4-Number-length), Sub-address [1] numericString (Size (1..UB -e163-4-sub-address-length)) OPTIONAL}, psap-address [0] PresentationAddress} PresentationAddress :: = SEQUENCE {pSelector [0] EXPLICIT OCTET STRING OPTIONAL, sSelector [1] EXPLICIT OCTET STRING OPTIONAL, tSelector [2 ] Explicit OcTet String Optional, Naddresses [3] Explicit Set size (1..max) of octet string}

Terminal-Type Extension-Attribute :: = {TerminalType Identified by 23}

TERMINALTYPE :: = Integer {Telex (3), Teletex (4), G3-Facsimile (5), G4-Facsimile (6), IA5-Terminal (7), VIDETEX (8)} (0..UB-INTEGER- Options

- Extension Domain-Defined Attributes

Teletex-domain-defined-attributes extension-attribute :: = {TelexDomainDefinedattributes Identified by 6}

TelexDomainDefinedAttributes :: = sequence size (1..ub-domain-defined-attributes) of teletexdomainDefinedattribute

TeletexDomainDefinedAttribute :: = SEQUENCE {type TeletexString (SIZE (1..ub-domain-defined-attribute-type-length)), value TeletexString (SIZE (1..ub-domain-defined-attribute-value-length))}

- Specifications of Upper Bounds - Shall Be Regarded As Mandatory - from Annex B of Itu-T X.411 - Reference Definition of MTS Parameter Upper Bounds

UB-X121-Address-length integer :: = 16

- Note - upper bounds on TeletexString are measured in characters .-- A significantly greater number of octets will be required to hold-- such a value As a minimum, 16 octets, or twice the specified upper-- bound, whichever is. The Larger, Should Be Allowed.end.end

B.2 hidden visual target module (IMPLICITLY TAGGED MODULE), 1993 syntax

Pkix1 Implicit93 {ISO (1) Identified-Organization (3) DOD (6) Internet (1) Security (5) MECHANISMS (5) PKIX (7) ID-mod (0) ID-PKIX1-Implicit-93 (4)}

Definitions Implicit Tags :: =

Begin

--Exports all -

IMPORTS id-pe, id-qt, id-kp, id-ad, id-qt-unotice, ORAddress, Name, RelativeDistinguishedName, CertificateSerialNumber, CertificateList, AlgorithmIdentifier, ub-name, DirectoryString, Attribute, EXTENSION FROM PKIX1Explicit93 {iso (1 Identified-Organization (3) DOD (6) Internet (1) Security (5) Mechanisms (5) PKIX (7) ID-mod (0) ID-PKIX1-Explicit-93 (3)};

- Key and Policy Information EXTENSITIONS -

AuthorityKeyidentifier Extension :: = {syntax authorseKeyidentifier Identified by ID-ce-authorityKeyIdentifier}

AuthorityKeyIdentifier :: = SEQUENCE {keyIdentifier [0] KeyIdentifier OPTIONAL, authorityCertIssuer [1] GeneralNames OPTIONAL, authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL} (WITH COMPONENTS {..., authorityCertIssuer PRESENT, authorityCertSerialNumber PRESENT} | WITH COMPONENTS {..., authorityCertIssuer Absent, authoritycertserialnumber absent} KeyIdentifier :: = o o

SubjectKeyIdentifier Extension :: = {syntax subjectKeyidentiDentifier Identified by ID-ce-subjectKeyIdentifier}

SubjectKeyIdentifier :: = Keyidentifier

Keyusage Extension :: = {Syntax Keyusage Identified by ID-CE-KEYUSAGE}

KeyUsage :: = BIT STRING {digitalSignature (0), nonRepudiation (1), keyEncipherment (2), dataEncipherment (3), keyAgreement (4), keyCertSign (5), cRLSign (6), encipherOnly (7), decipherOnly (8 }

ExtendedKeyusage Extension :: = {syntax sequence size (1..max) of keypurposeid Identified by ID-ce-extkeyusage}

Keypurposeid :: = Object Identifier

- PKIX-defined extended key purpose OIDsid-kp-serverAuth OBJECT IDENTIFIER :: = {id-kp 1} id-kp-clientAuth OBJECT IDENTIFIER :: = {id-kp 2} id-kp-codeSigning OBJECT IDENTIFIER :: = {ID-KP 3} ID-KP-EmailProtection Object Identifier :: = {ID-KP 4} ID-KP-IPSECENDSYSTEM Object Identifier :: = {ID-KP 5} ID-KP-IPSECTUNEL Object Identifier :: = {ID -kp 6} id-kp-ipsecUser OBJECT IDENTIFIER :: = {id-kp 7} id-kp-timeStamping OBJECT IDENTIFIER :: = {id-kp 8} privateKeyUsagePeriod EXTENSION :: = {SYNTAX PrivateKeyUsagePeriod IDENTIFIED BY {id-ce -priVateKeyusagePeriod}}

PrivateKeyusagePeriod :: = Sequence {NOTBEFORE [0] GeneralizedTime Optional, NOTER [1] generalizedtime optional} (with components {..., notbefore present}} | {..., notafter present})

CertificatePolicies Extension :: = {syntax certificatePoliciesysyntax Identified by ID-ce-certificatepolicies}

CertificatePoliciesysyntax :: = sequence size (1..max) of policyinformation

PolicyInformation :: = sequence {policyid, policyqualifiers sequence size (1..max) of policyqualifierinfo optional}

CertpolicyID :: = Object Identifier

PolicyQualifierInfo :: = SEQUENCE {policyQualifierId CERT-POLICY-QUALIFIER. & Id ({SupportedPolicyQualifiers}), qualifier CERT-POLICY-QUALIFIER. & Qualifier ({SupportedPolicyQualifiers} {@policyQualifierId}) OPTIONAL} SupportedPolicyQualifiers CERT-POLICY-QUALIFIER :: = {noticeToUser | PointerToCPS}

CERT-Policy-Qualifier :: = Class {& ID Object Identifier Unique, & Qualifier Optional} with Syntax {Policy-Qualifier-Id & ID [Qualifier-Type & Qualifier]}

PolicyMappings Extension :: = {syntax policymappingssyntax identified by ID-ce-policymappings}

Policymappingssyntax :: = sequence size (1..max) of sequence {issuerdomainPolicy CertpolicyId, SubjectDomainPolicy CertPolicyId}

- Certificate Subject and Certificate Issuer Attributes Extensions -

SubjectaltName Extension :: = {syntax generalnames identified by id-ce-subjectaltname}

Generalnames :: = sequence size (1..max) of generalname

GeneralName :: = CHOICE {otherName [0] INSTANCE OF OTHER-NAME, rfc822Name [1] IA5String, dNSName [2] IA5String, x400Address [3] ORAddress, directoryName [4] Name, ediPartyName [5] EDIPartyName, uniformResourceIdentifier [6] IA5String, Ipaddress [7] Oclet string, registeredid [8] Object Identifier} Other-name :: = Type-Identifier

Edipartyname :: = sequence {namessigner [0] DirectoryString {ub-name} Optional, Partyname [1] DirectoryString {UB-Name}}

Issueraltname extension :: = {syntax generalnames identified by id-ce-questionueraltname}

SubjectDirectoryAttributes extension :: = {syntax attributessyntax identified by ID-ce-subjectdiRectoryAttributes}

Attributessyntax :: = sequence size (1..max) of attribute

- Certification Path Constraints Extensions -

BasicConstraints Extension :: = {syntax Basicconstraintssyntax Identified by ID-ce-basicconstraints}

BasicConstraintssyntax :: = sequence {CA Boolean Default False, Pathlenconstraint Integer (0..max) Optional}

NameConstraints extension :: = {syntax nameconstrassyntax identified by ID-ce-nameconstraints}

NameConstraintssyntax :: = sequence {permittedsubtrees [0] generalsubtrees optional, Excludedsubtrees [1] generalsubtrees optional}

Generalsubtrees :: = sequence size (1..max) of generalsubtree

GENERALSBTREE :: = sequence {base generalname, minimum [0] Basedistance default 0, maximum [1] basedistance :: = integer (0..max)

PolicyConstraints Extension :: = {syntax policyconstraintssyntax Identified by ID-ce-policyconstraints}

PolicyConstRAINTSYNTAX :: = Sequence {RequireExplicitPolicy [0] Skipcerts Optional, InhibolicymApping [1] Skipcerts Optional}

Skipcerts :: = integer (0..max)

- Basic CRL EXTENSIONS -

CRLNUMBER EXTENSION :: = {syntax crlnumber identified by id-ce-crlnumber}

CRLNUMBER :: = INTEGER (0..max)

Reasoncode extension :: = {syntax crlreason IDentified by ID-ce-reasoncode}

CRLREASON :: = Enumerated {Unspecified (0), Keycompromise (1), Cacompromise (2), Affiliationchanged (3), Superseded (4), CassationOfoperation (5), CertificateHold (6), RemoveFromCRL (8)}

INSTRUCTIONCODE EXTENSION :: = {syntax holdinstruction Identified by ID-ce-instructioncode}

Holdinstruction :: = Object Identifier

- Holdinstruction Described in this specification, from Ans Ansi x9

- ANSI X9 ARC HOLDINSTRUCTION Archoldinstruction Object Identifier :: = {Joint-ISO-CCITT (2) Member-Body (2) US (840) X9CM (10040) 2}

- ANSI X9 holdinstructions referenced by this standardid-holdinstruction-none OBJECT IDENTIFIER :: = {holdInstruction 1} id-holdinstruction-callissuer OBJECT IDENTIFIER :: = {holdInstruction 2} id-holdinstruction-reject OBJECT IDENTIFIER :: = {holdInstruction 3} INVALIDITYDATE EXTENSITION :: = {syntax generalizedtime Identified by id-ce-invaliditydate}

- CRL Distribution Points and Delta-CRL EXTENSONS -

CRLDISTRIBUTIONPOINTS EXTENSION :: = {

Syntax CRLDistPointssyntax Identified by ID-CE-CRLDistributionPoints}

CRLDistPointssyntax :: = sequence size (1..max) of DistributionPoint

DistributionPoint :: = SEQUENCE {DistributionPoint [0] DistributionPointName Optional, Reasons [1] Reasonflags Optional, CRLISSUER [2] generalnames optional}

DistributionPointName :: = cho1 {fullname [0] generalnames, NameRelativeToCrlissuer [1] relativedistinguishedname}

Reasonflags :: = bit string {unused (0), Keycompromise (1), Cacompromise (2), AffiliationChanged (3), Superseded (4), CassationOfoperation (5), CertificateHold (6)}

IssuingDistributionPoint Extension :: = {syntax issuingdistpointsyntax Identified by ID-CE-ISSUINGDISTRIBUTIONPOINT}

IssuingDistPointSyntax :: = SEQUENCE {distributionPoint [0] DistributionPointName OPTIONAL, onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, onlySomeReasons [3] ReasonFlags OPTIONAL, indirectCRL [4] BOOLEAN DEFAULT FALSE} certificateIssuer EXTENSION :: = { Syntax generalnames identified by id-ce-certificateissuer}

Deltacrlindicator Extension :: = {syntax basecrlNumber Identified by ID-ce-deltacrlindicator}

BasecrlNumber :: = CRLNUMBER

- Object Identifier Assignments for ISO CERTIFICATE EXTENSITIONS --ID-CE Object Identifier :: = {Joint-ISO-CCITT (2) DS (5) 29}

ID-CE-SUBJECTDIRECTORTTRIBUTES Object Identifier :: = {ID-CE 9}

id-ce-subjectKeyIdentifier OBJECT IDENTIFIER :: = {id-ce 14} id-ce-keyUsage OBJECT IDENTIFIER :: = {id-ce 15} id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER :: = {id-ce 16} id- CE-SubjectaltName Object Identifier :: = {ID-CE 17} ID-CE-ISSUERALTNAME Object Identifier :: = {ID-CE 18} ID-CE-BasicConstraints Object Identifier :: = {ID-CE 19} ID-CE- cRLNumber OBJECT IDENTIFIER :: = {id-ce 20} id-ce-reasonCode OBJECT IDENTIFIER :: = {id-ce 21} id-ce-instructionCode OBJECT IDENTIFIER :: = {id-ce 23} id-ce-invalidityDate OBJECT IDENTIFIER :: = {id-ce 24} id-ce-deltaCRLIndicator OBJECT IDENTIFIER :: = {id-ce 27} id-ce-issuingDistributionPoint OBJECT IDENTIFIER :: = {id-ce 28} id-ce-certificateIssuer OBJECT IDENTIFIER: : = {ID-CE 29} ID-CE-NAMECONSTRAINTS Object Identifier :: = {ID-CE 30} ID-CE-CRLDISTRIBUTIONPOINTS OBJECT Identifier :: = {ID-C E 31} ID-ce-certificatePolicies Object Identifier :: = {ID-CE 32} ID-CE-PolicyMappings Object Identifier :: = {ID-CE 33} ID-CE-PolicyConstraints Object Identifier :: = {ID-CE 36 } ID-ce-authorityKeyidentifier Object Identifier :: = {ID-CE 35} ID-CE-EXTKEYUSAGE Object Identifier :: = {ID-CE 37} - Pkix 1 Extensions

AuthorityInfoAccess Extension :: = {syntax authorityInfoaccesssyntax Identified by ID-pe-authorityInfoaccess}

AuthorityInfoAccesssyNTax :: = Sequence Size (1..max) of accessDescription

AccessDescription :: = Sequence {AccessMethod Object Identifier, AccessLocation Generalname} ID-pe-authorityInfoaccess object identifier :: = {ID-PE 1}

ID-Ad-Ocsp Object Identifier :: = {ID-AD 1} ID-Ad-Caissuers Object Identifier :: = {ID 2}

- Pkix Policy Qualifier Definitions

Noticetouser Cert-Policy-Qualifier :: = {Policy-Qualifier-ID ID-QT-CPS Qualifier-Type cpsuri}

Pointertocps Cert-Policy-Qualifier :: = {Policy-Qualifier-ID ID-QT-UNOTICE Qualifier-Type UserNotice}

ID-QT-CPS Object Identifier :: = {ID-QT 1}

ID-QT-UNOTICE Object Identifier :: = {ID-Qt 2}

Cpsuri :: = ia5string

UserNotice :: = sequence {Noticref NoticReference Optional, ExplicitText Displaytext Optional}

NoticReference :: = sequence {Organization Displaytext, NoticenumBers Sequence of Integer}

Displaytext :: = kice {visibleString VisibleString (size (1..200)), bmpstring bmpstring (size (1..200)), uTF8String Utf8String (Size (1..200))}

End

Appendix C. ASN.1 Note

Structure "Sequence Size (1..max) Of" appears in several ASN.1 structures. An effective sequence (structure) will include zero or more entities. Structure SIZE (1..max) includes at least one entity sequence. MAX indicates that there is no specifier. Implementations freely choose the previous previous session suitable for them (application).

Structure "Positiveint :: = Integer (0..max)" Defines PositiveInt as an integer greater than or equal to 0 as an integer. No specifies in the last session. Implementations freely choose the previous previous session suitable for them (application).

String Type PrintableString supports a very basic Latin character set: lowercase letters 'A' to 'Z', uppercase letters 'a' to 'Z', number '0' to '9', eleven special characters '"() , -. /: String Type TeletexString is superchard of PrintableString .TeletexString supports a complete standard (ASCII-LIKE) Latin character set, non-spacing accents Latin ( Latin) Character Sets and Japanese Characters.

String Type Universalstring supports the characters allowed by any ISO 10646-1. ISO 10646 is a universal multiped coded character set (The Universal Multiple-Oct Coded Character Set (UCS)). ISO 10646-1 specifies structural format and basic multilingual platforms ("Basic Multilingual Plane" - a large standard character set includes all major world character standards.

String Type UTF8String Introduced at the 1998 version of ASN.1. UTF8String is a universal type and has been assigned a 12 digital label (Tag Number 12). UTF8String content is updated by RFC 2044 and RFC 2279 "UTF-8, A Transformation Format of ISP 10646.". At the same time ISO is the expected standard to join UTF8String to 1998 DirectoryString selection list.

Prepare these changes, and the IETF Best Practices is consistent with the RFC 2277 encoding, in the character set and the IETF Policy, this document includes UTF8String as a selection of DirectoryString and CPS-definition.

Appendix D. Example

This part consists of four examples: three certificates and a CRL (example). The first two certificates and CRLs contain the smallest certificate path.

Part D.1 contains a "self-signed" certificate hexadecimal (heap) interpretation by the unique name is CA, O = US, O = GOV, OU = NIST. The certificate contains the DSA public key and (related) parameters, as well as the relative DSA private signature.

Part D.2 includes a hex (heap) description of a terminal certificate. The terminal certificate contains a DSA public key, and a signature corresponding to the private key in the "Self-Sign" certificate in section D.1.

Part D.3 includes a terminal certificate hexadecimal (heap) explanation, which includes a RSA public key and a signature of the RSA and MD5 algorithm. This certificate is not part of the minimum certificate path.

Part D.4 includes an explanation of a CRL hex (heap). This CRL is issued by the only name of CN = US, O = GOV, OU = NIST. The certificate revocation list includes the terminal certificate described in Section D.2.

D.1 certificate

This part includes a version of 3 certificates with a total of 699 bytes of hexadecimal (heap) explanation. Certificate contains the following information: (a) The Serial Number IS 17 (11 HEX); (b) The Certificate IS Signed with DSA and The Sha-1 Hash Algorithm; (c) The Issuer's distinguished name is ou = Nist; o = GOV ; C = US (d) and the subject's distinguished name is ou = Nist; o = gov; c = US (e) The Certificate Was Issue 3, 1997 and Will Expire on December 31, 1997; (f) The certificate contains a 1024 bit DSA public key with parameters; (g) the certificate contains a subject key identifier extension; and (h) the certificate is a CA certificate (as indicated through the basic constraints extension.) 0000 30 82 02 b7 695: SEQUENCE0004 30 82 02 77 631:. Sequence Tbscertificate0008 A0 03 3:.....................................................................................

0016 30 09 06 07 7:............................................................................ ............................................................................................................................... SEQUENCE0046 06 03 3:................................................... :........................................................................................................................................... ... 740071 30 1E 30:.. Sequence0073 17 0D 13:... Utctime '970630000000z': 39 3 7 30 30 30 30 30 30 30 30 5A0088 17 0D 13:................................................................................................................................. SEQUENCE0109 06 03 3:............................................................................................................................................................ SEQUENCE0122 06 03 3:.......................................

: 67 6F 760132 31 0D 13:...................................................................................................................................................................................................................................................... 'Nist': 6E 69 73 740147 30 82 01 B436:.

0155 06 07 7:................................ 02 C5 35 7B D5 0B A1 7E 5D 72 59 63 55 D3: 45 56 E2 25 1A 6B C5 A4 AA 0B D4 62 B4 D2: 21 B1 95 A2 C6 01 C9 C3 FA 01 6F 79 86 83 3D 03: 61 E1 F1 92 AC BC 03 4E 89 A6 C9 53 4A F7 E2 A6: 48 CF 42 1E 21 B1 5C 2B 3A 7F Ba BE 6B 5A F7 0A: 26 D8 8E 1B EB EC BD 31 23 BE: 69 71 A7 C2 90 FE A5 D6 80 B5 24 DC 44 9C EB 4D: F9 DA F0 C8 E8 A2 4C 99 07 5C 8E 35 2B 7D 57 8D0299 02 14 20:............................................. 20 07 FC 4C E7 E8 9F F3 39 83: 51 0D DC DD0321 02 81 80 128:..... In Integer: 0E 3B 46 31 8A 0A 58 86 40 84 E3 A1 22 0D 88 CA : 90 88 57 64 9F 01 21 E0 15 05 94 24 82 E2 10 90: D9 E1 4E 10 5C E7 54 6B D4 0C 2B 1B 59 0A A0 B5: A1 7D B5 07 E3 65 7C EA 90 D8 8E 30 42 E4 85 BB: AC FA 4E 76 4B 78 0e DF 6C E5 A6 E1 BD 59 77 7D: A6 97 59 C5 29 A7 B3 3F 95 3E 9D F1 59 2D F7 42: 87 62 3F F1 B8 6F C7 3D 4B B8 8D 74 C4 CA 44 90: CF 67 DB DE 14 60 97 4A D1 F7 6D 9E 09 94 C4 0D0452 03 81 84 132:.. Bit String (0 unused bits)

: 02 81 80 AA 98 EA 13 94 A2 DB F1 5B 7F 98 2F 78: E7 D8 E3 B9 71 86 F6 80 2F 40 39 C3 DA 3B 4B 13: 46 26 EE 0D 56 C5 A3 3A 39 B7 7D 33 C2 6B 5C 77: 92 F2 55 65 90 39 CD 1A 3C 86 E1 32 EB 25 BC 91: C4 FF 80 4F 36 61 BD CC E2 61 04 E0 7e 60 13 CA: C0 9C DD E0 E0 EA 41 DE 33 C1 F1 44 A9 BC 71 DE CF: 59 D4 6E DA 44 99 3C 21 64 E4 78 54 9D D0 7B BA: 4E F5 18 4D 5E 39 30 BF E0 D1 F6 F4 83 25 4F 14: AA 71 E10587 A3 32 50:. [3] 0589 30 30 48:..... Sequence0593 06 03 3:......................................... 5:.................................................................................................................................................................................................................... EctKeyIdentifier: 55 1D 0E0615 04 16 22:.......................................................................... 1.2.840.10040.4.3: DSA-WITH-SHA: 2A 86 48 CE 38 04 030650 03 2F 47:. Bit String (0 unused bits): 30 2C 02 14 A0 66 C1 76 33 99 13 51 8D 93 64 2F: CA 13 73 DE 79 1A 7D 33 02 14 5D 90 F6 CE 92 4A: BF 29 11 24 80 28 A6 5A 8E 73 B6 76 02 68

D.2 certificate

This part includes a version 3 certificate with a total of 730 bytes of hexadecimal (heap) explanation. Certificate contains the following information: (a) The Serial Number IS 18 (12 HEX); (b) The Certificate IS Signed with DSA and The SHA-1 Hash Algorithm; (C) The Issuer's Distinguished Name is ou = Nist; o = GOV ; C = US (d) and the Subject's distinguished name is cn = TIM polk; = number; o = gov; c = US (e) The certificate Was Valid from July 30, 1997 THROUGH DECEMBER 1, 1997; (F) the certificate contains a 1024 bit DSA public key; (g) the certificate is an end entity certificate, as the basic constraints extension is not present; (h) the certificate contains an authority key identifier extension; and (i) the certificate includes one Alternative Name - AN RFC 822 Address.0000 30 82 02 D6 726: SEQUENCE0004 30 82 02 96 662:. SEQUENCE0008 A0 03 3:......................................... Integer 18: 120016 30 09 9:.. Sequence0018 06 07 7:... OID 1.2.840.10040.4.3: DSA-with-SHA: 2 A 86 48 CE 38 04 030027 30 2A 42:......................................................................................................................... 13 02 2:...............................................................................................................................................................................

: 55 04 0A0051 13 03 3:....................................................................................................................................................... 4.11: OU: 55 04 0B0065 13 04 4:.................................................. 30 30 30 30 30 30 30 30 30 30 30 5A0103 30 3D 61:. SEQUENCE0105 31 0B 11:....... SET0107 30 09 9 :.............................................................................................................. 0A 10:........................................................................................................... : 55 04 0A0127 13 03 3:................................................................................................................................................................... 4.11: Ou: 55 04 0B0141 13 04 4:................................... OID 2.5.4.3: CN: 55 04 030156 13 08 8:.... PrintAblestring 'TIM Polk'

: 54 69 6D 20 50 6F 6C 6B0166 30 82 01 29 297 06 07 7:..... OID 1.2.840.10040.4.1: DSA: 2A 86 48 CE 38 04 010183 30 82 01 1C 284:............................................ A4 AA 0B D4 62 B4 D2: 21 B1 95 A2 C6 01 C9 C3 FA 01 6F 79 86 83 3D 03: 61 E1 F1 92 AC BC 03 4e 89 A3 C9 53 4A F7 E2 A6: 48 CF 42 1e 21 B1 5C 2B 3A 7F Ba BE 6B 5A F7 0A: 26 D8 8E 1B EB EC BD 31 23 BE: 69 71 A7 C2 90 Fe A5 D6 80 B5 24 DC 44 9C EB 4D: F9 DA F0 C8 E8 A2 4C 99 07 5C 8E 35 2B 7D 57 8D0318 02 14 20:........................................... Integer : 0e 3B 46 31 8A 0A 58 86 40 84 E3 A1 22 0D 88 CA: 90 88 57 64 9F 01 21 E0 15 05 94 24 82 E2 10 90: D9 E1 4E 10 5C E7 54 6B D4 0C 2B 1B 59 0A A0 B5: A1 7D B5 07 E3 65 7C EA 90 D8 8E 30 42 E4 85 BB: AC FA 4E 76 4B 78 0E DF 6C E5 A6 E1 BD 59 77 7D: A6 97 59 C5 29 A7 B3 3F 95 3E 9D F1 59 2D F7 42: 87 62 3F F1 B8D C7 3D 4B B8 8D 74 C4 CA 44 90: CF 67 DB DE 14 60 97 4A D1 F7 6D 9E 09 94 C4 0D0471 03 81 84 132:... Bit String (0 unused bits )

: 02 81 80 A8 63 B1 60 70 94 7E 0B 86 08 93 0C 0D: 08 12 4A 58 A9 AF 9A 09 38 54 3B 46 82 FB 85 0D: 18 8B 2A 77 F7 58 E8 F0 1D D2 18 DF Fe E7 E9 35: C8 A6 1A DB 8D 3D 3D F8 73 14 A9 0B 39 C7 95 F6: 52 7D 2D 13 8C AE 03 29 3C 4E 8C B0 26 18 B6 D8: 11 1F D4 12 0C 13 CE 3F F1 C7 05 4E DF E1 FC 44: FD 25 34 19 4A 81 0D DD 98 42 AC D3 B6 91 0C 7F: 16 72 A3 A0 8A D7 01 7F FB 9c 93 E8 99 92 C8 42: 47 C6 430606 A3 3e 62:.. [3] 0608 30 3C 60:................................................... 81 0E 77 70 6F 6C 6B 40 6E 69 73 74 2E 67: 6F 760637 30 1F 31:............................... UbjectaltName: 55 1D 230644 04 18 24: 30 16 80 14 E7 26 C5 54 CD 5B A3 6F 35 68 95 AA: D5 FF 1C 21 E4 22 75 D60670 30 09 9:. SEQUENCE0672 06 07 7:.......................... .. 15 71 58: 92 29 48 C4 1C 54 DF FC 02 14 5B DA 53 98 7F C5: 33 DF C6 09 B2 7A E3 6F 97 70 1E 14 ED 94D.3 RSA Algorithm Terminal Certificate

This part includes a version of 3 certificates with a total of 675 bytes of hexadecimal (heap) explanation. Certificates contain the following information: (a) the serial number is 256; (b) the certificate is signed with RSA and the MD2 hash algorithm; (c) the issuer's distinguished name is OU = Dept Arquitectura de Computadors; O = Universitat Politecnica de. Catalunya; C = ES (d) and the subject's distinguished name is CN = Francisco Jordan;. OU = Dept Arquitectura de Computadors; O = Universitat Politecnica de Catalunya; C = ES (e) the certificate was issued on May 21, 1996 and expired on May 21, 1997; (f) the certificate contains a 768 bit RSA public key; (g) the certificate is an end entity certificate (not a CA certificate); (h) the certificate includes an alternative subject name and an alternative issuer name - bothe are URLs; (i) the certificate include an authority key identifier and certificate policies extensions; and (j) the certificate includes a critical key usage extension specifying the public is intended for generation of digital signatures.

0000 30 80: SEQUENCE (SIZE undefined) 0002 30 82 02 40 576:. SEQUENCE0006 A0 03 3:. [0] 0008 02 01 1:... Integer 2: 020011 02 02 2:.. Integer 256: 01 000015 30 0d 13:............................................................................... 0b 11:................................................. 530045 31 2D 45:........ SEQUENCE0049 06 03 3:..... OID 2.5.4.10: O: 55 04 0A0054 13 24 36:.... PrintAbleString

'Universitat Politecnica de Catalunya': 55 6e 69 76 65 72 73 69 74 61 74 20 50 6f 6c 69: 74 65 63 6e 69 63 61 20 64 65 20 43 61 74 61 6c: 75 6e 79 610092 31 2a 42:. SEQUENCE0096 06 03 3:................................................................... Situching:................................................................................................................................................................................................. UTCTime '960521095826Z': 39 36 30 37 32 32 31 37 33 38 30 32 5a0153 17 0d 13:... UTCTime '979521095826Z': 39 37 30 37 32 32 31 37 33 38 30 32 5a0168 30 81 83 112:.. SEQUENCE0171 31 0B 11:................ ENCE0175 06 03 3:......................................................................................................................................................... SEQUENCE0188 06 03 3:.............................................................................................

: 55 6E 69 76 65 72 73 69 74 6C 69: 74 61 20 63 69 20 43 61 74 61 6C: 75 6E 79 610231 31 2A 42:..... Set0233 30 28 40 :................................................................................................................................................... 64 6D 7072:..................................................... OID 2.5.4.3:. JOURNAL OF ANALYTICAL CHEMISTRY. JOURNAL OF ANALYTICAL CHEMISTRY. SEQUENCE0304 30 0D 13:... Sequence0306 06 09 9:.... OID 1.2.840.113549.1.1: rsaencryption : 2A 86 48 86 F7 0D 01 01 010317 05 00 0:... Null0319 03 6b 107:... Bit String: 00 (0 unused bits)

: 30 68 02 61 00 Be aa 8b 77 54 A3 AA 8B 77 9F 2F: B0 CF 43 88 FF A6 6D 79 55 5B 61 8C 68 EC 48 1E: 8A 86 38 A4 Fe 19 B8 62 17 1D 9D 0F 47 2C FF 63: 8F 29 91 04 D1 52 BC 7F 67 B6 B2 8F 74 55 C1 33: 21 6C 8F AB 01 95 24 C8 B2 73 93 9D 22 61 50 A9: 35 FB 9D 57 50 32 EF 56 52 50 93 AB B1 88 94 78: 56 15 C6 1C 8B 02 03 01 00 010428 A3 81 97 151:. [3] 0431 30 3C 60:.................... OID 2.5.29.35: AuthorityKeyidentifier: 55 1D 230440 04 14 22:..... OcTet String: 30 12 80 10 0E 6B 3A BF 04 EA 04 C3 0E 6B 3A BF: 04 EA 04 C30464 30 19 25:. 0466 06 03 3:..................... O......................................................... .. 06 06 04 80 07 06 08 06 05 2A 84 80 00 02 02 01: 0A0522 30 1C 28:...... OID 2.5.29.17: SubjectAltName: 55 1D 110529 04 15 21:..... OcTet String: 30 13 86 11 68 74 74 70 3A 2F 2F 61 63 2E 75 70: 63 2E 65 73 2F0552 30 19 25:

SEQUENCE0554 06 03 3:.................................................................................................................... 2E 75: 70 63 2E 650579 30 80:... Null0585 00 00 0:. End of Contents Marker0587 03 81 81 47:. Bit String: 00 (0 unused bits): 5C 01 BD B5 41 88 87 7A 0E D3 0E 6B 3A BF 04 EA: 04 CB 5F 61 72 3C A3 BD 78 F5 66 17 Fe 37 3A AB: EB 67 BF B7 DA A8 38 F6 33 15 71 75 2F B9 8C 91: A0 E4 87 BA 4B 43 A0 22 8F D3 A9 86 43 89 E6 50: 5C 01 BD B5 41 88 87 7A 0E D3 0E 6B 3A BF 04 EA: 04 CB 5F 61 72 3C A3 BD 78 F5 66 17 Fe 37 3A AB: EB 67 BF B7 Da A8 38 F6 33 15 71 75 2F B9 8C 91 : A0 E4 87 BA 4B 43 A0 22 8F D3 A9 86 43 89 E6 500637 00 00 0:. End of Contents Marker

D.4 certificate revocation list

This part includes a version 2 CRL once extended hex (heap) explanation. CRL is issued by OU = Nist; o = gov; c = US is issued in July 7, 1996; the next scheduled release time is August 7, 1996. CRL contains a revocation certificate: Serial number 18 (12 hex). CRL itself number 18 , Use the DSA and SHA-1 algorithm signature.

0000 30 81 BA 186: SEQUENCE0003 30 7C 124:................................................ .. 2A 86 48 30 2A 42:...................................................................................................... 13 02 2:................................................................................. 04 0A0043 13 03 3:............................................................................................. OU: 55 04 0B

0057 13 04 4:.................................................................. "970808000000z ': 39 37 30 38 38 30 30 30 202....................... . 3....:.......................... 3 3 3...... 3 30 3. 3. 3. 3 2.5.29.21: ReasonCode: 55 1D 150124 04 03 3:..................................................... 2A 86 48 CE 38 04 030140 03 2F 47:. Bit String (0 unuse D bits): 30 2C 02 14 9E D8 6B C1 7D C2 C4 02 F5 17 84 F9: 9F 46 7A CA CF B7 05 8A 02 14 9E 43 39 85 DC EA: 14 13 72 93 54 5D 44 44 E5 05 Fe 73 9A B2 Appendix E. Authors' Addresses

Russell Housley Spyrus 381 Elden Street Suite 1120 Herndon, VA 20170 USA

Email: housley@spyrus.com

Warwick Ford VeriSign, Inc. One Alewife Center Cambridge, MA 02140 USA

Email: wford@veriign.com

Tim Polk Nist Building 820, Room 426 Gaithersburg, MD 20899 USA

Email: wpolk@nist.gov

David Solo Citicorp 666 Fifth Ave, 3rd Floor New York, NY 10103 USA

Email: david.solo@citicorp.com

Appendix F. Complete copyright statement

Copyright (C) Internet Association (1999). all rights reserved. This document and its translation can be copied and assigned to others, as well as derived work such as comments or other interpretations or their application, etc., can be prepared, copied, published, and published, the overall or part is not restricted, provided The above copyright notices and this paragraph should be included in all such copies and derived work. However, this document itself cannot be modified in any way, such as a reference to the copyright notification or the Internet Association or other Internet organization, unless to develop the Internet Standard (the copyright program is defined in the Internet Standards process, or if you need to translate Other languages other than.

The above restriction allows authorization to be persistent and will not be hidden or transferred by the Internet Association or its heirs.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY Rights or Any Implied Warranties of Merchantability Or Fitness for a particular purpose.

Appendix F. Full Copyright Statement

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind , provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations , except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT iNFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

RFC2459 - Internet X.509 PUBLIC Key InfrastructureCertificate and CRL Profile Internet X.509 Public Key Infrastructure - Certificate and CRL Introduction RFC Document Chinese Translation Plan 1

转载请注明原文地址:https://www.9cbs.com/read-35792.html

9cbs

New Post(0)