W3C home > Mailing lists > Public > xml-encryption@w3.org > August 2000

RE: encryption in XML & in SMIME

From: Don Davis <dtd@world.std.com>
Date: Wed, 30 Aug 2000 12:05:39 -0500
Message-Id: <l0311070fb5d2d683688d@[208.192.101.88]>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:17 GMT