Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 3075

XML-Signature Syntax and Processing

Pages: 64
Obsoleted by:  3275
Part 2 of 3 – Pages 26 to 44
First   Prev   Next

ToP   noToC   RFC3075 - Page 26   prevText

4.4 The KeyInfo Element

KeyInfo is an optional element that enables the recipient(s) to obtain the key needed to validate the signature. KeyInfo may contain keys, names, certificates and other public key management information, such as in-band key distribution or key agreement data. This specification defines a few simple types but applications may place their own key identification and exchange semantics within this element type through the XML-namespace facility [XML-ns]. If KeyInfo is omitted, the recipient is expected to be able to identify the key based on application context information. Multiple declarations within KeyInfo refer to the same key. While applications may define and use any mechanism they choose through inclusion of elements from a different namespace, compliant versions MUST implement KeyValue (section 4.4.2) and SHOULD implement RetrievalMethod (section 4.4.3).
ToP   noToC   RFC3075 - Page 27
   The following list summarizes the KeyInfo types defined by this
   specification; these can be used within the RetrievalMethod Type
   attribute to describe the remote KeyInfo structure as represented as
   an octect stream.


   In addition to the types above for which we define structures, we
   specify one additional type to indicate a binary X.509 Certificate


   Schema Definition:

<element name="KeyInfo">
    <choice maxOccurs="unbounded">
      <any processContents="lax" namespace="##other" minOccurs="0"
      <element name="KeyName" type="string"/>
      <element ref="ds:KeyValue"/>
      <element ref="ds:RetrievalMethod"/>
      <element ref="ds:X509Data"/>
      <element ref="ds:PGPData"/>
      <element ref="ds:SPKIData"/>
      <element name="MgmtData" type="string"/>
    <attribute name="Id" type="ID" use="optional"/>

<!ELEMENT KeyInfo %Key.ANY; >
          Id ID  #IMPLIED >

4.4.1 The KeyName Element

The KeyName element contains a string value which may be used by the signer to communicate a key identifier to the recipient. Typically, KeyName contains an identifier related to the key pair used to sign the message, but it may contain other protocol-related information that indirectly identifies a key pair. (Common uses of KeyName include simple string names for keys, a key index, a distinguished name (DN), an email address, etc.)
ToP   noToC   RFC3075 - Page 28
   Schema Definition:

   <!-- type declared in KeyInfo -->

   <!ELEMENT KeyName (#PCDATA) >

4.4.2 The KeyValue Element

The KeyValue element contains a single public key that may be useful in validating the signature. Structured formats for defining DSA (REQUIRED) and RSA (RECOMMENDED) public keys are defined in Signature Algorithms (section 6.4). Schema Definition: <element name="KeyValue"> <complexType mixed="true"> <choice> <any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <element ref="ds:DSAKeyValue"/> <element ref="ds:RSAKeyValue"/> </choice> </complexType> </element> DTD: <!ELEMENT KeyValue %Key.ANY; >

4.4.3 The RetrievalMethod Element

A RetrievalMethod element within KeyInfo is used to convey a reference to KeyInfo information that is stored at another location. For example, several signatures in a document might use a key verified by an X.509v3 certificate chain appearing once in the document or remotely outside the document; each signature's KeyInfo can reference this chain using a single RetrievalMethod element instead of including the entire chain with a sequence of X509Certificate elements. RetrievalMethod uses the same syntax and dereferencing behavior as Reference's URI (section and The Reference Processing Model (section except that there is no DigestMethod or DigestValue child elements and presence of the URI is mandatory. Note, if the result of dereferencing and transforming the specified URI is a node set, then it may need to be to be canonicalized. All of the KeyInfo types defined by this specification (section 4.4) represent octets,
ToP   noToC   RFC3075 - Page 29
   consequently the Signature application is expected to attempt to
   canonicalize the nodeset via the The Reference Processing Model

   Type is an optional identifier for the type of data to be retrieved.
   Schema Definition

   <element name="RetrievalMethod">
         <element ref="ds:Transforms" minOccurs="0"/>
       <attribute name="URI" type="uriReference"/>
       <attribute name="Type" type="uriReference" use="optional"/>

   <!ELEMENT RetrievalMethod (Transforms?) >
   <!ATTLIST RetrievalMethod
             URI       CDATA   #REQUIRED
             Type      CDATA   #IMPLIED >

4.4.4 The X509Data Element

Identifier Type="" (this can be used within a RetrievalMethod or Reference element to identify the referent's type) An X509Data element within KeyInfo contains one or more identifiers of keys or X509 certificates (or certificates' identifiers or revocation lists). Five types of X509Data are defined 1. The X509IssuerSerial element, which contains an X.509 issuer distinguished name/serial number pair that SHOULD be compliant with RFC2253 [LDAP-DN], 2. The X509SubjectName element, which contains an X.509 subject distinguished name that SHOULD be compliant with RFC2253 [LDAP- DN], 3. The X509SKI element, which contains an X.509 subject key identifier value. 4. The X509Certificate element, which contains a base64-encoded [X509v3] certificate, and 5. The X509CRL element, which contains a base64-encoded certificate revocation list (CRL) [X509v3].
ToP   noToC   RFC3075 - Page 30
   Multiple declarations about a single certificate (e.g., a
   X509SubjectName and X509IssuerSerial element) MUST be grouped inside
   a single X509Data element; multiple declarations about the same key
   but different certificates (related to that single key) MUST be
   grouped within a single KeyInfo element but MAY occur in multiple
   X509Data elements.  For example, the following block contains two
   pointers to certificate-A (issuer/serial number and SKI) and a single
   reference to certificate-B (SubjectName) and also shows use of
   certificate elements

     <X509Data> <!-- two pointers to certificate-A -->
         <X509IssuerName>CN=TAMURA Kent, OU=TRL, O=IBM,
           L=Yamato-shi, ST=Kanagawa, C=JP</X509IssuerName>
     <X509Data> <!-- single pointer to certificate-B -->
       <X509SubjectName>Subject of Certificate B</X509SubjectName>
     </X509Data> <!-- certificate chain -->
       <!--Signer cert, issuer CN=arbolCA,OU=FVT,O=IBM,C=US, serial 4-->
       <!-- Intermediate cert subject CN=arbolCA,OU=FVTO=IBM,C=US
            issuer,CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US -->
       <!-- Root cert subject CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US -->

   Note, there is no direct provision for a PKCS#7 encoded "bag" of
   certificates or CRLs.  However, a set of certificates or a CRL can
   occur within an X509Data element and multiple X509Data elements can
   occur in a KeyInfo.  Whenever multiple certificates occur in an
   X509Data element, at least one such certificate must contain the
   public key which verifies the signature.
   Schema Definition

    <element name="X509Data">
          <sequence maxOccurs="unbounded">
              <element ref="ds:X509IssuerSerial"/>
              <element name="X509SKI" type="ds:CryptoBinary"/>
              <element name="X509SubjectName" type="string"/>
ToP   noToC   RFC3075 - Page 31
              <element name="X509Certificate" type="ds:CryptoBinary"/>
          <element name="X509CRL" type="ds:CryptoBinary"/>

    <element name="X509IssuerSerial">
          <element name="X509IssuerName" type="string"/>
          <element name="X509SerialNumber" type="integer"/>


   <!ELEMENT X509Data ((X509IssuerSerial | X509SKI | X509SubjectName |
                       X509Certificate)+ | X509CRL)>
    <!ELEMENT X509IssuerSerial (X509IssuerName, X509SerialNumber) >
    <!ELEMENT X509IssuerName (#PCDATA) >
    <!ELEMENT X509SubjectName (#PCDATA) >
    <!ELEMENT X509SerialNumber (#PCDATA) >
    <!ELEMENT X509Certificate (#PCDATA) >

4.4.5 The PGPData element

Identifier Type="" (this can be used within a RetrievalMethod or Reference element to identify the referent's type) The PGPData element within KeyInfo is used to convey information related to PGP public key pairs and signatures on such keys. The PGPKeyID's value is a string containing a standard PGP public key identifier as defined in [PGP, section 11.2]. The PGPKeyPacket contains a base64-encoded Key Material Packet as defined in [PGP, section 5.5]. Other sub-types of the PGPData element may be defined by the OpenPGP working group. Schema Definition: <element name="PGPData"> <complexType> <choice>
ToP   noToC   RFC3075 - Page 32
         <any namespace="##other" processContents="lax" minOccurs="0"
           <element name="PGPKeyID" type="string"/>
           <element name="PGPKeyPacket" type="ds:CryptoBinary"/>


   <!ELEMENT PGPData (PGPKeyID, PGPKeyPacket)  >
   <!ELEMENT PGPKeyPacket  (#PCDATA)  >

4.4.6 The SPKIData element

Identifier Type="" (this can be used within a RetrievalMethod or Reference element to identify the referent's type) The SPKIData element within KeyInfo is used to convey information related to SPKI public key pairs, certificates and other SPKI data. The content of this element type is expected to be a Canonical S- expression. Schema Definition: <element name="SPKIData" type="string"/> DTD: <!ELEMENT SPKIData (#PCDATA) >

4.4.7 The MgmtData element

Identifier Type="" (this can be used within a RetrievalMethod or Reference element to identify the referent's type) The MgmtData element within KeyInfo is a string value used to convey in-band key distribution or agreement data. For example, DH key exchange, RSA key encryption, etc. Schema Definition:
ToP   noToC   RFC3075 - Page 33
   <!-- type declared in KeyInfo -->

   <!ELEMENT MgmtData (#PCDATA)>

4.5 The Object Element

Identifier Type="" (this can be used within a Reference element to identify the referent's type) Object is an optional element that may occur one or more times. When present, this element may contain any data. The Object element may include optional MIME type, ID, and encoding attributes. The MimeType attribute is an optional attribute which describes the data within the Object. This is a string with values defined by [MIME]. For example, if the Object contains XML, the MimeType could be text/xml. This attribute is purely advisory; no validation of the MimeType information is required by this specification. The Object's Id is commonly referenced from a Reference in SignedInfo, or Manifest. This element is typically used for enveloping signatures where the object being signed is to be included in the signature element. The digest is calculated over the entire Object element including start and end tags. The Object's Encoding attributed may be used to provide a URI that identifies the method by which the object is encoded (e.g., a binary file). Note, if the application wishes to exclude the <Object> tags from the digest calculation the Reference must identify the actual data object (easy for XML documents) or a transform must be used to remove the Object tags (likely where the data object is non-XML). Exclusion of the object tags may be desired for cases where one wants the signature to remain valid if the data object is moved from inside a signature to outside the signature (or vice-versa), or where the content of the Object is an encoding of an original binary document and it is desired to extract and decode so as to sign the original bitwise representation. Schema Definition: <element name="Object"> <complexType mixed="true"> <sequence maxOccurs="unbounded"> <any namespace="##any" processContents="lax"/>
ToP   noToC   RFC3075 - Page 34
       <attribute name="Id" type="ID" use="optional"/>
       <attribute name="MimeType" type="string" use="optional"/>
          <!-- add a grep facet -->
       <attribute name="Encoding" type="uriReference" use="optional"/>

   <!ELEMENT Object %Object.ANY; >
   <!ATTLIST Object
             Id ID  #IMPLIED
             MimeType   CDATA   #IMPLIED
             Encoding   CDATA   #IMPLIED >

5.0 Additional Signature Syntax

This section describes the optional to implement Manifest and SignatureProperties elements and describes the handling of XML processing instructions and comments. With respect to the elements Manifest and SignatureProperties this section specifies syntax and little behavior -- it is left to the application. These elements can appear anywhere the parent's content model permits; the Signature content model only permits them within Object.

5.1 The Manifest Element

Identifier Type="" (this can be used within a Reference element to identify the referent's type) The Manifest element provides a list of References. The difference from the list in SignedInfo is that it is application defined which, if any, of the digests are actually checked against the objects referenced and what to do if the object is inaccessible or the digest compare fails. If a Manifest is pointed to from SignedInfo, the digest over the Manifest itself will be checked by the core signature validation behavior. The digests within such a Manifest are checked at the application's discretion. If a Manifest is referenced from another Manifest, even the overall digest of this two level deep Manifest might not be checked. Schema Definition: <element name="Manifest"> <complexType> <sequence> <element ref="ds:Reference" maxOccurs="unbounded"/>
ToP   noToC   RFC3075 - Page 35
       <attribute name="Id" type="ID" use="optional"/>

   <!ELEMENT Manifest (Reference+)  >
   <!ATTLIST Manifest
             Id ID  #IMPLIED >

5.2 The SignatureProperties Element

Identifier Type="" (this can be used within a Reference element to identify the referent's type) Additional information items concerning the generation of the signature(s) can be placed in a SignatureProperty element (i.e., date/time stamp or the serial number of cryptographic hardware used in signature generation). Schema Definition: <element name="SignatureProperties"> <complexType> <sequence> <element ref="ds:SignatureProperty" maxOccurs="unbounded"/> </sequence> <attribute name="Id" type="ID" use="optional"/> </complexType> </element> <element name="SignatureProperty"> <complexType mixed="true"> <choice minOccurs="0" maxOccurs="unbounded"> <any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </choice> <attribute name="Target" type="uriReference" use="required"/> <attribute name="Id" type="ID" use="optional"/> </complexType> </element> DTD: <!ELEMENT SignatureProperties (SignatureProperty+) > <!ATTLIST SignatureProperties Id ID #IMPLIED >
ToP   noToC   RFC3075 - Page 36
   <!ELEMENT SignatureProperty %SignatureProperty.ANY >
   <!ATTLIST SignatureProperty
             Target CDATA    #REQUIRED
             Id ID  #IMPLIED  >

5.3 Processing Instructions in Signature Elements

No XML processing instructions (PIs) are used by this specification. Note that PIs placed inside SignedInfo by an application will be signed unless the CanonicalizationMethod algorithm discards them. (This is true for any signed XML content.) All of the CanonicalizationMethods specified within this specification retain PIs. When a PI is part of content that is signed (e.g., within SignedInfo or referenced XML documents) any change to the PI will obviously result in a signature failure.

5.4 Comments in Signature Elements

XML comments are not used by this specification. Note that unless CanonicalizationMethod removes comments within SignedInfo or any other referenced XML (which [XML-C14N] does), they will be signed. Consequently, if they are retained, a change to the comment will cause a signature failure. Similarly, the XML signature over any XML data will be sensitive to comment changes unless a comment-ignoring canonicalization/transform method, such as the Canonical XML [XML-C14N], is specified.

6.0 Algorithms

This section identifies algorithms used with the XML digital signature specification. Entries contain the identifier to be used in Signature elements, a reference to the formal specification, and definitions, where applicable, for the representation of keys and the results of cryptographic operations.

6.1 Algorithm Identifiers and Implementation Requirements

Algorithms are identified by URIs that appear as an attribute to the element that identifies the algorithms' role (DigestMethod, Transform, SignatureMethod, or CanonicalizationMethod). All algorithms used herein take parameters but in many cases the parameters are implicit. For example, a SignatureMethod is implicitly given two parameters: the keying info and the output of CanonicalizationMethod. Explicit additional parameters to an algorithm appear as content elements within the algorithm role
ToP   noToC   RFC3075 - Page 37
   element.  Such parameter elements have a descriptive element name,
   which is frequently algorithm specific, and MUST be in the XML
   Signature namespace or an algorithm specific namespace.

   This specification defines a set of algorithms, their URIs, and
   requirements for implementation.  Requirements are specified over
   implementation, not over requirements for signature use.
   Furthermore, the mechanism is extensible, alternative algorithms may
   be used by signature applications.

   (Note that the normative identifier is the complete URI in the table
   though they are sometimes abbreviated in XML syntax (e.g.,

   Algorithm Type
      Algorithm - Requirements - Algorithm URI
      SHA1  - REQUIRED - &dsig;sha1
      base64  - REQUIRED - &dsig;base64
      HMAC-SHA1 - REQUIRED - &dsig;hmac-sha1
      DSAwithSHA1(DSS) - REQUIRED - &dsig;dsa-sha1
      RSAwithSHA1 - RECOMMENDED - &dsig;rsa-sha1
      minimal - RECOMMENDED - &dsig;minimal
      Canonical XML with Comments - RECOMMENDED -
      Canonical XML (omits comments) - REQUIRED -
      XPath - RECOMMENDED -
      Enveloped Signature* - REQUIRED - &dsig;enveloped-signature

   *  The Enveloped Signature transform removes the Signature element
   from the calculation of the signature when the signature is within
   the content that it is being signed.  This MAY be implemented via the
   RECOMMENDED XPath specification specified in 6.6.4: Enveloped
   Signature Transform; it MUST have the same effect as that specified
   by the XPath Transform.
ToP   noToC   RFC3075 - Page 38

6.2 Message Digests

Only one digest algorithm is defined herein. However, it is expected that one or more additional strong digest algorithms will be developed in connection with the US Advanced Encryption Standard effort. Use of MD5 [MD5] is NOT RECOMMENDED because recent advances in cryptography have cast doubt on its strength.

6.2.1 SHA-1

Identifier: The SHA-1 algorithm [SHA-1] takes no explicit parameters. An example of an SHA-1 DigestAlg element is: <DigestMethod Algorithm="&dsig;sha1"/> A SHA-1 digest is a 160-bit string. The content of the DigestValue element shall be the base64 encoding of this bit string viewed as a 20-octet octet stream. For example, the DigestValue element for the message digest: A9993E36 4706816A BA3E2571 7850C26C 9CD0D89D from Appendix A of the SHA-1 standard would be: <DigestValue>qZk+NkcGgWq6PiVxeFDCbJzQ2J0=</DigestValue>

6.3 Message Authentication Codes

MAC algorithms take two implicit parameters, their keying material determined from KeyInfo and the octet stream output by CanonicalizationMethod. MACs and signature algorithms are syntactically identical but a MAC implies a shared secret key.

6.3.1 HMAC

Identifier: The HMAC algorithm (RFC2104 [HMAC]) takes the truncation length in bits as a parameter; if the parameter is not specified then all the bits of the hash are output. An example of an HMAC SignatureMethod element: <SignatureMethod Algorithm="&dsig;hmac-sha1"> <HMACOutputLength>128</HMACOutputLength> </SignatureMethod>
ToP   noToC   RFC3075 - Page 39
   The output of the HMAC algorithm is ultimately the output (possibly
   truncated) of the chosen digest algorithm.  This value shall be
   base64 encoded in the same straightforward fashion as the output of
   the digest algorithms.  Example: the SignatureValue element for the
   HMAC-SHA1 digest

   9294727A 3638BB1C 13F48EF8 158BFC9D

   from the test vectors in [HMAC] would be

   Schema Definition:

   <element name="HMACOutputLength" type="integer"/>

   <!ELEMENT HMACOutputLength (#PCDATA)>

6.4 Signature Algorithms

Signature algorithms take two implicit parameters, their keying material determined from KeyInfo and the octet stream output by CanonicalizationMethod. Signature and MAC algorithms are syntactically identical but a signature implies public key cryptography.

6.4.1 DSA

Identifier: The DSA algorithm [DSS] takes no explicit parameters. An example of a DSA SignatureMethod element is: <SignatureMethod Algorithm="&dsig;dsa"/> The output of the DSA algorithm consists of a pair of integers usually referred by the pair (r, s). The signature value consists of the base64 encoding of the concatenation of two octet-streams that respectively result from the octet-encoding of the values r and s. Integer to octet-stream conversion must be done according to the I2OSP operation defined in the RFC 2437 [PKCS1] specification with a k parameter equal to 20. For example, the SignatureValue element for a DSA signature (r, s) with values specified in hexadecimal: r = 8BAC1AB6 6410435C B7181F95 B16AB97C 92B341C0 s = 41E2345F 1F56DF24 58F426D1 55B4BA2D B6DCD8C8
ToP   noToC   RFC3075 - Page 40
   from the example in Appendix 5 of the DSS standard would be


   DSA key values have the following set of fields: P, Q, G and Y are
   mandatory when appearing as a key value, J, seed and pgenCounter are
   optional but should be present.  (The seed and pgenCounter fields
   must appear together or be absent).  All parameters are encoded as
   base64 [MIME] values.

   <element name="DSAKeyValue">
           <element name="P" type="ds:CryptoBinary"/>
           <element name="Q" type="ds:CryptoBinary"/>
           <element name="G" type="ds:CryptoBinary"/>
           <element name="Y" type="ds:CryptoBinary"/>
           <element name="J" type="ds:CryptoBinary" minOccurs="0"/>
         <sequence minOccurs="0">
           <element name="Seed" type="ds:CryptoBinary"/>
           <element name="PgenCounter" type="ds:CryptoBinary"/>

   <!ELEMENT DSAKeyValue (P, Q, G, Y, J?, (Seed, PgenCounter)?) >
   <!ELEMENT Seed (#PCDATA) >
   <!ELEMENT PgenCounter (#PCDATA) >

6.4.2 PKCS1

Identifier: Arbitrary-length integers (e.g., "bignums" such as RSA modulii) are represented in XML as octet strings. The integer value is first converted to a "big endian" bitstring. The bitstring is then padded
ToP   noToC   RFC3075 - Page 41
   with leading zero bits so that the total number of bits == 0 mod 8
   (so that there are an even number of bytes).  If the bitstring
   contains entire leading bytes that are zero, these are removed (so
   the high-order byte is always non-zero).  This octet string is then
   base64 [MIME] encoded.  (The conversion from integer to octet string
   is equivalent to IEEE 1363's I2OSP [1363] with minimal length).

   The expression "RSA algorithm" as used in this document refers to the
   RSASSA-PKCS1-v1_5 algorithm described in RFC 2437 [PKCS1].  The RSA
   algorithm takes no explicit parameters.  An example of an RSA
   SignatureMethod element is:  <SignatureMethod Algorithm="&dsig;rsa-

   The SignatureValue content for an RSA signature is the base64 [MIME]
   encoding of the octet string computed as per RFC 2437 [PKCS1, section
   8.1.1: Signature generation for the RSASSA-PKCS1-v1_5 signature
   scheme].  As specified in the EMSA-PKCS1-V1_5-ENCODE function RFC
   2437 [PKCS1, section 9.2.1], the value input to the signature
   function MUST contain a pre-pended algorithm object identifier for
   the hash function, but the availability of an ASN.1 parser and
   recognition of OIDs is not required of a signature verifier.  The
   PKCS#1 v1.5 representation appears as:

      CRYPT (PAD (ASN.1 (OID, DIGEST (data))))

   Note that the padded ASN.1 will be of the following form:

      01 | FF* | 00 | prefix | hash

   where "|" is concatentation, "01", "FF", and "00" are fixed octets of
   the corresponding hexadecimal value, "hash" is the SHA1 digest of the
   data, and "prefix" is the ASN.1 BER SHA1 algorithm designator prefix
   required in PKCS1 [RFC 2437], that is,

      hex 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14

   This prefix is included to make it easier to use standard
   cryptographic libraries.  The FF octet MUST be repeated the maximum
   number of times such that the value of the quantity being CRYPTed is
   one octet shorter than the RSA modulus.

   The resulting base64 [MIME] string is the value of the child text
   node of the SignatureValue element, e.g.

ToP   noToC   RFC3075 - Page 42
   RSA key values have two fields Modulus and Exponent





   <element name="RSAKeyValue">
         <element name="Modulus" type="ds:CryptoBinary"/>
         <element name="Exponent" type="ds:CryptoBinary"/>

   <!ELEMENT RSAKeyValue (Modulus, Exponent) >
   <!ELEMENT Modulus (#PCDATA) >
   <!ELEMENT Exponent (#PCDATA) >

6.5 Canonicalization Algorithms

If canonicalization is performed over octets, the canonicalization algorithms take two implicit parameter: the content and its charset. The charset is derived according to the rules of the transport protocols and media types (e.g., RFC2376 [XML-MT] defines the media types for XML). This information is necessary to correctly sign and verify documents and often requires careful server side configuration. Various canonicalization algorithms require conversion to [UTF-8].The two algorithms below understand at least [UTF-8] and [UTF-16] as input encodings. We RECOMMEND that externally specified algorithms do the same. Knowledge of other encodings is OPTIONAL. Various canonicalization algorithms transcode from a non-Unicode encoding to Unicode. The two algorithms below perform text normalization during transcoding [NFC]. We RECOMMEND that externally
ToP   noToC   RFC3075 - Page 43
   specified canonicalization algorithms do the same.  (Note, there can
   be ambiguities in converting existing charsets to Unicode, for an
   example see the XML Japanese Profile [XML-Japanese] NOTE.)

6.5.1 Minimal Canonicalization

Identifier: An example of a minimal canonicalization element is: <CanonicalizationMethod Algorithm="&dsig;minimal"/> The minimal canonicalization algorithm: * converts the character encoding to UTF-8 (without any byte order mark (BOM)). If an encoding is given in the XML declaration, it must be removed. Implementations MUST understand at least [UTF-8] and [UTF-16] as input encodings. Non-Unicode to Unicode transcoding MUST perform text normalization [NFC]. * normalizes line endings as provided by [XML]. (See XML and Canonicalization and Syntactical Considerations (section 7).) This algorithm requires as input the octet stream of the resource to be processed; the algorithm outputs an octet stream. When used to canonicalize SignedInfo the algorithm MUST be provided with the octets that represent the well-formed SignedInfo element (and its children and content) as described in The CanonicalizationMethod Element (section 4.3.1). If the signature application has a node set, then the signature application must convert it into octets as described in The Reference Processing Model (section However, Minimal Canonicalization is NOT RECOMMENDED for processing XPath node-sets, the results of same-document URI references, and the output of other types of XML based transforms. It is only RECOMMENDED for simple character normalization of well formed XML that has no namespace or external entity complications.

6.5.2 Canonical XML

Identifier for REQUIRED Canonical XML (omits comments): Identifier for Canonical XML with Comments: An example of an XML canonicalization element is:
ToP   noToC   RFC3075 - Page 44
   <CanonicalizationMethod Algorithm="

   The normative specification of Canonical XML is [XML-C14N].  The
   algorithm is capable of taking as input either an octet stream or an
   XPath node-set (or sufficiently functional alternative).  The
   algorithm produces an octet stream as output.  Canonical XML is
   easily parameterized (via an additional URI) to omit or retain

(page 44 continued on part 3)

Next Section