HOME   Cart(6)   Quotation   About-Us Policy PDFs Standard-List
www.ChineseStandard.net Database: 189759 (19 Oct 2025)

GB/T 20518-2018 English PDF

US$1159.00 · In stock
Delivery: <= 6 days. True-PDF full-copy in English will be manually translated and delivered via email.
GB/T 20518-2018: Information security technology -- Public key infrastructure -- Digital certificate format
Status: Valid

GB/T 20518: Evolution and historical versions

Standard IDContents [version]USDSTEP2[PDF] delivered inStandard Title (Description)StatusPDF
GB/T 20518-2018English1159 Add to Cart 6 days [Need to translate] Information security technology -- Public key infrastructure -- Digital certificate format Valid GB/T 20518-2018
GB/T 20518-2006EnglishRFQ ASK 3 days [Need to translate] Information security techniques -- Public key infrastructure -- Digital certificate format Obsolete GB/T 20518-2006

PDF similar to GB/T 20518-2018


Standard similar to GB/T 20518-2018

GB/T 20281   GB/T 20279   GB/T 20280   GB/T 19713   GB/T 20520   

Basic data

Standard ID GB/T 20518-2018 (GB/T20518-2018)
Description (Translated English) Information security technology -- Public key infrastructure -- Digital certificate format
Sector / Industry National Standard (Recommended)
Classification of Chinese Standard L80
Classification of International Standard 35.040
Word Count Estimation 58,550
Date of Issue 2018-06-07
Date of Implementation 2019-01-01
Issuing agency(ies) State Administration for Market Regulation, China National Standardization Administration

GB/T 20518-2018: Information security technology -- Public key infrastructure -- Digital certificate format


---This is a DRAFT version for illustration, not a final translation. Full copy of true-PDF in English version (including equations, symbols, images, flow-chart, tables, and figures etc.) will be manually/carefully translated upon your order.
Information security technology--Public key infrastructure--Digital certificate format ICS 35.040 L80 National Standards of People's Republic of China Replace GB/T 20518-2006 Information Security Technology Public Key Infrastructure Digital certificate format Published on.2018-06-07 2019-01-01 implementation State market supervision and administration China National Standardization Administration issued

Content

Foreword III 1 Scope 1 2 Normative references 1 3 Terms and Definitions 1 4 Abbreviations 2 5 Digital Certificate and CRL 2 5.1 Overview 2 5.2 Digital Certificate Format 2 5.3 CRL format 20 6 support for algorithm technology 24 Appendix A (Normative) Structure of the certificate 25 Appendix B (Normative Appendix) Structure Example of Certificate 27 Appendix C (Normative Appendix) Certificate Revocation List Contents Table 29 Appendix D (informative) Digital certificate coding example 48 Appendix E (informative) Algorithm Technical Support 52 Reference 53

Foreword

This standard was drafted in accordance with the rules given in GB/T 1.1-2009. This standard replaces GB/T 20518-2006 "Information Security Technology Public Key Infrastructure Digital Certificate Format", and The main technical changes compared with GB/T 20518-2006 are as follows. --- Added support for SM2 and SM3 cryptographic algorithms in Appendix E algorithm technical support; deleted MD5, SHA-1 algorithm

Introduction

--- Added the basic structure of the 5.3 certificate revocation list and the contents of the extensions in the digital certificate format; --- Revised the value of some OIDs in 5.2.4. Please note that some of the contents of this document may involve patents. The issuing organization of this document is not responsible for identifying these patents. This standard is proposed and managed by the National Information Security Standardization Technical Committee (SAC/TC260). This standard was drafted. Shanghai Geer Software Co., Ltd., Changchun Jida Zhengyuan Information Technology Co., Ltd., Shanghai Digital Certificate Certification Center Co., Ltd., China Financial Certification Center, Beijing Haitai Fangyuan Technology Co., Ltd., Beijing Digital Certification Co., Ltd. Wuxi Jiangnan Information Security Engineering Technology Center, Chengdu Weishitong Information Industry Co., Ltd., Xingtang Communication Technology Co., Ltd., Shandong An Information Technology Co., Ltd., National Information Security Engineering Technology Research Center. The main drafters of this standard. Liu Ping, Zheng Qiang, Yang Wenshan, Zhao Lili, Han Wei, Zhao Gaixia, Fu Dapeng, Jiang Hongyu, Luo Jun, Xu Mingyi, Wang Nina, Kong Fanyu, Yuan Feng. The previous versions of the standards replaced by this standard are. ---GB/T 20518-2006. Information Security Technology Public Key Infrastructure Digital certificate format

1 Scope

This standard specifies the basic structure of digital certificates and certificate revocation lists, and the contents of each data item. This standard applies to the development of digital certificate authentication systems, the operation of digital certificate certification institutions and security applications based on digital certificates.

2 Normative references

The following documents are indispensable for the application of this document. For dated references, only dated versions apply to this article. For the undated references, the latest edition (including all amendments) applies to this document. GB/T 16262.1-2006 Information Technology Abstract Syntax Notation 1 (ASN.1) Part 1. Basic notation specification GB/T 16264.8-2005 Information technology open systems interconnection directory - Part 8. Public key and attribute certificate framework GB/T 17969.1-2015 Information technology - Open systems interconnection OSI registration procedures - Part 1 . General procedures GB/T 35275 SM2 cryptographic algorithm cryptographic signature message syntax specification GB/T 35276 SM2 cryptographic algorithm usage specification PKCS Certificate authority; certificationauthority; CA The authority responsible for creating and assigning certificates, trusted by users. The certificate authority can also create a key for the user. 3.6 Certificate revocation list distribution point CRLdistributionpoint A CRL directory entry or other CRL distribution source, the CRL distributed through the CRL distribution point may contain only one CA The revocation of a subset of the issued certificate set may also include revocations with multiple CAs. 3.7 Digital certificate digitalcertificate A digitally signed third-party certificate authority (CA) that is authoritative, credible, and impartial. The digitized file of the letter.

4 Abbreviations

The following abbreviations apply to this document. CA Certificate Authority (CertificationAuthority) CRL certificate revocation list (CertificateRevocationList) DIT Directory Information Tree System (DirectoryInformationTree) OID object identifier (ObjectID) PKI Public Key Infrastructure (Publickeyinfrastructure)

5 Digital certificates and CRLs

5.1 Overview Digital certificates have the following characteristics. --- Any user who can obtain and use the certificate authority's public key can restore the public key authenticated by the certification body; --- Except for the certification body, no other organization can change the certificate, the certificate is unforgeable. Since certificates are unforgeable, they can be published by placing them in a directory without having to specifically protect them later. The certificate authority generates a user certificate by signing the information set, and the information set includes a distinguishable user name, a public key, and a The unique identifier that contains the user's additional information. The exact format of the unique identifier content is not specified here, but is left to the authentication machine. Construct a definition. The unique identifier can be, for example, an object identifier, a certificate, a date, or a certificate indicating the validity of the distinguished username. Other forms of the book. Specifically, if the distinguished name of a user certificate is A, the unique identifier is UA, and the certificate is A user certificate, named CA, whose unique identifier is UCA, is generated in the following form. CA< \u003cA\u003e>=CA{V, SN, AI, CA, UCA, A, UA, Ap, TA}\u003c/a\u003e Here V is the certificate version; SN is the certificate serial number; AI is the algorithm identifier used to sign the certificate; UCA is the optional only CA Uniform identifier; UA is the optional unique identifier of User A; Ap is the public key of User A; TA indicates the validity period of the certificate, consisting of two The date is composed of the time period between the two is the validity period of the certificate. The certificate validity period is a time interval in which time, The CA shall ensure that the status information of the certificate is maintained, that is, the information about the revocation is released. Since the TA is assumed to be no less than 24h Changes in the cycle require the system to be based on Greenwich Mean Time. The signature on the certificate can be used by any user who knows the CA public key CAp Used to verify the validity of the certificate. The CRL is a list file issued by the CA for the revoked certificate, which can be used for the application system to authenticate the user certificate. Sex. The CRL follows the certificate revocation list format of the X.509V2 standard. 5.2 Digital Certificate Format 5.2.1 Overview This standard uses GB/T 16262.1-2006 specific coding rules (DER) to encode the information in the following certificate items. Form a specific certificate data structure. The ASN.1DER code is an encoding system for the tag, length and value of each element. 5.2.2 Data Structure of the Basic Certificate Domain The basic data structure of a digital certificate is as follows. Certificate ..= SEQUENCE { tbsCertificate TBSCertificate, signatureAlgorithm AlgorithmIdentifier, signatureValue BITSTRING } TBSCertificate ..= SEQUENCE { Version [0] EXPLICITVersionDEFAUTv1, serialNumber CertificateSerialNumber, Signature AlgorithmIdentifier, Issuer Name, Validity Validity, Subject Name, subjectPublicKeyInfoSubjectPublicKeyInfo, issuerUniqueID [1]IMPLICITUniqueIdentifierOPTIONAL, -- If it does, version must be v2 or v3 subjectUniqueID[2]IMPLICITUniqueIdentifierOPTIONAL, -- If it does, version must be v2 or v3 Extensions [3]EXPLICITExtensionsOPTIONAL extension -- If it does, version must be v3 Version ..= INTEGER { v1(0),v2(1),v3(2) } CertificateSerialNumber ..= INTEGER Validity..=SEQUENCE{ notBefore Time, notAfter Time} Time..=CHOICE{ utcTime UTCTime, generalTime GeneralizedTime} UniqueIdentifier ..= BITSTRING SubjectPublicKeyInfo ..= SEQUENCE { Algorithm AlgorithmIdentifier, subjectPublicKey BITSTRING } Extensions ..= SEQUENCESIZE(1.MAX)OFExtension Extension ..= SEQUENCE { extnID OBJECTIDENTIFIER, Critical BOOLEANDEFAULTFALSE, extnValue OCTETSTRING } The above certificate data structure is composed of three domains. tbsCertificate, signatureAlgorithm and signatureValue. These ones The meaning of the domain is as follows. The tbsCertificate field contains the principal name and issuer name, the principal's public key, the validity period of the certificate, and other related information. The signatureAlgorithm field contains the identifier of the cryptographic algorithm used by the certificate issuing authority to issue the certificate. An algorithm identifier The ASN.1 structure is as follows. AlgorithmIdentifier ..= SEQUENCE { Algorithm OBJECTIDENTIFIER, Parameters ANYDEFINEDBYalgorithmOPTIONAL} The algorithm identifier is used to identify a cryptographic algorithm in which the OBJECTIDENTIFIER portion identifies the specific algorithm. among them The content of the optional parameters is completely dependent on the identified algorithm. The algorithm identifier of the domain should be the signature identifier in tbsCertificate The signature algorithm items are the same. If the signature algorithm is SM2, there is no parameter. The signatureValue field contains the result of digitally signing the tbsCertificate field. Tbs-coded with ASN.1DER Certificate is entered as a digital signature, and the result of the signature is encoded into a BITSTRING type according to ASN.1 and saved in the certificate. Within the signature value field. If the signature algorithm is SM2, the SM2 cryptographic algorithm signature data format is shown in GB/T 35276. 5.2.3 TBSCertificate data structure 5.2.3.1 Version Version This item describes the version number of the encoded certificate. 5.2.3.2 Serial number Serialnumber The serial number is a positive integer assigned by the CA to each certificate, and the serial number of each certificate issued by a CA should be unique (this Similarly, a certificate can be uniquely identified by the issuer's name and serial number. The CA should ensure that the serial number is a non-negative integer. serial number It can be a long integer and the certificate user should be able to process serial number values up to 20 8-bit bytes. CA should ensure that no more than 20 8 are used The serial number of the bit byte. 5.2.3.3 Signature Algorithm Signature This entry contains the identifier of the cryptographic algorithm used by the CA to issue the certificate. This algorithm identifier should be associated with the signature in the certificate. The algorithm identifiers for the rithm entries are the same. The content of the optional parameters is completely dependent on the specific algorithm identified, and can support user-defined signatures. algorithm. 5.2.3.4 Issuer Issuer This item identifies the entity for certificate signing and certificate issuance. It should contain a non-empty screening name (DN-distinguished Name). This item is defined as the Name type, and its ASN.1 structure is as follows. Name..=CHOICE{RDNSequence} RDNSequence..=SEQUENCEOFRelativeDistinguishedName RelativeDistinguishedName..=SETOFAttributeTypeAndValue AttributeTypeAndValue..=SEQUENCE{ Type AttributeType, Value AttributeValue} AttributeType..= OBJECTIDENTIFIER AttributeValue..= ANYDEFINEDBYAttributeType 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 describes the name of the hierarchy consisting of some attributes, such as the country name and the corresponding value, such as "country=CN". Where At- The type of the tributeValue part is determined by the AttributeType, which is usually a DirectoryString type. DirectoryString types are defined as PrintableString, TeletexString, BMPString, UTF8String, and Uni- One of the versalString types. UTF8String encoding is the preferred encoding. 5.2.3.5 Validity Validity 5.2.3.5.1 Overview The certificate validity period is a period of time during which the CA guarantees that it will maintain information about the status of the certificate. The item is represented As a SEQUEENCE type data with two time values. the start time of the certificate validity period (notBefore) and the validity period of the certificate End time (notAfter). Both NotBefore and notAfter can be used as UTCTime type or General- The izedTime type is encoded. 5.2.3.5.2 Encoding type requirements CAs that comply with this standard should encode this time as UTCTime type before 2049 (including 2049), in 2050 After that, the encoding is of the GeneralizedTime type. 5.2.3.5.3 World Time UTCTime This item is a standard ASN.1 type for international applications where only local time is not enough. UTCTime passed The two low digits determine the year and the time is accurate to one minute or one second. UTCTime contains Z (for Zulu, or Greenwich Mean Time) Or time difference. In this standard, the UTCTime value is expressed in Greenwich Mean Time (Zulu) and should contain seconds even if the value of the second is zero. (ie the time format is YYMMDDHHMMSSZ). The system pair year field (YY) should be interpreted as follows. When YY is greater than or equal to 50, the year should be interpreted as 19YY; when YY is less than 50, the year should be interpreted as 20YY. 5.2.3.5.4 Universal time type GeneralizedTime This item is a standard ASN.1 type that represents the variable accuracy of time. The GeneralizedTime field can contain a local and The time difference between Greenwich Mean Time. In this standard, the GeneralizedTime value shall be expressed in Greenwich Mean Time and shall contain seconds even if the value of the second is zero (ie The time format is YYYYMMDDHHMMSSZ). The GeneralizedTime value must never contain fractional seconds. 5.2.3.6 Subject Subject The subject item describes the entity that corresponds to the public key in the subject's public key entry. The subject name can appear in the subject item and/or subject optional Replace the name extension item (subjectAltName). If the principal is a CA, then the principal should be a non-empty and issuer The content matches the distinguished name (distinguishedname). If the subject's naming information only appears in the subject alternative replacement name expansion In the exhibit item (for example, the key is only bound to an email address or URL), then the subject name should be an empty sequence, and the subject can be replaced. The name extension should be identified as critical. When the subject item is not empty, this item shall contain an X.500 Distinguished Name (DN), a CA-certified entity for each subject entity. The name should be unique. A CA can issue multiple certificates for the same principal entity with the same distinguished name. The subject name extension is defined as the name type of GB/T 16264.8-2005. 5.2.3.7 Subject Public Key Information SubjectPublicKeyInfo This item is used to identify the public key and the corresponding public key algorithm. The public key algorithm uses the algorithm identifier AlgorithmIdentifier structure to Said. When the public key algorithm is SM2, the AlgorithmIdentifier structure is defined in GB/T 35275; when the public key algorithm is RSA, Al- GorithmIdentifier structure definition see PKCS 5.2.3.8 Issuer unique identifier issuerUniqueID This item is mainly used to deal with the reuse of the subject or issuer name. This standard recommends different entity names not to be reused, In- Do not use a unique identifier for the ternet network certificate. A certificate issuing authority that complies with this standard shall not generate a unique identifier with the issuer. Certificate, but should be able to parse the item and compare it during the application process. 5.2.3.9 Subject unique identifier subjectUniqueID This item is mainly used to deal with the reuse of subject names. This standard recommends not to reuse different entity names and is not recommended. For this item, the certificate issuing authority that complies with this standard shall not generate a certificate with the subject unique identifier, but shall be able to resolve it during the application process. Unique identifiers and comparisons. 5.2.3.10 extension extensions The entry is a sequence of one or more certificate extensions (SEQUENCE) whose content and data structure are defined in 5.2.4. 5.2.4 Certificate Extension Domain and Its Data Structure 5.2.4.1 Certificate extension The certificate extensions defined in this standard provide methods for associating some additional attributes with users or public keys and the management of certificate structures. method. Digital certificates allow the definition of standard extensions and private extensions. Extensions in each certificate can be defined as critical and non-critical Sexual. An extension consists of three parts, which are the extension type, the extension key, and the extension value. Extension criticality (extension Criticality) tells a user of a certificate whether to ignore an extension type. Certificate application system does not recognize critical When expanding, the certificate should be rejected, and if the non-critical extension is not recognized, the extension's information can be ignored. This article defines some standard extensions. It is important to note that in the actual application process, if a critical extension is adopted, This certificate may not be available in some general-purpose applications. Each extension includes an object identifier OID and an ASN.1 structure. When an extension appears in the certificate, the OID is used as The extnID entry appears, and its corresponding ASN.1 encoding structure is the value of the 8-bit string extnValue. Specific to a particular certificate The extension can only appear once. For example, a certificate can only contain one certificate authority key identifier extension. One extension contains one Boolean values are used to indicate the criticality of the extension. The default value is FALSE, which is non-critical. The text of each extension points to the key The acceptable value of the sex item. CAs that comply with this standard should support extensions such as key identifiers, basic restrictions, key usage, and certificate policies. If the certificate issued by the CA The subject in the book is an empty sequence, and the CA should support the subject replaceable name extension. Other extensions are optional. CA can also support Other extensions beyond the definition of this standard. The issuer of the certificate should note that if these extensions are defined as critical, they may be given to each other. Operational barriers. Applications that follow this standard should recognize at least the following extensions. key usage, certificate policy, subject replacement name, basic restrictions, name Restrictions, policy restrictions, and extended key usage. In addition, this standard recommends support for the authority and subject key identifier. (subjectkeyidentifier) and policy map extension. 5.2.4.2 Standard extension 5.2.4.2.1 Overview 5.2.4.2 Define standard certificate extensions for digital certificates, each extension corresponding to an OID defined in GB/T 16264.8-2005 turn off. These OIDs are members of id-ce and are defined as follows. Id-ce OBJECTIDENTIFIER..= {joint-iso-ccitt(2)ds(5)29} 5.2.4.2.2 Authority Key Identifier authorityKeyIdentifier The authority key identifier extension provides a way to identify the public key corresponding to the certificate signing private key. When the issuer has This extension is used when multiple keys coexist or have multiple signature keys due to changes. Identification can be based on the subject secret in the issuer certificate The key identifier or based on the issuer's name and serial number. All certificates generated by the corresponding CA shall include the keyIdentifier entry of the authorityKeyIdentifier extension to facilitate the establishment of the chain. When the CA issues its public key in the form of a "self-signed" certificate, the certificate authority key identifier can be omitted. At this point, the subject and certification The organization key identifiers are identical. This item can be used both as a certificate extension and as a CRL extension. This item identifies the public secret signed on the certificate or CRL. key. It can identify different keys used by the same CA (for example, when a key update occurs). This definition is as follows. id-ce-authorityKeyIdentifierOBJECTIDENTIFIER..= {id-ce35} AuthorityKeyIdentifier..=SEQUENCE{ keyIdentifier [0]KeyIdentifier OPTIONAL, authorityCertIssuer [1]GeneralNames OPTIONAL, authorityCertSerialNumber[2]CertificateSerialNumberOPTIONAL } (WITHCOMPONENTS {,authorityCertIssuer PRESENT, authorityCertSerialNumberPRESENT}│ WITHCOMPONENTS {,authorityCertIssuerABSENT, authorityCertSerialNumberABSENT}) KeyIdentifier..= OCTETSTRING. The value of the KeyIdentifier entry should be derived from the public key used to validate the certificate signature or derived by generating a unique value. Public key The key identifier KeyIdentifier can be generated in two general ways. a) The keyIdentifier consists of the 160-bit SHA1 hash value of the BITSTRINGsubjectPublicKey value (removing the label, long Degrees and bytes not used); b) The keyIdentifier is the lowest of the SHA-1 hash values of 0100 plus the BITSTRINGsubjectPublicKey value followed by The 60bit bit is composed. This key can be identified by the key identifier in the keyIdentifier field, or by the identity of the certificate of this key (given The certificate issuer in the authorityCertIssur field and the certificate serial number in the authorityCertSerialNumber field) Knowledge, or can be identified by the key identifier and the certificate identifier of this key. If two forms of identification are used, then the certificate or CRL The issuer should ensure that they are consistent. For the authority's all key identifiers containing extended certificates or CRLs, each The key identifier should be unique. Implementations that do not require support for this extension can handle all names in the authorityCertIssuer field form. The certificate authority specifies or automatically generates the certificate serial number, so that the issuer and the certificate serial number are combined to uniquely identify one. Certificate. All certificates, except for self-signed certificates, should include this extension and should include the keyIdentifier entry. If the certificate of the issuer’s certificate If the book has a SubjectKeyIdetifier extension, the keyIdentifier entry in this extension should be extended with the SubjectKeyIdetifier of the issuer's certificate. The value of the exhibition is consistent. If the certificate's certificate does not have a SubjectKeyIdetifier extension, you can use the two methods described in the article. One to produce. The keyIdentifier, authorityCertSerialNumber in the structure is recommended, but this extension should be non-critical. 5.2.4.2.3 Subject Key Identifier SubjectKeyIdentifier The principal key identifier extension provides a way to identify a certificate that contains a particular public key. This extension identifies the certified public Open the key. It can distinguish between different keys used by the same principal (for example, when a key update occurs). This definition is as follows. id-ce-subjectKeyIdentifierOBJECTIDENTIFIER..= {id-ce14} SubjectKeyIdentifier..=KeyIdentifier For each key identifier of the subj...

Tips & Frequently Asked Questions:

Question 1: How long will the true-PDF of GB/T 20518-2018_English be delivered?

Answer: Upon your order, we will start to translate GB/T 20518-2018_English as soon as possible, and keep you informed of the progress. The lead time is typically 4 ~ 6 working days. The lengthier the document the longer the lead time.

Question 2: Can I share the purchased PDF of GB/T 20518-2018_English with my colleagues?

Answer: Yes. The purchased PDF of GB/T 20518-2018_English will be deemed to be sold to your employer/organization who actually pays for it, including your colleagues and your employer's intranet.

Question 3: Does the price include tax/VAT?

Answer: Yes. Our tax invoice, downloaded/delivered in 9 seconds, includes all tax/VAT and complies with 100+ countries' tax regulations (tax exempted in 100+ countries) -- See Avoidance of Double Taxation Agreements (DTAs): List of DTAs signed between Singapore and 100+ countries

Question 4: Do you accept my currency other than USD?

Answer: Yes. If you need your currency to be printed on the invoice, please write an email to [email protected]. In 2 working-hours, we will create a special link for you to pay in any currencies. Otherwise, follow the normal steps: Add to Cart -- Checkout -- Select your currency to pay.

Question 5: Should I purchase the latest version GB/T 20518-2018?

Answer: Yes. Unless special scenarios such as technical constraints or academic study, you should always prioritize to purchase the latest version GB/T 20518-2018 even if the enforcement date is in future. Complying with the latest version means that, by default, it also complies with all the earlier versions, technically.