Enumerated XML-Signature Conformance Requirements

Some thoughts [1]. (Basically, let's tighten our definition of a conformant
Signature application and define a conformant signature element as why that
is laxly valid according to the schema). Other thoughts are welcome.

__

[1] http://www.w3.org/Signature/2000/07/27-conformance.html

   Status
          This is a proposed enumeration of the conformance requirements
          specified in
          [3]http://www.w3.org/TR/2000/WD-xmldsig-core-20000711/ with
          suggestions to provide greater organization and clarity that will
          hopefully be reflected back into the next version of the
          specification.
     _________________________________________________________________

      [3] http://www.w3.org/TR/2000/WD-xmldsig-core-20000711/

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

Syntax

   I'm not sure what these MUSTs mean as they are more descriptive than
   prescriptive. (This is also currently being discussed on the list).
     * 7.1 XML 1.0, Syntax Constraints, and Canonicalization
       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:
     * 7.2 DOM/SAX Processing and Canonicalization
       For an XML Signature to be verifiable by an implementation using
       DOM or SAX, not only must the syntax constraints given in
       [4]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.

      [4] http://www.w3.org/Signature/2000/07/27-conformance.html#sec-XML-1

   I believe a single syntax constraint should be stated along the lines
   of:

     a conforming digital signature element is an element that is
     [5]schema-valid-lax [[6]XML-schema] with respect to the XML
     Signature schema.

      [5] http://www.w3.org/TR/2000/WD-xmlschema-1-20000407/#cvc-elt-lax
      [6]
http://www.w3.org/Signature/2000/07/27-conformance.html#ref-XML-schema

   The questions are:
    1. Do we have any other choice? (We could speak of an XML1.0
       Signature document, but this only works with external
       signatures/DTDs).
    2. How much work does this validation entail? We aren't using that
       many schema features, consequently how much work does it take
       relative to a schema validating parser?

  XML Signature Applications

   I suspect some of these could use some tuning.
     * 1.3 Versions, Namespaces and Identifiers
       ...The XML namespace [[7]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
       [8]internal entities [[9]XML] or our "dsig" XML [10]namespace
       prefix and defaulting/scoping conventions are OPTIONAL
     * 2.1 Simple Example (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.
     * 4.3.3 The 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 '[11]bare
       name' [[12]Xptr] shortcut after '#' so as to identify IDs within
       XML documents.
     * 4.4 The 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: [13]KeyValue and
       SHOULD implement Section 4.4.3: [14]RetrievalMethod.
     * 4.4.4 The 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):
     * 6.1 Algorithm Identifiers and Implementation Requirements
       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:
       [15]Enveloped Signature Transform; it MUST have the same effect as
       that specified by the XPath specification.
     * 6.6.4 Enveloped Signature Transform
       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.

      [7] http://www.w3.org/Signature/2000/07/27-conformance.html#ref-XML-ns
      [8] http://www.w3.org/TR/REC-xml#sec-internal-ent
      [9] http://www.w3.org/Signature/2000/07/27-conformance.html#ref-XML
     [10] http://www.w3.org/TR/1999/REC-xml-names-19990114/#dt-prefix
     [11] http://www.w3.org/TR/xptr#bare-names
     [12]
http://www.w3.org/Signature/2000/07/27-conformance.html#ref-XPointer
     [13]
http://www.w3.org/Signature/2000/07/27-conformance.html#sec-KeyValue
     [14]
http://www.w3.org/Signature/2000/07/27-conformance.html#sec-RetrievalMethod
     [15]
http://www.w3.org/Signature/2000/07/27-conformance.html#sec-EnvelopedSignatur
e




_________________________________________________________
Joseph Reagle Jr.   
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/

Received on Tuesday, 25 July 2000 17:25:24 UTC