GB/T 25061-2020 (GB/T 25061-2010) PDF English
US$320.00 · In stock · Download in 9 secondsGB/T 25061-2010: Information security technology -- Public key infrastructure -- XML digital signature syntax and processing specification Delivery: 9 seconds. True-PDF full-copy in English & invoice will be downloaded + auto-delivered via email. See step-by-step procedureStatus: Obsolete GB/T 25061: Evolution and historical versions
| Standard ID | Contents [version] | USD | STEP2 | [PDF] delivery | Name of Chinese Standard | Status |
| GB/T 25061-2020 | English | 1149 |
Add to Cart
|
8 days
|
Information security technology. XML digital signature syntax and processing specification
| Valid |
| GB/T 25061-2010 | English | 320 |
Add to Cart
|
0-9 seconds. Auto-delivery
|
Information security technology -- Public key infrastructure -- XML digital signature syntax and processing specification
| Obsolete |
Excerpted PDFs (Download full copy in 9 seconds upon purchase)PDF Preview: GB/T 25061-2010
GB/T 25061-2010: Information security technology -- Public key infrastructure -- XML digital signature syntax and processing specification
---This is an excerpt. Full copy of true-PDF in English version (including equations, symbols, images, flow-chart, tables, and figures etc.), auto-downloaded/delivered in 9 seconds, can be purchased online: https://www.ChineseStandard.net/PDF.aspx/GBT25061-2010
NATIONAL STANDARD OF THE
PEOPLE’S REPUBLIC OF CHINA
ICS 35.040
L 80
Information Security Technology - Public Key
Infrastructure - XML Digital Signature Syntax and
Processing Specification
Issued on: SEPTEMBER 2, 2010
Implemented on: FEBRUARY 1, 2011
Issued by. General Administration of Quality Supervision, Inspection and
Quarantine;
Standardization Administration of the People’s Republic of
China.
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.
6.4.4.4 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.
6.4.4.5 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
Identifier.
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
Identifier.
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
identified data object after processing. It may also include transforms of generating
digest processing input. Through the calculation of the digest value of data object and
signature of the value, signature can be added to the data object. Afterwards, through
reference validation and signature validation, the signature result can be validated.
[s14-16] KeyInfo indicates public key for signature validation. Possible forms of
identification include certificate, key name, key exchange algorithm and information.
KeyInfo is optional because of two reasons. Firstly, the signer may be reluctant to
represent public key information to all the document processing parties. Secondly,
public key information might be obtained through application context, and it will be
unnecessary to explicitly express it. Since KeyInfo is outside SignedInfo, if the signer
hopes to add the public key information to the signature information, using Reference
can quite easily identify it and add KeyInfo to the signature.
D.1.2 More content of reference
[s05] URI attribute of optional Reference identifies the data object to be signed. In a
digital signature, only one Reference at the most may neglect this attribute.
[s05-s08] This identification, together with transform, describe which forms are
provided by the signer for digest processing to obtain signature data information. As
long as the digest validates, the verifier may use another method to obtain the digest.
A special circumstance is that the verifier might obtain the content from a different
location, for example, from local storage, instead of a place appointed by URI.
[s06-s08] Transform is an optional and sequential list of processing steps. Before
digest processing of resource content, use these steps first to process them. Transform
might include the following operations. canonicalization, encoding, decoding (including
compression and decompression), XSLT, XPath, XML Schema validation or XInclude.
[p04] In optional Reference, Type attribute provides relevant information of resources
identified by URI. Whether it is Object, SignatureProperty or Manifest element may be
indicated. Application program can implement special initialization processing of some
Reference elements in accordance with this. The orientation towards reference of an
XML data element in Object element shall indicate the element truly being oriented. If
element content is not XML (perhaps binary or encoded data), the reference shall
indicate Object and Reference type. If element content is XML, the Object shall be
indicated. It shall be noted that Type is an auxiliary attribute; core processing does not
need to adopt any processing on it, or, validate its correctness.
[p10] Object is an optional element, which is used to import data object in Signature
element or other places. The encoding of Object is optional.
[p11-18] Signature attribute, for example, signature time, may be electively indicated
in Reference to implement the signature.
D.3 Object and Manifest Extension Examples
This Appendix uses Manifest element to demonstrate how to satisfy some additional
demands. Here are two demands and how they are satisfied by Manifest element.
a) Even though signature operation itself is public key signature with large
consumption, application programs still often need efficient signature operation
of multiple data objects. This needs to be implemented by containing multiple
Reference elements in SignedInfo. That is because every added digest
guarantees the security of data for digest processing. However, some
applications perhaps do not need core validation behavior, which is
accompanied with this method. That is because it needs every Reference in
SignedInfo to go through the process of the reference validation process. These
applications might hope to reserve reference validation decision-making logic
for them. For instance, an application might receive a legitimate SignedInfo
element of Signature, which contains three Reference elements. If one of the
References fails in operation, signature will fail in the core validation process.
However, application programs might hope to consider the two valid Reference
elements as valid in processing, or, they might hope to adopt different
countermeasures in accordance with different causes for the failure. In order to
implement this, SignedInfo needs to take Manifest element, which contains one
or multiple Reference elements as a reference. Then, the reference validation
of Manifest is under the control of the application programs.
......
Source: Above contents are excerpted from the full-copy PDF -- translated/reviewed by: www.ChineseStandard.net / Wayne Zheng et al.
|