The original edition of this specification [XMLDSIG-CORE] referenced the XPointer Candidate Recommendation [XPTR-XPOINTER-CR2001] and some implementations support it optionally. That Candidate Recommendation has been superseded by the [XPTR-FRAMEWORK], [XPTR-XMLNS] and [XPTR-ELEMENT] Recommendations, and — at the time of this edition — the [XPTR-XPOINTER] Working Draft. Therefore, the use of the xpointer() scheme [XPTR-XPOINTER] beyond the usage discussed in this section is discouraged. ‘#xpointer(id(‘ID’))’ MUST be interpreted to identify the element node identified by ‘#element’ [XPTR-ELEMENT] when evaluated with respect to the document that contains the URI attribute. If the URI attribute is omitted altogether, the receiving application is expected to know the identity of the object.
For example, a lightweight data protocol might omit this attribute given the identity of the object is part of the application context. This attribute may be omitted from at most one Reference in any particular SignedInfo, or Manifest. We RECOMMEND XML Signature applications be able to dereference URIs in the HTTP scheme.
The algorithms below understand at least [UTF-8] and [UTF-16] as input encodings. Digest algorithms that are known not to be collision resistant SHOULD NOT be used in DigestMethod elements. For example, the MD5 message digest algorithm SHOULD NOT be used as specific collisions have been demonstrated for that algorithm. While in principle many certificate encodings are possible, it is RECOMMENDED that certificates appearing in an X509Certificate element be limited to an encoding of BER or its DER subset, allowing that within the certificate other content may be present. In any case, XML Signature implementations SHOULD NOT alter or re-encode certificates, as doing so could invalidate their signatures. Such data characteristics are provided as parameters to the Transform algorithm and should be described in the specification for the algorithm.
The XPath expression appearing in the XPath parameter is evaluated once for each node in the input node-set. XML schema validators may not support integer types with decimal data exceeding 18 decimal digits. Convert the elliptic curve point to an octet string by first converting the field elements x and y to octet strings as specified in Section 6.2 of [ECC-ALGS] , and then prepend the concatenated result of the conversion with 0x04. Support for Elliptic-Curve-Point-to-Octet-String conversion without point compression is REQUIRED. Features described in this section are mandatory to implement unless otherwise indicated.
Consequently those excluded portions can change without affecting signature validity. For example, if the resource being signed encloses the signature itself, such a transform must be used to exclude the signature value from its own computation. If no Transforms element is present, the resource’s content is digested directly. While the Working Group has specified mandatory canonicalization and decoding algorithms, user specified transforms are permitted.
