Presently, the specification constrains (a) XML Signature Syntax and (b) XML Signature Applications. Most of the MUSTs relate to XML Signature applications. Should we cast all of these constraints as application conformance requirements or syntax requirements? (I don't think the latter is possible and that we should continue to want to use both as discussed below).
I'm not sure what these MUSTs mean as they are more descriptive than prescriptive. (This is also currently being discussed on the list).
Thus, to interoperate between different XML implementations, the
following syntax constraints MUST be observed when generating any signed
material to be processed as XML, including the SignedInfo
element:
For an XML Signature to be verifiable by an implementation using DOM or SAX, not only must the syntax constraints given in section 7.1 be followed but an appropriate XML Canonicalization MUST be specified so that the verifier can re-serialize DOM/SAX mediated input into the same octect stream that was signed.
I believe a single syntax constraint should be stated along the lines of:
a conforming digital signature element is an element that is schema-valid-lax [XML-schema] with respect to the XML Signature schema.
The questions are:
I suspect some of these could use some tuning.
...The XML namespace [XML-ns] URI that MUST be used by implementations of this (dated) specification is: xmlns="http://www.w3.org/2000/07/xmldsig#"
While applications MUST support XML and XML-namespaces, the use of internal entities [XML] or our "dsig" XML namespace prefix and defaulting/scoping conventions are OPTIONAL
Signature, SignedInfo, Methods,
and References)
To promote application interoperability we specify a set of signature algorithms that MUST be implemented, though their use is at the discretion of the signature creator.
Reference Element
XML Signature applications MUST be able to parse URI syntax. We RECOMMEND they be able to dereference URIs and null URIs in the HTTP scheme
XML Signature applications MUST support the XPointer 'bare name' [Xptr] shortcut after '#' so as to identify IDs within XML documents.
KeyInfo
Element
While applications may define and use any mechanism they choose through
inclusion of elements from a different namespace, compliant versions MUST
implement Section 4.4.2: KeyValue
and SHOULD implement Section 4.4.3: RetrievalMethod.
X509Data Element
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 multiple X509Data elements. For example, the
following block contains two pointers to certificate-A (issuer/serial
number & SKI) and a single reference to certificate-B (Subject
Name):
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.
Algorithms: SHA1 Base64, HMAC-SHA1, DSAwithSHA1 (DSS), Canonical XML
The Enveloped Signature transform removes the Signature
element from the calculation of the signature when the signature is within
the document 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 specification.
Note that it is not necessary to use an XPath expression evaluator to create this transform. However, this transform MUST produce output in exactly the same manner as the XPath transform parameterized by the XPath expression above.