- 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