W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 2001

Comments/Questions about the XML-Signature spec

From: Erwin van der Koogh - Sun Ireland - Software developer <Erwin.Vanderkoogh@sun.com>
Date: Wed, 9 May 2001 17:51:51 +0100 (BST)
Message-Id: <200105091650.RAA17488@ireserver.Ireland.Sun.COM>
To: dee3@torque.pothole.com, reagle@w3.org, dsolo@alum.mit.edu
Cc: w3c-ietf-xmldsig@w3.org, eve.maler@east.sun.com, rags@sun.com
Hello,

I am sorry for being so late with my comments/questions, but I have only 
recently joined Sun's XML devision so I haven't had an awful lot of time to look 
it over.

First of all about the KeyInfo stuff:

I think it should be stressed extremely obviously multiple times all over the 
spec that you still need to verify the key supplied in the KeyInfo. By checking 
whether the key is from the person who supposedly signed the document and by 
verifying and trusting one or more signatures on the key.

I know it's in the spec itself, but I have been writing crypto libraries for 
years now and you'll be amazed how people can forget little things like that. 
This morning I had to explain the difference between encryption and Base64 
encoding to someone. And because this is an area that can't be covered by a 
library (It's a trust decision and can at best be made by an application 
programmer (and at worst by a user) this has to be crystal clear and leave no 
room for intrepetation).

The same thing is true for RetrievalMethod.

I don't see any need for anything but a KeyID and/or RetrievalMethod in the 
signature, but I guess the spec is too close to being final for that to be 
thrown out.

In the DSA example you concatenate r and s.. Why don't you have something like:
<SignatureValue><DSA><R>alsdkfjalsdjfasf</R><S>asldkjfalskdfjd</S></DSA></Signat
ureValue>
That's what XML is for right? formatting the data so it's easier to parse :)

Last comment for now:
In 6.4.1 DSA you specify that p, g, q, y are to be mandatory in the DSAKey.
And that J, seed, and pgenCounter are optional?

First it's possible to have systemwide p, g, and q and have only y be the public 
key. So you don't have to repeat p, g and q in all communications and force 
people to use certain values (because these parameters should be choosen very 
carefully because of weak values it's debatable that this is actually a good 
feature).

Now there's no reference to what J, seed and pgenCounter are exactly.
I don't know what they are but because of "seed" I think this might have 
something to do with the seed of a PRNG?
If this is the case then these optional elements tell way more than just the 
DSAKey and should therefor not be used.

That's all for now.. if I find some more spare time I'll have another go at the 
spec.

Regards,

Erwin van der Koogh
Received on Wednesday, 9 May 2001 20:29:23 GMT

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