W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > October to December 2001

Defective Sign-and-Encrypt Article in Nov. 2001 DDJ

From: John Boyer <JBoyer@PureEdge.com>
Date: Tue, 30 Oct 2001 17:00:40 -0800
Message-ID: <7874BFCCD289A645B5CE3935769F0B520C34B5@tigger.PureEdge.com>
To: <editors@ddj.com>
Cc: <ddavis@curl.com>, "XML DSig (E-mail)" <w3c-ietf-xmldsig@w3.org>, <jboyer@acm.org>
Dear DDJ Editors,

As a co-author of the XML Signature specification, which is currently a
W3C proposed recommendation, I was surprised by some of the content of
Mr. Davis' article on defective sign and encrypt.  Overall, I enjoyed
the article, and I agree with his premise that care must be taken in the
sign-and-encrypt scenario to avoid the surreptitious forwarding problem.
However, I think the article is incorrect in its heavy-handed indictment
of the XML Signature specification.  I found several remarks in the
article (e.g. "...they underestimated the subtlety of adding
cryptography...") to be representative of a position of condescension
that is undefensible, in part due to the contradiction that arises when
the article asserts that the problem is not in fact with signatures per
se, but rather "it is the presence of the encrypting envelope that"
causes the problem (p. 30).

Moreover, on a technical level, I disagree with Mr. Davis' assertion
that it is difficult to codify a standard solution to this problem, and
the article would have been improved had he taken more time to consider
what can be done with XML Signature.  To wit, the XML signature
namespace includes an <Object> tag that allows the consumer of XML
Signature technology to add whatever additional information is cogent to
the context.  The <Object> tag is a well-known part of the specification
that appears in its earliest examples.  It is a simple matter to require
(or at least recommend) that signatures created in a sign and encrypt
scenario be created with an <Object> element that contains a <Recipient>
element which, in turn, can contain an encoding of the intended
recipient's public key certificate (thus taking the solution suggested
by Mr. Davis in Example 2a).  Had Mr. Davis ever raised this issue with
the XML Signature working group (which he has not done at the time of
this writing), I for one would have provided the simple solution above,
and I may have even added it to the Signature Scenarios document

To his credit, I notice that Mr. Davis has raised this issue with the
XML encryption group, where the issue properly resides.  Unfortunately,
I do not agree with the group's current decision not to address Mr.
Davis' point, but I am not in the XML encryption working group and am
writing mainly to set the record straight about XML Signature.  The XML
Signature specification is a mature work nearing completion and easily
capable of providing a solution  (given above) for the surreptious
forwarding problem discussed in Mr. Davis' article.

Thank you,
John Boyer, Ph.D.
Senior Product Architect
PureEdge Solutions Inc.
Received on Tuesday, 30 October 2001 20:01:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:36 UTC