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

Re: Comments/Questions about the XML-Signature spec

From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
Date: Thu, 10 May 2001 00:00:51 -0400
Message-Id: <200105100400.AAA0000095684@torque.pothole.com>
To: Erwin van der Koogh - Sun Ireland - Software developer <Erwin.Vanderkoogh@sun.com>
cc: w3c-ietf-xmldsig@w3.org, eve.maler@east.sun.com, rags@sun.com

From:  Erwin van der Koogh - Sun Ireland - Software developer <Erwin.Vanderkoogh@sun.
Message-Id:  <200105091650.RAA17488@ireserver.Ireland.Sun.COM>
Date:  Wed, 9 May 2001 17:51:51 +0100 (BST)
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

>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.

The XMLDSIG standard is not about trust. It is about the mechanical
linkage of data to a key. The data may not be a "document" signed by a
"person" in any normal sense. It may be an automatic protocol message
of some sort sent through a channel with an automatically generated
key. What the key means, whether the key is big enough, whether the
algorithm is sound, whether the symmetric or asymmetric or biometric
is appropriate, whether the signature generation and verification
processes are done on hardware with sufficient physical security, what
the signature signifies, etc., are all considerations outside the

>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. 

It is hard (impossible?) to fool proof things because fools are so

>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).

I don't think it is possible to document everything that could be done
or go wrong outside the scope of the standard.

>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.

What kind of KeyID?

>In the DSA example you concatenate r and s.. Why don't you have something like:
>That's what XML is for right? formatting the data so it's easier to parse :)

There doesn't seem to be much advantage in labeling the parts as you
suggest above.

>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 

If you are operating in a closed system, you can define your own
KeyValue element or abuse KeyName to send y or do whatever you
want. If you are not in such a system, you need to send the full key

>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.

I don't remember the details.  I'll try to look it up.

>That's all for now.. if I find some more spare time I'll have another go at the 
>Erwin van der Koogh

Received on Thursday, 10 May 2001 00:01:41 UTC

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