Re: Additional edits to XML Signature 1.1

I prefer that simplicity. Do we specify any algorithms with output  
length <= 160 bits, if so maybe we should add a second sentence about  
those.

regards, Frederick

Frederick Hirsch
Nokia



On Dec 31, 2009, at 12:20 PM, ext Magnus Nystrom wrote:

> 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:28:42 UTC