XML Signature 1.1 comments

I have received the following comments on XML Signature 1.1 draft  
(before f2f edits)

regards, Frederick

Frederick Hirsch
Nokia


3.2.1 Reference Validation

 > Additionally, the SignatureMethod URI may have been altered by the
 > canonicalization of SignedInfo (e.g., absolutization of relative  
URIs)
 > 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  
specification
 > does not change URIs.

this doesn't make sense. :)

4.4.2.1 The DSAKeyValue Element
 > Parameter J is available for inclusion solely for efficiency as it is
 > calculatable from P and Q.

calculable

4.4.2.3.1 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  
if)

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  
omit
 > or retain comments.

parametrized

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  
manner
 > as the XPath transform parameterized by the XPath expression above.

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

descendants

 > NFC-Corrigendum] and check that any XML being consumed is in that  
form
 > as well; (if not, signatures may consequently fail to validate).
 > Additionally, none of these algorithms provide data type  
normalization.
 > 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  
content

fabricated cryptographical XML example ?

 > and validates under the schema, it also uses schemaLocation to aid
 > automated schema fetching and validation.