- From: Don Davis <dtd@world.std.com>
- Date: Wed, 30 Aug 2000 12:05:39 -0500
- To: Ed Simon <ed.simon@entrust.com>
- Cc: xml-encryption@w3.org
> I think I will put it into the next version of the XML > Encryption proposal. hi, mr. simon -- please include some description of the security problem that's at issue here. i hope the xml-enc draft will include some urging that every "sign & encrypt" implemen- tation will have to solve this problem somehow. one way to describe the issue is "authenticating the encryptor." a naive sign & encrypt should not be acceptable as compliant, if it doesn't take some steps to authenticate the author of the ciphertext. > Readers of this thread might be interested in a recent > discussion on the XML Signature list about why the > element which contains the signer's identifying info, > <KeyInfo>, is not mandatory and, when it does exist, > is not signed (by default, though it can be). Here's a link: > "http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/0397.html". i don't believe that keyinfo is relevant to this problem, because what the naming fix needs is only a name, not the whole cert or key. an application that wants to sign and encrypt, without including keyinfo in the document, could still include just a name in the document. in sum, there are five possible ways to authenticate the encryptor: * sign/wrap/sign (easy but slow); * signing two digests (intricate but fast and elegant); * include names for signer & decryptor in the document, then sign/encrypt or encrypt/sign; * include signer's name, then encrypt, then sign; * include decryptor's name, then sign, then encrypt. the advantage of the three naming fixes is that they're fairly compatible with conventional (x.509) PKI usage. - don davis, boston -
Received on Wednesday, 30 August 2000 12:09:29 UTC