W3C home > Mailing lists > Public > public-xmlsec@w3.org > January 2009

XML Signature 1.1 comments

From: Frederick Hirsch <Frederick.Hirsch@nokia.com>
Date: Wed, 14 Jan 2009 01:00:56 -0500
Cc: Frederick Hirsch <Frederick.Hirsch@nokia.com>
Message-Id: <975DCABA-AF1A-4ECF-87E3-CF0155925514@nokia.com>
To: XMLSec WG Public List <public-xmlsec@w3.org>
I have received the following comments on XML Signature 1.1 draft  
(before f2f edits)

regards, Frederick

Frederick Hirsch

3.2.1 Reference Validation

 > Additionally, the SignatureMethod URI may have been altered by the
 > canonicalization of SignedInfo (e.g., absolutization of relative  
 > and it is the canonical form that MUST be used.

I really don't  like "absolutization", normalization is what's  
typically used.

also, "it is the ... that MUST" is awkward (passive).

In the end, I don't think this sentence parses properly.

 > However, the required canonicalization [XML-C14N] of this  
 > does not change URIs.

this doesn't make sense. :) The DSAKeyValue Element
 > Parameter J is available for inclusion solely for efficiency as it is
 > calculatable from P and Q.

calculable Explicit Curve Parameters

 > Structures are defined for three types of characteristic two fields:
 > gaussian normal basis, pentanomial basis and trinomial basis.

Gaussian ?

4.4.4 The X509Data Element

 >   1. At least one element, from the following set of element types;
 > any of these may appear together or more than once iff (if and only  

could you write IFF instead of iff?

 > each instance describes or is related to the same certificate:

6.4.2 RSA (PKCS#1 v1.5)
 >  Canonical XML is easily parameterized (via an additional URI) to  
 > or retain comments.


is actually a word, are you opposed to using it?

6.5.2 Canonical XML 1.1
 > Canonical XML 1.1 is easily parameterized (via an additional URI)  
to omit
 > or retain comments.

6.6.3 XPath Filtering
 > However, this transform MUST produce output in exactly the same  
 > as the XPath transform parameterized by the XPath expression above.

6.6.5 XSLT Transform
 > We RECOMMEND that signature applications create XML content  
 > elements and their descendents/content) in Normalization Form C [NFC,


 > NFC-Corrigendum] and check that any XML being consumed is in that  
 > as well; (if not, signatures may consequently fail to validate).
 > Additionally, none of these algorithms provide data type  
 > Applications that normalize data types in varying formats

 > (e.g., (true, false) or (1,0)) may not be able to validate

nesting parens is confusing....

 > each other's signatures.

i'm not sure.... my personal parser doesn't like it, nor does my  
dictionary, but i don't have a suggestion.

8.2 Check the Security Model
 >    A cryptographical fabricated XML example that includes foreign  

fabricated cryptographical XML example ?

 > and validates under the schema, it also uses schemaLocation to aid
 > automated schema fetching and validation.
Received on Wednesday, 14 January 2009 06:01:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:10 UTC