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

Re: Suggested Security Considerations Section

From: <dee3@us.ibm.com>
Date: Wed, 13 Oct 1999 16:35:39 -0400
To: w3c-ietf-xmldsig@w3.org
Message-ID: <85256809.00714032.00@D51MTA10.pok.ibm.com>
See at @@@

Donald E. Eastlake, 3rd
17 Skyline Drive, Hawthorne, NY 10532 USA
dee3@us.ibm.com   tel: 1-914-784-7913, fax: 1-914-784-3833

home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
dee3@torque.pothole.com   tel: 1-914-276-2668

"Joseph M. Reagle Jr." <reagle@w3.org> on 10/13/99 03:52:36 PM

To:   Donald Eastlake/Hawthorne/IBM@IBMUS
cc:   w3c-ietf-xmldsig@w3.org
Subject:  Re: Suggested Security Considerations Section

At 23:47 99/10/12 -0400, dee3@us.ibm.com wrote:
 >Only What is Signed is Secure
 >The flexible Transformations mechanism, including canonicalization and
 >filtering and extraction, permit securing only a subset of data in an
 >This is good for many applications where a limited portion of an object
 >change after the signature or different signatures secure different parts
or the
 >application modifies aspects of the object that are not significant and
can be
 >omitted from signature coverage or the like.   Keep in mind that whenever
 >is done, those aspects that are not signed can be arbitrarily modified and
 >signature will still validate.

Given this section is called "transformations" for good reason, I'm
concerned about the reliance upon "subset of data". How about something like:

The Transformations mechanism permits the signer to transform a source
document into a derived document. Two obvious purposes for this feature is
to canonicalize a document, or perform filtering and extraction such that
the application derives and signs only a subset of the source content.
Consequently, those portions of the source document that are not reflected
in the derived document can be arbitrarily modified and the signature will
still validate.

@@@ While there is nothing particularly wrong with your wording, you have lost
the material as to why one might be motivated to sign a subset of the data.  Is
that deliberate?

 >Only What is "Seen" Should be Signed
 >If signing is intended to convey the judgment or consent of an automated
 >mechanism or person concerning some information, then it is normally
 >to secure as exactly as possible the information that was presented to that
 >mechanism or person.  Note that this can be accomplished by literally
 >what was presented, for example the screen images shown a user.  However,
 >may result in data which it is difficult for subsequent software to
 >It can be effective instead to secure the full data along with whatever
 >style sheets, or the like were used to control the part of the information
 >was presented.

I think I prefer the following <smile>

Applications are recommended to ensure signers understand the actual
resulting content that is being signed after transformations are applied.
Users should not be tricked into signing a native content that is
transformed into something that the user would not have signed otherwise.
This recommendation applied to transformations specified in the signature
block, as well as transformations found within the document itself.

@@@ The first sentence wrongly implies that it is the transform output that is
being digitally signed when it is the original data and the transforms together
that are being signed.  This is a confusion between digital signing mechanism
and some conception of human consent.

@@@ The whole thing is way too document and human being oriented to my mind.
What does "understand" mean?  How can you ever tell if a person "understands"
something without telepathy?  The sentence "Users should not be tricked into
signing a native content that is
transformed into something that the user would not have signed otherwise." seems
very confusing to me, contradicts the wrong first sentence by talking about
signing "native" (i.e. original???) content.

@@@ The user only ever signs the output of the transformations, that's all they
see.  So I don't understand this stuff about them signing the result of
transformations into something they "would not have signed".  Furthermore, it's
really not about tricking the user, it's about implemention bugs or
implementation maliciousness.  The user only ever signs what they see, it is up
to faithful software to record that fact.  The admonition is against improperly
designed or unfaithful software that incorrectly records the users signature.
Little of this applies to protocol signatures as it is so obvious that the
integrity of the whole parsing, transformation, programatic decision making,
signing, etc., behaviour of the software as a whole is what is at issue.  As for
the final sentence, I think it is confusing in this document to call things like
internally referenced style sheets in a document "transformations".  We should
reserve that word in this document for our Transformations element.  And I think
it is mystifying not to give any example of something in a document, like a
style sheet, which effects what the user sees.  Some people might see the kind
of thing you are talking about right away and others might not have a clue what
you mean by transformations in a document.

@@@ My wording is not all that great, but I think it is better.  I cover such
cases as a signature added whose sole purpose is to time stamp.  In such a
signature, it is utterly immaterial what, if any, part of the data was
understood.  We are not yet at the stage of defining semantic tags where you can
tell such things, but I assume we or someone else in the future will.  But the
wording you propose only makes sense if you assume certain siganture semantics.

@@@ Donald
Joseph Reagle Jr.
Policy Analyst           mailto:reagle@w3.org
XML-Signature Co-Chair   http://w3.org/People/Reagle/
Received on Wednesday, 13 October 1999 16:37:31 UTC

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