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

Comments on WD-xmldsig-core-19991116

From: Jim Schaad (Exchange) <jimsch@Exchange.Microsoft.com>
Date: Thu, 18 Nov 1999 12:26:11 -0800
Message-ID: <EAB5B8B61A04684198FF1D0C1B3ACD194A7134@dino.dns.microsoft.com>
To: "W3c-Ietf-Xmldsig (E-mail)" <w3c-ietf-xmldsig@w3.org>
1.  Section 1.3 states that the support for XML internal entities is
optional.  If this is true then it cannnot be used in the schema and should
not be used in the final example.  Either that or the support for this
feature needs to be mandated and I don't think that would fly.

2.  Section 2.3, para 3  the word ojbect should change to object.

3.  Section 2.3, para 3.  remove the phrase "this acts as an assertion by
the signer that they are signing...."  This is not correct.  Location is a
hint and the content may or may not currently be at that location.

4.  Section 2.4:  Is there a reason not to just use an attribute rather than
have both package and manifiest.  Using an attribute to say must verify
should be suffient.

5.  Section 2.5:  I don't understand the purpose of Target in
SignatureProperties.  Are you saying that a signature properties element
could be targeted at any item?  I would have thought that it should only be
included in a single signature and that was the binding used.  What is the
reason for this as I don't find anything on the list about it.

6.  Section 3.1:  The archetype end tag has an ' in it.  Please remove

7.  Section 3.1:  Is the default model=closed or model=open?  If it is open
then need to put closed on some of these elements.

8.  Section 3.2:  Schema in the document does not match that of the schema
file.  Do we really want to restrict this to a string.  An alternative
encoding of DSA sigantures could be
<SignatureValue><R>...</R><S>....</S></Signature> and this is prohibitied by
the proposed schema.

9.  Section 3.2: Should the schema be change to be of type='binary'?  This
seems to fit better and we can then do an encoding='base64' to get what you
currently have.

10. Section 3.3.1:  If default is model=closed, then need to put model=open
on this and other similar elements.

11.  Section 3.3.3:  Schema corrections: Remove the minOccurs and maxOccurs
from the first line of the schema.  Change type for 'Type' from string to
uri to match text. Change maxoccurs on transforms from '*' to '1'

12. Section Schema corrections: remove the minOccurs and maxOccurs
from the first line.

13. Section  Please give an example where the use of MimeType or
Charset might be useful so I can understand what you are thinking about.

14.  Section 3.4:  Schema is completely messed up.  I will attempt to change
and post.

15.  Section 3.5:  Remove minOccurs and maxOccurs from the first line on the

16.  Section 4.2:  Schema does not match with the description in 2.5  Which
is the correct structure?

17.  Section 5.1:  I would like to see the signature method for dsa be
dsa-with-sha1 to match the string description on the equivalent OID and to
match the example in section 3.1.  If we are not going to do parametization
of signature algorithms I do not want to see the same string used for both
the Signature and Public Key algorithm names to avoid confusion.  (thus dsa
for the public key name and dsa-with-sha1 for the signature name).

18.  Section 5.2.1:  The text states that the encoding must be base64.  If
so then why have the encoding parameter on the DigestMethod element in the

19.  Seciton 5.4.1: I will be trying to get correct schema for the key value

20.  Section 5.4.2 para 2:  Remove "and urn:rsasdi-com:rsa-md5" from text.

21.  Section 5.5.2  Why is minimal only applicable to XML content.  I would
like this type of algorithm for text files in general as line endings need
to be canonicalized for text on many systems.

22.  Section 6.1 step 2.  Remove the text "(including start and end tags)"
This no longer makes sense as the output of the transforms need not be an
XML document and should be a byte stream suitable for hashing.  (i.e. for
all XML documents the last transform would be a canonicalization of some
type to a byte stream.)

23.  Section 8.0 Corrections to the example at the end:
	a) There is not null transformation to be applied so remove this
	b) There is no encoding element.  Change to Transform (esp true as
this is a decoding not an encoding transform)
	c) Change "CanonicalizationMethod name="..."" to "Transform
Algorithm="..." on timestamp object reference
	d) KeyInfo comes before Object
	e) keyname should be "KeyName" in the key info object
	d) SignatureAttributes object structure is completely incorrect and
does not match anything resembleing our SignatureProperties structure.

Received on Thursday, 18 November 1999 15:27:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:32 UTC