XML-Signature WG Last Call Comments [ ascii]

Related:

• Juha Pääjärvi: Last Call Comment: Canonicalization

Possible Resolution:

1. Wrap a fragment in an element.

• move SignatureProperty namespace to SignatureProperties.

Possible Resolutions: Do we clarify that KeyValue is a hint? Reiterate difference between signature and trust validation?

1. KeyInfo and KeyValue: Clarify: There is no requirement that the verifying implementation use the specific information contained within KeyInfo in the actual signature validation, although (as in CMS) we expect that for efficiency reasons implementations will likely try the included key information first before hitting a database to look for other potential keys to use to validate the signature.
2. RE: KeyInfo and KeyValue . Fox: Do you (Carl) have a suggested alternative for KeyValue that is semantically neutral?  I agree that we need some explanatory text on DSA parameters, but the parameters cannot be omitted from KeyValue for cryptographic reasons discussed previously. There is no scenario using KeyValue in which the parameters can be left out.

• I think no one implements exact order. I may request for Xalan/LotusXSL team to make output of XPath lex-order.
• Also : Minimal Canonicalization should be removed with the same reason.  Simon: "... requiring minimal canonicalization is a real pain not because minimal canonicalization is hard to implement, but because by making support for minimal canonicalization REQUIRED, it means that an implementor cannot use XML parsing to parse SignedInfo when verifying a Signature."

Also, minimal is no longer required, but optional.

1. the XPath element does not appear to be in the DTD. An example would be useful.
2. Without a context node, the XPath cannot be applied against an XML tree.
3. It appears quite easy in this syntax (being XML) to allow the user to declare namespaces for use within XPaths. XSLT and XLink both provide this capability. Using namespace-uri() and local-name() hinders readability and impacts performance significantly.
4. ...

Possible Resolution:

• Boyer's 000406 Version .

URIs: For URIs and URI references, add a convention as in http://www.w3.org/TR/charmod/#URIs. (all W3C specs that use URIs in XML are doing this)

• When obtaining a resource (via <Reference>), the resource is supposed to come with its own Type/Charset information. If this is not the case, then all kinds of operations just cannot be performed. This information is certainly available in http, and the 'charset' (encoding) information is available for XML even on protocols that do not provide meta-information. This raises the question of priority.
• The charset information provided as explained above may in some cases be absent (e.g. in many cases for HTML over http), and in some cases may be wrong. This MUST NOT provide a reason for XMLSig to make the attributes on <Transform> have higher priority than the information provided in the protocol or in the resource itself. Otherwise, this would deteriorate efforts to make absolutely sure this information is present and available.
• Content negotiation is an additional reason for why the 'charset' information should be taken from the resource/protocol itself, rather than from the
• In any case, the priority of the various information sources has to be clearly specified. It may also be possible to say that an error occurs if the informations don't match.
• Type and charset seem to be on Transform because it is unclear how this information would get from one transform to the other. Because this information has to get from the original resource to the first Transform, a processing model that doesn't allow passing such information from one Transform to another even if needed seems inappropriate. [the spec currently doesn't say what the processing model for the sequence of transforms is; making this clear would help us a lot to check whether it is appropriate for i18n or not [describing a processing model in the spec does not mean that all implementations have to follow it; it's okay if they do something else provided they produce the same results]] This should be changed so that these parameters are eliminated on <Transform>, and the necessary information is passed from transform to transform automatically. The parameters may then be moved to <Reference>.
• Some transforms may need other parameters, while many transforms won't need Type or charset. At the moment, for example, there seems to be no proposed transform that would need MimeType. Also, the result of most transforms is of a very well defined type and in many cases also of a defined 'charset', and having to add this information on the next transform is error-prone. If the parameters are kept on Transform, it should be stated clearly that each transform definition has to define whether they are actually used, and (in particular for MimeType) for what.
• We also discussed the question of whether it would be better to have both Type and charset in a single attribute, but we didn't reach a conclusion.

• 'minimal' canonicalization is required, but it should be made very clear that this does not imply that conversion from all 'charset's to UTF-8 is required. A set of 'charset's for which support is required should be defined exactly, e.g. as UTF-8 and UTF-16. This is the same for other transforms.
• There should be a clear and strong warning and an official non-guarantee in the spec about conversions from legacy 'charset's (i.e. encodings not based on the UCS) into encodings based on the UCS (i.e. UTF-8, UTF-16,...). The problem is that while for most 'charset's, all transcoder implementations produce the same result for almost all characters in these 'charset's, the number of 'charset's where all transcoding implementations behave exactly the same is rather limited. As an example, in "Shift_JIS", the 'charset' used on Japanese PCs, about 10 to 15 special characters are transcoded differently on Windows, on the Mac, and by Java.
• Part of the above warning should be to recommend UTF-8 and UTF-16 to be used for the original documents, and to recommend to use numeric character references (e.g. &#xABCD;) for cases where differences are known.
• We discussed the idea of having a transform that just does transcoding. This would allow to separate various issues clearly.

• Both Base64 and Quoted-Printable are provided as encoding transforms. For Quoted-Printable, the only reason given is "Quoted-printable is provided, in addition to base-64, in keeping with the XML support of a roughly human readable final format.". We have serious doubts that this is really useful in the context at hand; if several transform steps are used, it should be enough that the data before applying base64 is readable, and in all the examples given, base64 is only applied to calculated numbers/hex sequences, which are not very readable either way. So we request to remove Quoted-Printable.

• XPath transform [Please note: there has already been discussion on the list about this with the XSL WG. The comments below are included to make sure they can be formally answered.]
• The XMLSig draft contains some provisions to deal with the fact that input and output infrastructure (e.g. the equivalent of http://www.w3.org/TR/xslt#output) is missing in XPath. In particular, the evaluation context includes two variables: $exprEncoding: a string containing the character encoding of the XPath expression $exprBOM: a string containing the byte order mark for the XPath expression; set to the empty string if the document containing the XPath expression has no byte order mark. and makes these available to the XPath expression. The spec also says: "The XPath implementation is expected to convert all strings appearing in the XPath expression to the same encoding used by the input string prior to making any comparisons."
• This should be changed so that: - The spec clearly says that all XPath operations have to work as if they were implemented in UCS (to conform to http://www.w3.org/TR/xpath#strings). Conversion from the input encoding of the XPath expression and from the input encoding of the actual object are assumed to occur implicitly. This would also resolve the question of what lexicographic ordering to use in the output. - The encoding of the output be clearly specified as one of the following: - always, or by default, UTF-8 - always, or by default, the encoding of the input object - specifiable as a parameter to the 'serialize()' function. (We would prefer always UTF-8; this reduces implementation effort) - The above variables be scrapped. While the information is relevant to the XPath engine, it is in no way relevant to the XPath expression. 

• Make sure that the transforms defined do not *require* NFC. (any XML processor, and any transforms based on it, are always *allowed* to to do normalization, see the definition of 'match' in the XML spec).

• Provide a transform that *checks* for NFC. The transform fails if the input is not in NFC. If the transform succeds, the output is exactly the same as the input. [this is a bit different from the average transform, but fits very well into the general model].

• Advise users (and provide examples) to use this transform after e.g. Canonical XML, to avoid missing interactions between numeric character references and NFC.

• Advise users to provide their data in NFC (just to reinforce the general recommendation), and stress the importance of this in the context of digital signatures. - Provide a transform that actually does NFC, for cases where this is desirable, but add the necessary warnings.

It is not clear what "signature application" means. If this means an application that produces signatures, we do not understand the sentence in the last paragraph of 7.0 which recommends that such applications produce normalized XML. *** It has to be cristal-clear that no actual normalization should occur in connection with any signing calculation. The current text is not clear enough.

Also proposed to be added to 6.5 of Signature:

When a document is transcoded from a non-Unicode encoding to Unicode as part of C14N, normalization SHOULD be performed

accepted ( with suggested tweaks)

Proposed: 4.3.3 The Reference Element

... The set of characters for URIs is the same as for XML, namely [Unicode]. However, some Unicode characters are disallowed from URI references: all non-ASCII characters and the excluded characters listed in Section 2.4 of [IETF RFC 2396], excluding the number sign (#) and the percent sign (%); and excluding the square bracket characters re-allowed in [IETF RFC 2732]. Disallowed characters must be escaped as described in section 4.1.1 URI Reference Encoding and Escaping of [XPtr]:

1. Each disallowed character is converted to UTF-8 [IETF RFC 2279] as one or more bytes.
2. Any octets corresponding to a disallowed character are escaped with the URI escaping mechanism (that is, converted to %HH, where HH is the hexadecimal notation of the byte value).
3. The original character is replaced by the resulting character sequence.

4.3.3 The Reference Element

...Applications should be cognizant of the fact that protocol parameter and state information, (such as a HTTP cookies, HTML device profiles or content negotiation), may affect the content yielded by dereferencing a URI.

If there a resource is identified by more than one URI, the most specific should be used (e.g. .../interop-pressrelease.html.en instead of .../interop-pressrelease).

"IANA registered 'character set'"

4.3.3.1 The Transforms Element

.. Some Transform may require explicit MimeType, Charset (IANA registered "character set"), or other such information concerning the data they are receiving from an earlier Transform or the source data, although no Transform algorithm specified in this document needs such explicit information. Such data characteristics are provided as parameters to the Transform algorithm and should be described in the specification for the algorithm.

4.5 The Object Element

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

Canonicalization algorithms takes two implicit parameter when they appear as a CanonicalizationMethod within the SignedInfo element: the content and its charset. (Note, there may be ambiguities in converting existing charsets to Unicode, for an example see the XML Japanese Profile [XML-Japanese] NOTE.) The charset is derived according to the rules of the transport protocols and media formats (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]. Where any such algorithm is REQUIRED or RECOMMENDED the algorithm MUST understand at least [UTF-8] and [UTF-16] as input encodings. Knowledge of other encodings is OPTIONAL. Transcodings from a non-Unicode encoding to Unicode as part of canonicalization SHOULD be performed

"All entity references (except "amp", "lt", "gt", "apos",
"quot", and other character entities not representable in the encoding chosen) are expanded and non-representable characters are replaced by
their numeric character reference."

4.4.4 The X509Data Element The specification does not describe how to include certificate chain though certificate chain is used in the example. In the example, how does a signature application know which certificate has a key to verify the signature? )

Gindin: The effective rule is that any certificate whose subject name matches the issuer name of any of the other certificates included is a CA from one of the included chains, and thus signature verification should only run on the remaining certificates.

Gindin: However, RFC 2459 section 3.2 contains the following: "In general, a chain of multiple certificates >may be needed, comprising a certificate of the public key owner (the end >entity) signed by one CA, and zero or more additional certificates of CAs >signed by other CAs." ...

1. In section 6.4.2, change "IEEE P1363" to "IEEE 1363", the specification achieved release status on August 25th 2000 and hence the 'P' was dropped.
2. Should signatures with partial message recovery be noted somewhere?
3. Do we need a footnote for SHA-2?

1. fixed .
2. please make a case for it being noted.
3. we allow arbitrary algorithms to be specified, many algorithms that can be used are not footnoted.