W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > October to December 2000

Re: Comments on XML-Signature S&P draft

From: Joseph M. Reagle Jr. <reagle@w3.org>
Date: Mon, 02 Oct 2000 17:38:05 -0400
Message-Id: <4.3.2.7.2.20001002171759.02e06040@rpcp.mit.edu>
To: TAMURA Kent <kent@trl.ibm.co.jp>
Cc: w3c-ietf-xmldsig@w3.org, "Donald Eastlake" <dee3@torque.pothole.com>, <lde008@dma.isg.mot.com>
At 10:26 9/29/2000 +0900, TAMURA Kent wrote:

>Members of my group read the latest Canonical XML [1] and the
>latest XML Signature [2].

Thanks for the comments Kent!

>1.3 Versions, Namespaces and Identifiers
>         XSLT is identified and defined by an external namespace
>                 http://www.w3.org/TR/1999/PR-xslt-19991008
>should be:
>         XSLT is identified and defined by an external URI(?)
>                 http://www.w3.org/TR/1999/REC-xslt-19991116

Yes, URI. Corrected.

>2.2 Extended Example (Object and SignatureProperty)
>o The first paragraph, the second sentence from the botom
>         the SignatureProperty element.
>should be:
>         the <code>SignatureProperty</code> element.

Fixed.

>2.3 Extended Example (Object and Manifest)
>o The last example
>    [m13]     </Reference>
>    [m14] </Object>
>should be:
>    [m13]     </Reference>
>    [m14]   </Manifest>
>    [m15] </Object>

Fixed.

>3.1 and 3.2
>   "The REQUIRED steps" is too strong expression.  The order of
>these steps may be changed.  For example, in 3.2.2,
>"1. Canonicalize..." and "2. Obtain..." are exchangeable.
>3.2.1 Reference Validation
>   Why do we have to canonicalize the SignedInfo before
>processing References?

Both of these are the same issue. As we recommend you see what you sign, and 
the CanonicalizationMethod might tweak the content of SignedInfo, it should 
be processed and then processed. For instance, say at some point the issue 
of releative URIs results in a CanonicalizationMethod that rewrites URIs in 
a novel way, you should apply CanonicalizationMethod first before processing 
them. This text is there to ensure security, though I expect if understood 
by implementors it won't result in a big deal. If they know they only 
support one CanonicalizationMethod, and that Method is safe then they might 
choose not to do this so as to optimize, but that's their choice and the 
spec needs to be clear. There's a parenthetical comment in the latest draft, 
do we need more motivating text?

>4.3.3.1 The URI Attribute
>o the last paragraph
>         S<code>ignatureProperties</code>
>shoud be:
>         <code>SignatureProperties</code>

Fixed.

>4.3.3.2 The Reference Processing Model
>o the first item in the first list after the second paragraph
>         If the data object is a set of octets and ...
>should be:
>         If the data object is an octet stream and ...

Fixed.

>o the first exapmle of URI examples
>         URI="http://example.com/bar.xml"
>                 Identifies the octets that represent the
>                 (unparsed) external XML resource 
> 'http://example.com/bar.xml'.
>The suffix of the URI is ".xml", but signature applications must
>not suppose the URI identifies an XML document and it need not
>see media type of this resource.  So, it should be:
>                 Identifies the octets that represent the
>                 external resource 'http://example.com/bar.xml',
>                 that is probably XML document.

Ok.

>o the third example, URI=""
>   Add a note that comment nodes are omitted.  It is difficult to
>understand whether comment nodes are ommited or not in each
>case....

Ok: Identifies the nodeset (minus any comment nodes) of the XML resource 
containing the signature

>o the fourth example, URI="#chapter1", the second sentence
>         signature applications ...
>should be:
>         Signature applications ...

Fixed.

>4.4 The KeyInfo Element
>o the third paragraph
>         ... by this specification; these can used ...
>should be:
>         ... by this specification; these can be used ...

Fixed.

>4.4.3 The RetrievalMethod Element
>o the second paragraph and Schema/DTD definition
>   The second paragraph says "Type is an optional identifier",
>but the Schema/DTD declare the Type attribute is required.

Ok, as agreed to in [1], type is optional. Fixed.
        <attribute name='Type' type='uriReference' use='optional'/>
...
              Type      CDATA   #IMPLIED >


[1] http://www.w3.org/Signature/Minutes/000907-tele.html

>o DTD
>         <!ATTLIST Type
>should be:
>         <!ATTLIST RetrievalMethod

Fixed.

>4.4.4 The X509Data Element
>   The specification does not describe how to include certificate
>chain though certificate chain is used in the example.  In the
>example, how does a signature application know which certificate
>has a key to verify the signature?

I'll add this to the issues list and defer to Don for its resolution.

__
Joseph Reagle Jr.
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/
Received on Monday, 2 October 2000 17:39:08 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:11 GMT