Re: Suggested Security Considerations Section

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
explicit
 >filtering and extraction, permit securing only a subset of data in an
object.
 >This is good for many applications where a limited portion of an object
must
 >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
this
 >is done, those aspects that are not signed can be arbitrarily modified and
the
 >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
necessary
 >to secure as exactly as possible the information that was presented to that
 >mechanism or person.  Note that this can be accomplished by literally
signing
 >what was presented, for example the screen images shown a user.  However,
this
 >may result in data which it is difficult for subsequent software to
manipulate.
 >It can be effective instead to secure the full data along with whatever
filters,
 >style sheets, or the like were used to control the part of the information
that
 >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