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).

   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.

      * http://www.w3.org/2000/09/xmldsig#X509Data
      * http://www.w3.org/2000/09/xmldsig#PGPData
      * http://www.w3.org/2000/09/xmldsig#SPKIData
      * http://www.w3.org/2000/09/xmldsig#MgmtData

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

      * http://www.w3.org/2000/09/xmldsig#rawX509Certificate

   Schema Definition:

<element name="KeyInfo">
  <complexType>
    <choice maxOccurs="unbounded">
      <any processContents="lax" namespace="##other" minOccurs="0"
       maxOccurs="unbounded"/>
      <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"/>
    </choice>
    <attribute name="Id" type="ID" use="optional"/>
  </complexType>
</element>
DTD:

<!ELEMENT KeyInfo %Key.ANY; >
<!ATTLIST KeyInfo
          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.)

   Schema Definition:

   <!-- type declared in KeyInfo -->
   DTD:

   <!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 4.3.3.1) and The Reference Processing Model
   (section 4.3.3.2) 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,

   consequently the Signature application is expected to attempt to
   canonicalize the nodeset via the The Reference Processing Model
   (section 4.3.3.2)

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

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

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

4.4.4 The X509Data Element

   Identifier
         Type="http://www.w3.org/2000/09/xmldsig#X509Data"
         (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].

   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

   <KeyInfo>
     <X509Data> <!-- two pointers to certificate-A -->
       <X509IssuerSerial>
         <X509IssuerName>CN=TAMURA Kent, OU=TRL, O=IBM,
           L=Yamato-shi, ST=Kanagawa, C=JP</X509IssuerName>
         <X509SerialNumber>12345678</X509SerialNumber>
       </X509IssuerSerial>
       <X509SKI>31d97bd7</X509SKI>
     </X509Data>
     <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-->
       <X509Certificate>MIICXTCCA..</X509Certificate>
       <!-- Intermediate cert subject CN=arbolCA,OU=FVTO=IBM,C=US
            issuer,CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US -->
       <X509Certificate>MIICPzCCA...</X509Certificate>
       <!-- Root cert subject CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US -->
       <X509Certificate>MIICSTCCA...</X509Certificate>
     </X509Data>
   </KeyInfo>

   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">
       <complexType>
        <choice>
          <sequence maxOccurs="unbounded">
            <choice>
              <element ref="ds:X509IssuerSerial"/>
              <element name="X509SKI" type="ds:CryptoBinary"/>
              <element name="X509SubjectName" type="string"/>

              <element name="X509Certificate" type="ds:CryptoBinary"/>
            </choice>
          </sequence>
          <element name="X509CRL" type="ds:CryptoBinary"/>
        </choice>
      </complexType>
    </element>

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

    DTD

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

4.4.5 The PGPData element

   Identifier
         Type="http://www.w3.org/2000/09/xmldsig#PGPData"
         (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>

         <any namespace="##other" processContents="lax" minOccurs="0"
         maxOccurs="unbounded"/>
         <sequence>
           <element name="PGPKeyID" type="string"/>
           <element name="PGPKeyPacket" type="ds:CryptoBinary"/>
         </sequence>
       </choice>
     </complexType>
   </element>

   DTD:

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

4.4.6 The SPKIData element

   Identifier
         Type="http://www.w3.org/2000/09/xmldsig#SPKIData"
         (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="http://www.w3.org/2000/09/xmldsig#MgmtData"
         (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:

   <!-- type declared in KeyInfo -->
   DTD:

   <!ELEMENT MgmtData (#PCDATA)>

4.5 The Object Element

   Identifier
         Type="http://www.w3.org/2000/09/xmldsig#Object"
         (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"/>

       </sequence>
       <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"/>
     </complexType>
   </element>
   DTD:

   <!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="http://www.w3.org/2000/09/xmldsig#Manifest"
         (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"/>

       </sequence>
       <attribute name="Id" type="ID" use="optional"/>
     </complexType>
   </element>
   DTD:

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

5.2 The SignatureProperties Element

   Identifier
         Type="http://www.w3.org/2000/09/xmldsig#SignatureProperties"
         (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  >

   <!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

   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.,
   "&dsig;base64").)

   Algorithm Type
      Algorithm - Requirements - Algorithm URI
   Digest
      SHA1  - REQUIRED - &dsig;sha1
   Encoding
      base64  - REQUIRED - &dsig;base64
   MAC
      HMAC-SHA1 - REQUIRED - &dsig;hmac-sha1
   Signature
      DSAwithSHA1(DSS) - REQUIRED - &dsig;dsa-sha1
      RSAwithSHA1 - RECOMMENDED - &dsig;rsa-sha1
   Canonicalization
      minimal - RECOMMENDED - &dsig;minimal
      Canonical XML with Comments - RECOMMENDED -
         http://www.w3.org/TR/2000/CR-xml-c14n-20001026#WithComments
      Canonical XML (omits comments) - REQUIRED -
         http://www.w3.org/TR/2000/CR-xml-c14n-20001026
   Transform
      XSLT - OPTIONAL - http://www.w3.org/TR/1999/REC-xslt-19991116
      XPath - RECOMMENDED -
         http://www.w3.org/TR/1999/REC-xpath-19991116
      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.

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:
         http://www.w3.org/2000/09/xmldsig#sha1

   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:
         http://www.w3.org/2000/09/xmldsig#hmac-sha1

   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>

   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

   <SignatureValue>kpRyejY4uxwT9I74FYv8nQ==</SignatureValue>
   Schema Definition:

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

   <!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:
         http://www.w3.org/2000/09/xmldsig#dsa-sha1

   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

   from the example in Appendix 5 of the DSS standard would be

<SignatureValue>
i6watmQQQ1y3GB+VsWq5fJKzQcBB4jRfH1bfJFj0JtFVtLotttzYyA==</SignatureValue>

   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.
   Schema:

   <element name="DSAKeyValue">
     <complexType>
       <sequence>
         <sequence>
           <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>
         <sequence minOccurs="0">
           <element name="Seed" type="ds:CryptoBinary"/>
           <element name="PgenCounter" type="ds:CryptoBinary"/>
         </sequence>
       </sequence>
     </complexType>
   </element>
   DTD:

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

6.4.2 PKCS1

   Identifier:
         http://www.w3.org/2000/09/xmldsig#rsa-sha1

   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

   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-
   sha1"/>

   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.

      <SignatureValue>IWijxQjUrcXBYoCei4QxjWo9Kg8D3p9tlWoT4
      t0/gyTE96639In0FZFY2/rvP+/bMJ01EArmKZsR5VW3rwoPxw=
      </SignatureValue>

   RSA key values have two fields Modulus and Exponent

      <RSAKeyValue>

   <Modulus>xA7SEU+e0yQH5rm9kbCDN9o3aPIo7HbP7tX6WOocLZAtNfyxSZDU16ksL6W

   jubafOqNEpcwR3RdFsT7bCqnXPBe5ELh5u4VEy19MzxkXRgrMvavzyBpVRgBUwUlV
         5foK5hhmbktQhyNdy/6LpQRhDUDsTvK+g9Ucj47es9AQJ3U=
         </Modulus>
         <Exponent>AQAB</Exponent>
      </RSAKeyValue>

   Schema:

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

   <!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

   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:
         http://www.w3.org/2000/09/xmldsig#minimal

   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 4.3.3.2).  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):
         http://www.w3.org/TR/2000/CR-xml-c14n-20001026

   Identifier for Canonical XML with Comments:
         http://www.w3.org/TR/2000/CR-xml-c14n-20001026#WithComments

   An example of an XML canonicalization element is:

   <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2000/CR-xml-
   c14n-20001026"/>

   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
   comments.