Skip to product information
1 of 12

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

GB/T 25061-2010 English PDF (GBT25061-2010)

GB/T 25061-2010 English PDF (GBT25061-2010)

Regular price $320.00 USD
Regular price Sale price $320.00 USD
Sale Sold out
Shipping calculated at checkout.
Quotation: 24-hr self-service. Click GB/T 25061-2010
See Chinese contents: GB/T 25061-2010

GB/T 25061-2010: Information security technology -- Public key infrastructure -- XML digital signature syntax and processing specification

This Standard specifies the syntax and processing rules of establishing and representing XML digital signature. XML digital signature provides integrity, message authentication and signer authentication services to any type of data. This Standard is applicable to application programs, systems or services of establishing and processing XML digital signature.
GB/T 25061-2010
ICS 35.040
L 80
Information Security Technology - Public Key
Infrastructure - XML Digital Signature Syntax and
Processing Specification
Issued by: General Administration of Quality Supervision, Inspection and Quarantine;
Standardization Administration of the PEOPLE Republic of
Table of Contents
Foreword ... 3
Introduction ... 4
1 Scope ... 5
2 Normative References ... 5
3 Terms, Definitions and Abbreviations ... 6
4 Overview of XML Signature ... 7
5 Processing Rules ... 9
6 Core Signature Syntax ... 10
7 Additional Signature Syntax ... 29
Appendix A (Normative) Definition of XML Digital Signature Document Type 33 Appendix B (Normative) Definition of XML Digital Signature Schema ... 44 Appendix C (Informative) Algorithms ... 51
Appendix D (Informative) Examples of XML Digital Signature ... 60
Bibliography ... 67
Information Security Technology - Public Key
Infrastructure - XML Digital Signature Syntax and
Processing Specification
1 Scope
This Standard specifies the syntax and processing rules of establishing and representing XML digital signature. XML digital signature provides integrity, message authentication and signer authentication services to any type of data.
This Standard is applicable to application programs, systems or services of establishing and processing XML digital signature.
2 Normative References
Through the reference in this Standard, clauses in the following documents become clauses of this Standard. In terms of references with a specific date, all the subsequent modification lists (excluding corrected content) or revised editions are not applicable to this Standard. However, all parties that reach an agreement in accordance with this Standard are encouraged to explore the possibility of adopting the latest version of these documents. In terms of references without a specific date, the latest version is applicable to this Standard.
GB/T 1988 Information Technology - 7-bit Coded Character Set for Information Interchange (GB/T 1988-1998, eqv ISO/IEC 646-1991)
GB 13000.1 Information Technology - Universal Multiple-Octet Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane (GB 13000.1-1993, idt ISO/IEC 10646-1: 1993)
GB/T 16264.8 Information Technology - Open Systems Interconnection - The Directory - Part 8: Public-key and Attributed Certificate Frameworks (GB/T 16264.8-2005, ISO/IEC 9594-8: 2001, IDT)
GB/T 18793-2002 Information Technology - Extensible Markup Language (XML) 1.0 (W3C RFC-xml: 1998, NEQ)
RFC 2253 Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names
RFC 2396 Uniform Resource Identifiers (URI): Generic Syntax
Signature application refers to an application program, which implements the indispensable parts requested in this Standard, and whose structure and substructure of Signature element type comply with the requirements in this Standard. 3.1.7 Signature validation
Signature validation refers to the core validation of whether the SignedInfo result processed through the canonicalization method appointed by CanonicalizationMethod and the signature method appointed by SignatureMethod matches with the value in SignatureValue.
3.1.8 Signer authentication
Signer authentication is used to declare and identify the attribute of the signer. Signature shall indicate the signer of a document, message or record, and without authorization, it is extremely difficult for others to generate it. Signer authentication shall be implemented through application. This Standard supports signer authentication. However, the specific mode of such authentication shall be stipulated by relevant authentication standards.
3.1.9 Transform
Transform refers to the processing of a piece of data from original state to export state. Typical transform includes XML normalization, XPath and XSLT.
3.2 Abbreviations
The following abbreviations are applicable to this Standard:
CRL: Certification Revocation List
DN: Distinguished Name
URI: Universal Resource Identifier
XML: Extensible Markup Language
XSL: Extensible Stylesheet Language
XSLT: XSL Extensible Stylesheet Language Transformations
4 Overview of XML Signature
4.1 Overview
This Chapter describes XML digital signature structure. Chapter 5 provides processing rules. Chapter 6 provides core signature syntax. Chapter 7 provides signature syntax of additional elements.
Core validation shall include:
a) Reference validation: validate digest included in every Reference in SignedInfo; b) Signature validation: use cryptographic method to conduct signature validation of the signature obtained through SignedInfo calculation.
5.2.2 Reference validation
Reference validation has the following steps:
a) In accordance with canonicalization method appointed by
CanonicalizationMethod in SignedInfo, canonicalize SignedInfo element;
b) In terms of every Reference in SignedInfo:
1) Obtain data object for digest processing;
2) Use digest algorithm appointed in Reference to calculate the digest value of the result data object;
3) Compare the digest value generated in the previous step and the content of DigestValue element in SignedInfo; if there is any difference, then, the validation is failed.
NOTE: SignedInfo is canonicalized in the first step; the application program shall guarantee that CanonicalizationMethod would not lead to any error.
5.2.3 Signature validation
Signature validation has the following steps:
a) From KeyInfo or other modes, obtain key information;
b) Use CanonicalizationMethod to obtain canonicalization form of
SignatureMethod. Then, use the obtained result and the key information
obtained above to compare with the signature value on SignedInfo element. 6 Core Signature Syntax
6.1 Overview
This Chapter stipulates the specific syntax of core signature elements. If it is not particularly declared, elements involved in this Chapter shall be supported. Signature syntax shall be defined through document type definition and XML schema definition. All document type definitions and XML schema definitions shall use the following XML preamble, declaration and internal entity.
identified by URI points to identical-document reference or when the application does not request transform, signature application program does not need to resolve it. If fragment emerges in front of an absolute or relative URI, the connotation of the fragment shall be defined by MIME type of resources. In terms of XML document, a proxy may also be used to complete signature program?€?s URI parsing (including the fragment processing). Thus, if fragment processing is not reference validation through standardized processing, it might fail. Therefore, this Standard suggests that URI attribute shall not include fragment identifier, instead, it shall consider this processing process as an additional XPath transform to explain.
When fragment does not emerge in front of URI, XML signature program shall support a null-URI and unknown XPointer. If application program still hopes to support any normalized operation of annotation saving, then, it is suggested to provide support to XPointer of the same document. Since it might be impossible for application program to control fragment generation, all the other supports for XPointer are all optional; all the supports for unknown XPointer and externally quoted XPointer are also optional. Same document URI reference
Parsing same document reference shall generate a XPath node set which is suitable for normalized XML application. Particularly speaking, parsing a null-URI shall generate a XPath node set, which contains every non-annotated node of XML document, which has URI attribute. In fragment URI, characters behind # shall comply with XPointer syntax. When processing XPointer the application program shall use the root node of XML document, which contains URI attribute, to initialize XPointer processing document. If the result after XPointer processing is a node set, application program shall be obtained through the following methods:
a) Discard point node.
b) Replace XPath nodes that have integral or partial content within all the ranges with nodes of every range.
c) Use child node to replace root node (assume that it is in the node set). d) Replace all the element nodes E with E and E?€?s descendant nodes (text, annotation, PI or element) and namespace and attribute node of all the E and its descendant elements.
e) If URI is not an integral XPointer, then, delete all the annotation nodes. The fourth step of replacement is indispensable. XPointer uses subtree?€?s root node element to indicate the subtree of syntax parser tree of an XML document. Normalized XML considers a node set as a set of nodes. Under this circumstance, the deficiency of descendant nodes will lead to insufficient content of normalization form. The last step shall be used to handle null-URI, raw pointer and subsequence XPointer. In the transmission of a node set, node set shall be processed in accordance with the circumstance with and without annotation. In the processing of byte stream, XPath expression (default or without annotation) will be dispatched. Hence, in order to preserve the default behavior of demolding annotation in the transmission of node set, incomplete XPointer URI shall be eliminated. If annotation needs to be reserved when elements are chosen through identifier ID, complete XPointer like this shall be used: . If annotation needs to be reserved in the selection of
an entire document, complete XPointer like this shall be used:
. XPointer contains a simple XPath expression which
contains root node. The fourth step will replace this root node with all nodes (namespace of all the descendants, all the attributes and all the nodes) of the syntax parser tree. Transform element
Optional transform element includes a sequential list of Transform elements. These elements describe how the signer obtains data object for digest processing. The output of every Transform shall be considered as the input of the next Transform. The input of the first Transform is the result of parsing Reference element?€?s URI attribute; the result of the last Transform is the input of DigestMethod algorithm. After using Transform, what the signer processes is no longer the original document, but a document after Transform processing.
Every Transform element is constituted of an algorithm attribute and content parameters matching with this algorithm (if there are any parameters). Algorithm attribute value appoints the name of algorithm that needs to be processed. Transform content provides additional data to control the algorithm?€?s processing of Transform input.
In Reference processing model, it is once mentioned that some Transforms use XPath node set as the input, while some others need a byte stream. If the practical input complies with the demand for Transform, Transform will not alter the input in operation. If Transform?€?s input requirements are different from the format of the practical input, then, the practical input needs to go through some transformation. Transform might need explicit MIME type, character set, or relevant information of data received from the previous Transform or source data. The characteristics of such data shall be provided in the form of the parameters of Transform algorithm. Through the form of parameters, these data characteristics shall be provided to Transform algorithm, and be described in algorithm specification.
Examples of Transform include, but are not limited to: base64 decoding, XML canonicalization, XPath filtering and XSLT.
describing or associating with the same certificate, the following elements may be used together or used for multiple times;
b) Please see the specific content below:
X509IsserSerial element, shall contain unique name/serial number of
X509issuer that complies with RFC2253 specification.
X509SubjectName element, shall contain a X509 certificate subject name; it shall comply with RFC2253 standard.
X509SKI element, shall contain base64 simple encoding, which is extended from X509 certificate subject key identifier.
X509 certificate element, shall contain X509 certificate of gebase64 encoding. Elements of external naming space which accompany or supplement the above elements.
X509CRL element, shall contain a certificate revocation list (CRL) of base64 encoding.
X509IssuerSerial, X509SKI and X509SubjectName elements shall point to certificate or certificate that contains validation key. All elements that point to a specific certificate shall be placed in X509Data. Moreover, reference shall point to this X509Data element. X509IssuerSerial, X509SKI and X509Subject Name elements, which use the same key but are associated with different certificates, shall be divided into one KeyInfo. However, they may emerge in multiple X509Data elements.
Certificate that emerges in X509Data element shall be able to be associated with validation key. Through validation key, or the validation key may be contained as a part of certificate chain. However, the certificate chain is not requested to be sequential. Please see a specific example below:
NOTE: in terms of PKCS#7 coded certificate chain or CRL, there is no direct stipulation. In a ???X509Data??? element, a group of certificates and CRL may emerge. In addition, in a ???KeyInfo???, multiple ???X509Data??? elements may emerge. Whenever multiple certificates emerge in a ???X509Data??? element, at least one certificate shall contain public key of validation signature.
Character string (???X509IssuerSerial???, ???X509SubjectName??? or ???KeyName???) in DN shall be coded in accordance with the following methods:
a) Consider character string as a consecutive character string in GB 13000; b) Special characters shall add ?€?\?€? for meaning transfer. Special characters include ?€?#?€? in the forefront of character string, or ?€?,?€?, ?€?+?€?, ?€??€??€?, ?€?\?€?, ?€?????€?, ?€?????€? or ?€?;?€?; c) Transfer meaning of all the control characters in GB/T 1988 (the scope of GB 13000.1: \x00 - \x1f), namely, add character ?€?\?€? in front of their binary hexadecimal number in GB 13000.1;
d) Transfer meaning of all the subsequent spacings; use ?€?\20?€? to replace ?€?\?€?. Since XML document logically contains characters, not bytes, the GB 13000.1 result character string shall be coded in accordance with the character encoding method that is adopted in the generation of the physical representation of the XML document. automatically remove the identified element, its child element and any descendant annotations, and the starting and ending label of processing instruction. The output of this transform is octet stream.
C.7.4 XPath filtering
Standard specification of XPath expression evaluation is XPath. XPath expression, which is to be evaluated, will emerge in character content. Character content is a transform parameter child element, whose name is XPath.
This transform needs XPath node set. It shall be noted that if the practical input is XPath node set, which is obtained through null-URI or unknown XPointer parsing, then, annotation node will be neglected. If the practical input is octet stream, then, application program must transform the octet stream into XPath node set, which is suitable for canonicalized XML with annotation. In other words, the input node set should be equivalent to a node set established through the following process of description:
a) Initialize XPath evaluation context. Firstly, set up the initial node to be equal to the root node of the input XML document. Then, set up the context position and context size to be 1.
b) Calculate XPath expression ( )
The calculation of this expression includes all nodes (including annotation) of document in the node set that expresses the octet stream. The output of the transform is still XPath node set. In terms of XPath expression that emerges in XPath parameter, every node in the input node set shall be calculated once. The result shall be converted into Boolean value. If Boolean value is true, then, the node will be contained in the output node set. If Boolean value is false, then, the node will be neglected by the output node set.
The main objective of this transform is to guarantee that after adding signature, changes of the particular definition of the input XML document are merely allowed. The demand above shall be implemented through the method below. The output includes all the input nodes and signature node input, which is allowed to be altered for only one time. In application context, the author of XPath expression shall be responsible for handling all nodes that might affect the performance of transform output during the change.
An important situation is that a document might need two enveloped signatures. In digest calculation, every signature shall exclude itself. However, the second Signature transform. However, it is merely applicable to node set of its parent XML document. NOTE: it is unnecessary to use XPath expression evaluator to establish this transform, but this transform must establish the output in accordance with the same method of XPath transform being parameterized by XPath expression as it is mentioned above.
C.7.6 XSLT transform
Standard specification of XSL transform is XSLT. Specification of stylesheet elements with namespace limitation should adopt particularly appointed stylesheet. XSLT processing model determines whether local XSLT declaration instantiation shall be conducted on embedded processing in resources. Sequential application of multiple stylesheets might need multiple transforms. In terms of the identification of remote stylesheet of a given URI, this Appendix does not provide any particular stipulations. It may be transmitted through xsl:include or xsl:import in transformed stylesheet child element.
This transform needs an octet stream as the input. If the practical input is XPath node set, then, the signature application program should comply with the method described by Reference processing model to transform it into an octet stream.
The output of this transform is octet stream. In XSLT specification, the rules of processing XSL stylesheet or ???Transform??? element are explained. This Appendix suggests XSLT transform creators to use XML output method to process XML and HTML. Since different XSLT implementation will unnecessarily generate completely identical output sequence, this Appendix suggests adding a Transform behind XSLT transform to canonicalize the output. These operations may help application programs that support XSLT transform to guarantee the interoperability of the signature result. If the output is indeed HTML, then, the result of these processing steps are logically equivalent.
also combine with other algorithms (for example, RSA-SHA1 filling algorithm), sign algorithm name, so as to defend against the attack from those replaced algorithms which have relatively weak complexity. In order to improve the interoperability of applications, even though whether these algorithms should be used completely depends on the creator of signature, this Appendix still enumerates a series of signature algorithms. This Appendix recommends some of them; users are also allowed to declare their own algorithms.
[s05-11] Every Reference element includes digest algorithm and digest result of the identifi...

View full details