notes/comments on XML Signature 2.0, 2010 March 4 draft

Hi all,

Reading through the 2010 March 4 draft of XML Signature 2.0, I noted
down some comments, mainly editorial and suggestions for clarification.

As I'm a relative newbie in the group, please forgive my nit-picking
and/or ignorance of previous discussions.

I won't be present in tomorrow's telco (attending a conference), but
will be available for comments/public bashing by email, and in next
week's telco.

best,

Karel Wouters.

-------------------------------------------------------

Section 2.1.1:

s/These section/This section

Reword (attempt)
[s05-08] This identification, along with the transforms, is a
description provided by the signer on how the representation of the
signed data object (i.e. its digest value) has been computed.  The
verifier may obtain the digested content in another method as long as
the digest verifies. In particular, the verifier may obtain the content
from a different location than the one specified in the URI, e.g., from
a local repository

s/is used to identify/are used to identify

Section 2.2:
"Consider the preceding example (in compatibility mode) with an
additional reference to a local Object that includes a SignatureProperty
element. (Such a signature would not only be detached [p02] but
enveloping [p03].)"
-> This is about a signature that contains a reference to an XML
fragment in Object, AND some external resource.
My idea of an enveloped signature was that the envelope contains
everything that is signed. If we extrapolate the reasoning in the text
fragment above, and add another reference to the XML document in which
this signature happens to be included, we get a signature that is
detached AND enveloping AND enveloped.
If nobody sees any problem in that, forget about this comment.

"[p14-21] Signature properties, such as time of signing, can be
optionally signed by identifying them from within a Reference. (These
properties are traditionally called signature "attributes" although that
term has no relationship to the XML term "attribute".)"
-> A (informational) reference to XAdES would be suitable here.

"This is the same example in the 2.0 mode. Only the Reference part is
different."
-> This implies that a mixed mode (some refs in compat mode, some in 2.0
mode) is allowed?? If it is, it might be mentioned explicitly somewhere
in the document.

Section 3.2.1:
s/so that application/so such that the application

Section 3.2.4
s/Signature Validation is 2.0 mode/Signature Validation in 2.0 mode

"except that in this mode KeyInfo cannot have any transforms"
-> suggestion to add some clarification here: I guess this is because of
the use of KeyInfoReference instead of RetrievalMethod. This actually
makes it a bit unclear: I would expect that even in 2.0 mode, it would
be possible to use "compatibility mode" KeyInfo elements,

Section 4:
s/This section provides detailed syntax/This section provides a detailed
syntax

Section 4.1:
"If a value can be of type base64Binary or ds:CryptoBinary they are
defined as base64Binary."
Reworded:
"Note that if a value can be either of type base64Binary or
ds:CryptoBinary, it must be defined as base64Binary"

Section 4.4.1
"In 2.0 mode the SignedInfo element is presented as a single subtree
with no exclusions to the Canonicalization 2.0 algorithm."
-> maybe avoid the word "exclusions" to prevent confusion with EXC-C14N

"2.0 mode uses CanonicalizationMethod in more way - as a
canonicalization for the Reference."
-> I don't understand this sentence. Isn't this the same as in
compatibility mode?

s/We recommend applications/We recommend that applications

Section 4.4.3.2
s/cognizant/aware

Section 4.4.3.3
"Consequently, we RECOMMEND in this case"
"We RECOMMEND support for the same-document"
-> change font/colour for RECOMMEND keyword

s/Same-Document URI-References (section 4.4.3.3)./Same-Document
URI-References (section 4.4.3.4).

Section 4.4.3.7
"modelled as special Transform, so as not to break existing schema."
-> change font/colour of "Transform", or change the word to "transform"
(2 other occurrences in this paragraph)

s/report failure in the fashion that is normal for them./fail gracefully.
(or something else)

Section 4.4.3.8
s/parameters that is expects,/parameters that it expects,

"Type="...xml""
-> this was puzzling when I first read it. Maybe just list all
possibilities here, or add an example? It takes another 24 pages before
the ... is filled in. :-)

s/subtress/subtrees

capitalize "xml"

Section 4.4.3.9
This starts with something like "we're not doing XPath nodesets", and
then defines the concept of subtrees, which are defined using nodes.
Which kind of data model are we dealing with here? DOM, XPath, InfoSet?

Section 4.4.3.10

"The Selection's URI attribute is a a slightly simplified version of the
Reference's URI"
... in compatibility mode

Section 4.4.3.11
"The XPath mentioned in the IncludedXPath and ExcludedXPath are "normal"
XPath"
-> IncludedXPath and ExcludedXPath are note mentioned before. Maybe add
a line before this one, telling the reader the purpose of these elements.

s/book children of root node/book children of the root node

s/It should possible to execute/It should be possible to execute

s/ Streaming XPath implementation by definition/ Streaming XPath
implementations by definition

Section 4.5.2.1
"Parameter J is available for ...."
Font/colour of J, P, Q, G (for consistency); more occurrences of this in
the remainder of the doc.

Section 4.5.2.3.2
The example that is given is one for RFC 4050, and it remains unclear
(from the text) if such a key value can be used in this specification,
and how....
Some more explanation needed here.

Section 4.5.3
s/by adding a specially crafter tranform/by adding a specially crafted
transform

Section 4.5.4
I see some XAdES interference here, and I miss a X509CRLReference
element or something similar.
The CRLs that I know of are rather large (Belgian eID card PKI CRL: >100MB).
Or is the X509CRL element supposed to be a pointer?

Section 4.5.8
"The <xenc:EncryptedKey> and <xenc:DerivedKey> "
Although it's clear what xenc: means, it's not defined in this document

s/In particular, the xenc:DerivedKey> /In particular, the <xenc:DerivedKey>
(maybe it's better to discard the < and >'s in theis paragraph)

Section 4.5.10
"KeyInfoReference uses the same syntax and dereferencing behavior as
Reference's URI (section 4.4.3.1) and the Reference Processing Model
(section 4.4.3.2)"
-> should be 4.4.3.2 ans 4.4.3.3

Section 4.6
s/The Object's Encoding attributed/The Object's Encoding attribute

Section 6.1
"DSAwithSHA1 (signature verification)"
Shouldn't we add here also "use for signature generation is DISCOURAGED"?

Section 6.4.1
"Since XML Signature 1.0 requires .... beyond 2010"
-> it says "this XML Signature 1.1 revision" etcetc. Should be
rephrased, or marked as a citation.
-> REQUIRES: font/colour


Section 6.4.2
In the example of the RSA SignatureMethod element, it would be better to
use SHA-256, as SHA-1 usage is not recommended by this document.

s/RSASSA-PKCS1-v1_5 signature scheme]./RSASSA-PKCS1-v1_5 signature scheme.

"determined by RFC 3447" -> add link

"XML Signature 1.1 must support RSA signature generation and
verification ..."
"XML Signature 1.1 implementations should use at least 2048-bit ..."
-> update to 2.0 ?

Section 6.4.3
"specification with the l parameter"
"l" is marked as an element. Can find it's definition in this document

Section 6.5
s/They are described in section 2.0 Mode Canonicalization
Algorithms/They are described in section 6.8 on 2.0 Mode
Canonicalization Algorithms

"UCS character domain from any encoding that is not UCS-based."
-> add reference to UCS?

s/Canonical XML 1.1 [XML-C14N11]] and /Canonical XML 1.1 [XML-C14N11] and

Section 6.5.1
Something wrong in the font/colour of the example

Section 6.5.3
s/ Canonicalization 1.0 is [XML-EXC-C14N]]./ Canonicalization 1.0 is
[XML-EXC-C14N].
-> add internal reference URI

Section 6.6
"2.0 mode signatures do not use these Transform algorithms. See section."
-> section number missing

Section 6.6.3
s/set defined in [XPATH] a function named here./set defined in [XPATH],
plus a function named here.

Section 6.6.5
"within the stylesheet child of the Transform."
"stylesheet" is marked as an element; should be normal font.

Section 6.7.1
"The parameter EnvelopedSignature may be removed, because in an
enveloped signature, sign an EnvelopedSignature without exluding the
signature itself."
-> I don't understand this sentence

Processing, step 1: "fetch the document and use an xml parser to parse
it into a complete document tree. " -> somewhere earlier in the
document, it was stated that mode 2.0 should allow for streaming.
Doesn't this step prevent streaming? (I must admit that things started
to get vague for me at this point)

s/ the root of subtree/ the root of the subtree

s/set add the current signature/add the current signature

Section 6.7.2
s/The XPath to be include./The XPath to be included.
-> as far as I understand this, the spec permits here to execute XPath
on an octet stream, which is supposed to hold an XML fragment then, I
guess (?)

Section 6.7.3
s/The XPath to be include./The XPath to be included.

Section 6.8
No Algorithm ID for C14N20 yet?

Section 8.1
s/section 3.1.3].) /section 3.1.3.)

Section 9.1
Schema for C14N20 ...

Section A.1
[XML-MEDIA-TYPES] is a normative ref, while it is a W3C note
(don't know if this is a problem, it just caught my eye)

Received on Monday, 31 May 2010 23:38:34 UTC