Re: Comments/Questions about the XML-Signature spec

Hi,

On the DSA Key Value item, maybe I'm missing something but I don't
know what J, seed, and pgenCounter are about. So I agree with you
that, as far as I can see, they should be dropped. And it would be
reasonable for P, G, and Q to be optional.

On the other topics you bring up, there does not seem to be any
support for broadening the areas covered in the specifciation or
reducing the types inside KeyInfo, judging from the lack of email. So
we will consider those resolved to leave things as they are.

Thanks,
Donald

From:  "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
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
In-reply-to:  Your message of "Wed, 09 May 2001 17:51:51 BST."
	                  <200105091650.RAA17488@ireserver.Ireland.Sun.COM> 
Date:  Thu, 10 May 2001 00:00:51 -0400

>From:  Erwin van der Koogh - Sun Ireland - Software developer <Erwin.Vanderkoogh@sun.
>com>
>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
>
>>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.
>
>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
>spec.
>
>>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
>ingenious.
>
>>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:
>><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 :)
>
>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 
>>feature).
>
>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
>value.
>
>>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 
>>spec.
>>
>>Regards,
>>
>>Erwin van der Koogh
>
>Donald
>

Received on Wednesday, 23 May 2001 16:55:45 UTC