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

RE: encryption in XML & in SMIME

From: Ed Simon <ed.simon@entrust.com>
Date: Wed, 30 Aug 2000 09:20:12 -0400
Message-ID: <3120721CA75DD411B8340090273D20B10C1B85@sottmxs06.entrust.com>
To: xml-encryption@w3.org, "'dtd@world.std.com'" <dtd@world.std.com>
Thanks Don,
I think I will put in into the next version of the XML
Encryption proposal.

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:

-----Original Message-----
From: Don Davis [mailto:dtd@world.std.com]
Sent: Tuesday, August 29, 2000 8:56 PM
To: Ed Simon
Cc: xml-encryption@w3.org
Subject: RE: encryption in XML & in SMIME

> Just had a thought as to how one can get the same
> effect of sign/wrap/sign without actually having
> to sign twice.  ... Rather than signing twice,
> two digests [for plaintext and for ciphertext with
> names, respectively] are covered by one signature.

mr. simon,

   i believe it works.  i can't be sure, because
i'm uncertain about the xml-sig syntax.  but the
idea of signing both digests at once is very nice,
and i wish i had thought of it years ago. in fact,
i suggest that you should publish it.

> if this is an XML Signature security issue, then
> it needs to be discussed on the XML Signature list.

   but this isn't an xml-sig security issue at all;
it's a problem that arises only when xml-encryption
is combined with xml-sig.  since the xml-enc standard
will follow the xml-sig standard, it makes sense to
address the issue in the xml-enc draft.  indeed, the
xml-sig draft _cannot_ discuss how signatures should
interact with encryption, since xml-sig can't refer
to a non-existent xml-enc draft.

				- don davis, boston

Received on Wednesday, 30 August 2000 09:27:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:12:58 UTC