Additional edits to XML Signature 1.1

I reviewed XML Signature 1.1 editors draft, and made editorial  
revisions as part of that review. I also have some questions. This  
should complete ACTION-474

Questions:

1.  Section 3.2 Core Signature Validation

[[ Comparison of each value in reference and signature validation is  
over the numeric (e.g., integer) or decoded octet sequence of the  
value. Different implementations may produce different encoded digest  
and signature values when processing the same resources because of  
variances in their encoding, such as accidental white space. But if  
one uses numeric or octet comparison (choose one) on both the stated  
and computed values these problems are eliminated. ]]

Does "choose one" impact interop? Is this an issue for Signature 1.1?

2. HMACOutputLength warning

We added in section 4.4.2

[[Signatures must be deemed invalid if the truncation length is below  
half the underlying hash algorithm's output length, or 80 bits,  
whichever of these two values is greater.]]

it seems it is invalid if (a) truncation length < half output length  
and/or (b) < 80 bits.

Can we remove the phrase ", whichever of these two values is greater."

If not, what does it add beyond conditions (a) and (b)?

3. The document refers to C14N, should it now refer to C14N11 in  
various normative places?

for example, section 4.4.3.2
[If the data object is a node-set and the next transform requires  
octets, the signature application must attempt to convert the node-set  
to an octet stream using Canonical XML [XML-C14N]. ]

and 4.4.3.3
[Dereferencing a same-document reference must result in an XPath node- 
set suitable for use by Canonical XML [XML-C14N]]

no real difference of meaning in the second case, but there might be a  
consistency concern...

4. We might want to reference the historical note in section 4.5.9  
from the KeyValue section, which is earlier, or move it.

http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-DEREncodedKeyValue

5. Note - should  the schema error for RetrievalMethod be fixed in 2.0?

6. Note - MimeType etc for Object element might be an issue for 2.0  
since we do not rely on Transforms for that model?

See discussion

http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-Object

specifically, [[  Applications which require normative type and  
encoding information for signature validation should specify  
Transforms with well defined resulting types and/or encodings. ]]

7 What is a "sufficiently functional alternative"  and why do we  
mention it in Base64 transform section?
Should we remove this phrase?

http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-Base-64

8. Please review the references section.

Editorial changes:

Fix section depths in Algorithm section, updating table of contents etc.
Restore text that was lost from 2nd edition in section on  
canonicalization algorithms.
Review and Fix textual section references, e.g. explicit section  
numbers mentioned in text.
Make RelaxNG reference normative
Fix editorial corrections such as 'a' to 'an' etc
Format element names using <code> formatting, multiple corrections as  
needed
Correct case of referenced elements, also adding formatting.
Fix [URI] link to URI reference
Break long lines in examples, adding note that this was done
Fix URIs to have associated href formatting

Added mention of XML Security 1.1 requirements in design  
considerations section and added reference

I did not review or update the status of the document section, but  
note that the diff from the previous WD will require an update.

I updated the redlines from 2nd edition, and from the pre-ReSpec  
conversion.

regards, Frederick

Frederick Hirsch
Nokia

Received on Thursday, 31 December 2009 00:34:04 UTC