RE: Additional edits to XML Signature 1.1

For

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

I guess an alternative could be:

"Signatures must ("MUST"?) be deemed invalid when the truncation length is less than the greater of half the underlying hash algorithm's output length or 80 bits."

But that still seems a bit convoluted. Why not just

"Signatures must ("MUST"?) be deemed invalid when the truncation length is less than half the underlying hash algorithm's output length.

(Assuming the use of hash algorithms with output length <160 bits will go away)

-- Magnus

-- Magnus

> -----Original Message-----
> From: public-xmlsec-request@w3.org [mailto:public-xmlsec-
> request@w3.org] On Behalf Of Frederick Hirsch
> Sent: Wednesday, December 30, 2009 4:33 PM
> To: XMLSec WG Public List
> Cc: Frederick Hirsch
> Subject: 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 17:20:46 UTC