Skip to product information
1 of 9

PayPal, credit cards. Download editable-PDF and invoice in 1 second!

GM/T 0089-2020 English PDF (GMT0089-2020)

GM/T 0089-2020 English PDF (GMT0089-2020)

Regular price $320.00 USD
Regular price Sale price $320.00 USD
Sale Sold out
Shipping calculated at checkout.
Quotation: In 1-minute, 24-hr self-service. Click here GM/T 0089-2020 to get it for Purchase Approval, Bank TT...

GM/T 0089-2020: Simple certificate enrollment protocol specification

This Document defines the encryption and signature message syntax using the SM9 cryptographic algorithm. This Document is applicable to the standardized encapsulation of operation results when the SM9 algorithm is used for encryption and signature operations.
GM/T 0089-2020
GM
CRYPTOGRAPHY INDUSTRY STANDARD
OF THE PEOPLE REPUBLIC OF CHINA
ICS 35.040
CCS L 80
Simple certificate enrollment protocol specification
ISSUED ON: DECEMBER 28, 2020
IMPLEMENTED ON: JULY 01, 2021
Issued by: State Cryptography Administration
Table of Contents
Foreword ... 3
Introduction ... 4
1 Scope ... 5
2 Normative references ... 5
3 Terms and definitions ... 5
4 Abbreviations ... 6
5 SCEP function ... 7
5.1 SCEP entities ... 7
5.2 Client certification ... 9
5.3 Enrollment certification ... 9
5.4 CA/RA certificate distribution ... 10
5.5 Certificate enrollment ... 10
5.6 Certificate query ... 13
5.7 CRL query ... 14
5.8 Certificate revocation ... 14
6 SCEP security message object ... 15
6.1 Overview ... 15
6.2 SCEP message ... 15
6.3 SCEP message type ... 18
6.4 Simplified SignedData data type ... 21
7 SCEP transaction ... 21
7.1 Obtain a CA certificate ... 21
7.2 Certificate enrollment ... 22
7.3 Certificate polling ... 22
7.4 Certificate query ... 23
7.5 CRL query ... 24
7.6 Obtain the next CA certificate ... 24
8 SCEP transmission protocol ... 25
8.1 HTTP message format ... 25
8.2 SCEP message ... 25
Appendix A (Normative) GetCACaps message ... 29
Bibliography ... 30
Simple certificate enrollment protocol specification
1 Scope
This document defines a simple protocol for certificate enrollment using the SM2 algorithm.
This document is applicable to guiding the development of a digital certificate authentication system that provides automatic certificate enrollment, as well as the use of SM2 algorithm for automatic enrollment of device certificates. 2 Normative references
The contents of the following documents, through normative references in this text, constitute indispensable provisions of this document. Among them, for dated references, only the edition corresponding to that date applies to this document. For undated references, the latest edition (including all amendments) applies to this document.
GB/T 20518-2018 Information security technology - Public key infrastructure - Digital certificate format
GB/T 32918 (all parts) Information security technology - Public key
cryptographic algorithm SM2 based on elliptic curves
GB/T 35275-2017 Information security technology - SM2 cryptographic
algorithm encrypted signature message syntax specification
GM/T 0092 Specification of certificate request syntax based on SM2
cryptographic algorithm
GM/Z 4001 Cryptology Terminology
3 Terms and definitions
The terms and definitions defined by GM/Z 4001 and the following ones apply to this document.
3.1
Client
The device which applies for certificate service.
The client shall take reliable measures to protect the integrity of this information. The client can maintain multiple independent configurations applicable to multiple CAs. These configurations do not affect the protocol operation. 5.1.3 CA
The CA is the entity that issues the client certificate. The name of the CA shall appear in the issuer field of the generated certificate.
Before any PKI operation occurs, the CA shall obtain a CA certificate that complies with the configuration of GB/T 20518-2018. It can be a CA certificate issued by a higher-level CA.
The client shall obtain the CA certificate through the request message for obtaining CA certificate in 7.1.1. And use the certificate hash value to authenticate the CA certificate obtained by obtaining the CA certificate response message.
CA shall respond to certificate query requests online or provide certificate query results through LDAP.
CA can implement any policies and apply these policies to authenticate or deny client requests. If the server has issued a certificate for the client, and the certificate is still valid, the server can return the certificate previously created for the client.
If the client enters a timeout status after polling a pending transaction, it shall resynchronize by sending a request with the same certificate enrollment transaction name, key and transaction ID to the server. The CA shall return the status of certificate enrollment transaction, including issued certificates. The CA shall not create a new transaction, unless the certificate enrolled is revoked or the validity period has expired.
5.1.4 RA
RA is a kind of SCEP server. It performs certification and authorization checks on SCEP clients. At the same time, the certification request is forwarded to the CA. The name of the RA shall not appear in the issuer field of the generated certificate.
When RA returns a certificate through the response message of CA certificate in 7.1.2, it shall return both the RA certificate and the CA certificate. This response includes an RA certificate, indicating that the client is making a certificate-related request to the CA through an RA. In the subsequent secure communication, the client shall designate this RA as the server communication. 5.4 CA/RA certificate distribution
If the client has not obtained a CA/RA certificate before, before starting any PKI operation, it shall apply for a CA/RA certificate.
After the client obtains the CA certificate, the hash algorithm shall be used to calculate the hash value of the received CA certificate (and the RA certificate that may be included). If the client does not have a certificate path to the trust anchor, by comparing the certificate hash value with the information obtained by the locally-configured and out-of-band mode, the CA certificate is
authenticated.
Since the public key has not been exchanged between the client and CA/RA, it is impossible to protect these messages in accordance with the syntax format of GB/T 35275. And the data will be transmitted in plain text.
If RA is in use, according to the SignedData type format in GB/T 35275, a digital envelope will be returned. The envelope either contains the RA and CA
certificates, or only the CA certificate itself. The transmission protocol shall specify which one is returned.
After the client obtains the CA certificate, the hash algorithm shall be used to calculate the hash value of the received CA certificate (and the RA certificate that may be included). If the client does not have a certificate path to the trust anchor, by comparing the certificate hash value with the information obtained by the locally-configured and out-of-band mode, the CA certificate is
authenticated.
Since it may take a long time to transfer the query from the client to the CA/RA, and the RA certificate may change at any time, it is recommended that the client does not store the RA certificate; but shall retrieve the CA/RA certificate before each operation.
5.5 Certificate enrollment
The client creates a certificate request according to GM/T 0092 to start the certificate enrollment transaction; and sends it to CA/RA after encapsulating it according to GB/T 35275.
If the automatic enrollment certification mode is adopted, according to the policy, CA/RA returns a request response message CertRep; the status is set to
SUCCESS or FAILURE. For the definition of message types, see 6.2.2.3.
If the manual enrollment certification mode is adopted, the status of the CertRep message returned by CA/RA is set to PENDING. The client shall enter the polling mode by periodically sending the certificate polling GetCertInitial to 6 SCEP security message object
6.1 Overview
SCEP messages with confidentiality requirements adopt a two-layer structure, see GB/T 35275. By simultaneously applying digital envelope and digital signature, the end-to-end transaction information integrity and confidentiality of the information part of the SCEP message are protected.
The ContentType field of the outer layer shall be a digital signature SignedData structure, also known as pkiMessage. The ContentInfo field of the inner layer shall be an EnvelopedData structure, also known as pkcsPKIEnvelope. The data messageData carried in the SCEP message is encapsulated in
pkcsPKIEnvelope. Its data format is defined by the messageType attribute in pkiMessage.
If messageData is not transmitted, the entire pkcsPKIEnvelop shall be ignored. For example, CertRep messages with FAILURE and PENDING status have no
signature information.
6.2 SCEP message
6.2.1 SCEP message structure
The basic structure of all secure SCEP message objects is the SCEP message. This structure is composed of the SignedData type in GB/T 35275, as defined in 8.1 in GB/T 35275-2017. There are the following restrictions:
If there is a signed content (the CertRep message is in the SUCCESS status), the content shall be a pkcsPKIEnvelope structure and shall match the
messageType attribute.
6.2.2 Signed transaction attributes
6.2.2.1 Overview
According to 8.2 of GB/T 35275-2017, SignerInfo of SignedData needs to carry a series of authenticated attributes (authenticatedAttributes). All messages shall include transactionID, messageType, senderNonce and any other
attributes required by 8.2 of GB/T 35275-2017. If it is a response message, it shall include pkiStatus and recipientNonce attributes; see Table 1.
6.2.2.4 Transaction status (pkiStatus)
All response messages shall include transaction status information, defined as pkiStatus:
SUCCESS(0): Approve
FAILURE(2): Reject and provide the failInfo attribute defined in 6.2.2.5 PENDING(3): Pending
Undefined message types are handled as errors.
6.2.2.5 Failure information (failInfo)
The failure information attribute shall include the following failure reasons: badAlg(0): Unrecognized or unsupported algorithm identification
badMessageCheck(1): Integrity check failure
badRequest(2): Transaction is not allowed or supported
badTime(3): Signing time attribute is not close enough to the system time badCertId(4): Do not identify a certificate that can match the provided standard
Undefined message types are handled as errors.
6.2.2.6 Sender nonce and recipient nonce (senderNonce and
recipientNonce)
senderNonce and recipientNonce are 16-byte random numbers generated by
each transaction. Used to resist replay attacks.
The client shall include the senderNonce in the PKI message sent to the server. The server shall copy the senderNonce to the recipientNonce. The client shall verify the recipientNonce.
6.2.2.7 Signing time (signingTime)
The signing time attribute specifies the time for the signer to perform the signing process. This attribute is optional. For its definition, please refer to PKCS#9. 6.2.3 SCEP digital envelope
The information part of the SCEP message is contained in the EnvelopedData In addition to the authenticatedAttributes required by valid GB/T 35275, pkiMessage shall also contain the following attributes:
- Transaction identifier attribute transactionID;
- Message type attribute messageType, which is set to GetCert;
- Sender nonce attribute senderNonce.
6.3.6 CRL query
This type of messageData contains an IssuerAndSerialNumber. It is defined in 6.7 of GB/T 35275-2017 and contains the name and serial number of the
certificate issuer that needs to be confirmed.
In addition to the authenticatedAttributes required by valid GB/T 35275, pkiMessage shall also contain the following attributes:
- Transaction identifier attribute transactionID;
- Message type attribute messageType, which is set to GetCRL;
- Sender nonce attribute senderNonce.
6.4 Simplified SignedData data type
The simplified SignedData data type refers to the simplification of the signed data type SignedData in GB/T 35275. It does not have a signer; is only used to transmit certificates and certificate revocation lists.
When carrying a certificate, the certificate will be included in the certificates field of SignedData. When carrying CRL, CRL will be included in the crls field of SignedData.
7 SCEP transaction
7.1 Obtain a CA certificate
7.1.1 Request message format
In order to obtain the CA certificate, the client sends a GetCACert message to the server. There is no relevant data in this message.
7.1.2 Response message format
The response message format depends on whether the server has an RA
certificate or only one CA certificate. The server shall clearly specify what kind request is rejected; or the configured polling time limit (or maximum number of polls) is exceeded.
Since GetCertInitial is part of the enrollment, the message exchange during the polling period shall carry the same service ID attribute as the previous PKCSReq. When the server receives a GetCertInitial that does not match
PKCSReq, it shall ignore the request.
Since the certificate has not been issued at this time, the client can only use its own subject name (sent via PKCSReq and included in the certificate enrollment request in the GM/T 0092 format) to identify the polling certificate request. Because there can be multiple outstanding requests from a client (for example, different keys and different key usage will be used to request multiple certificates), the transaction ID shall also be included, to eliminate ambiguity between multiple requests.
Prerequisite: The client has received a CertRep message with a transaction status of PENDING.
Post-condition: The client has received a valid response, which can be a valid certificate (transaction status is SUCCESS), application failure (transaction status is FAILURE), or polling cycle timeout.
7.3.2 Response message format
The response message of GetCertInitial is the same as in 7.2.2.
7.4 Certificate query
7.4.1 Request message format
Through the name of the issuer and the certificate serial number of the certificate to be queried, the client can query the issued certificate from the SCEP server. This transaction is not used to provide general certificate directory services.
For this transaction, a GetCert message is sent from the client to the server; and a CertRep message is received from the server as a response.
Prerequisite: The certification authority has issued the client entity's certificate. The serial number specified by the issuer is known.
Post-condition: A certificate shall be returned if successful; or the request is rejected.
7.4.2 Response message format

View full details