- From: Erwin van der Koogh - Sun Ireland - Software developer <Erwin.Vanderkoogh@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. 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 UTC