FW: transforms, XMLDSIG, and presentation(was [dss] Requesr for comments: Proposal of message for XMLDSIG)

["jmessing" <jmessing@law-on-line.com>]

There was discussion on the call yesterday about XMLDSIG, transforms, and potential weaknesses in "seeing what you sign" or verifying according to what was signed. The Oasis DSS TC has asked XMLDSIG for an opinion. This is the very latest in exchanges about transforms that do not exactly fall within the CN14 cannonicalization rules of XMLDSIG but generate HTML for the final version (in our terms, the contract that is actually signed). This raises the possibility of out-of-cannonicalization transforms that normalize characters. 

It is rather technical, and is only submitted for clarification of a side issue that was raised between John McClure and myself. I took the position that XMLDSIG's methodology allows for presentation issues to remain out of scope for the standard by relying on this and related technologies for developers to use or assume. John McClure countered that there were flaws that were being explored by Joseph Reagle and others. I think this communication may put the matters to rest (or not) for those who are interested in this subdiscussion. Best regards.

---------- Original Message ----------------------------------
From: Gray Steve <steve.gray@upu.int>
Date:  Thu, 24 Apr 2003 17:23:51 +0200



Juan is right,

   This should be referred to XMLDSIG, where it is already being addressed.
I have included the relevant sections below.

Ed

8.1.2 Only What is "Seen" Should be Signed
Additionally, the signature secures any information introduced by the
transform: only what is "seen" should be signed. If signing is intended to
convey the judgment or consent of an automated mechanism or person, then it
is normally necessary to secure as exactly as practical the information that
was presented to that mechanism or person. Note that this can be
accomplished by literally signing what was presented, such as the screen
images shown a user. However, this may result in data which is difficult for
subsequent software to manipulate. Instead, one can sign the data along with
whatever filters, style sheets, client profile or other information that
affects its presentation.

8.1.3 "See" What is Signed
Note: This new recommendation is actually a combination/inverse of the
earlier recommendations and is still under discussion.

Just as a person or automatable mechanism should only sign what it "sees,"
persons and automated mechanisms that trust the validity of a transformed
document on the basis of a valid signature SHOULD operate over the data that
was transformed (including canonicalization) and signed, not the original
pre-transformed data. Some applications might operate over the original or
intermediary data but SHOULD be extremely careful about potential weaknesses
introduced between the original and transformed data. This is a trust
decision about the character and meaning of the transforms that an
application needs to make with caution. Consider a canonicalization
algorithm that normalizes character case (lower to upper) or character
composition ('e and accent' to 'accented-e'). An adversary could introduce
changes that are normalized and consequently inconsequential to signature
validity but material to a DOM processor. For instance, by changing the case
of a character one might influence the result of an XPath selection. A
serious risk is introduced if that change is normalized for signature
validation but the processor operates over the original data and returns a
different result than intended.

Consequently, while we RECOMMEND all documents operated upon and generated
by signature applications be in [NFC] (otherwise intermediate processors
might unintentionally break the signature) encoding normalizations SHOULD
NOT be done as part of a signature transform, or (to state it another way)
if normalization does occur, the application SHOULD always "see" (operate
over) the normalized form.
 

Regards


Steve Gray & Ed Shallow


-----Original Message-----
From: Gray Steve [mailto:steve.gray@upu.int] 
Sent: April 24, 2003 6:14 AM
To: Ed Shallow (E-mail)

Hi Ed

Perhaps you could comment on this?

Also note, I have added you to the OASIS list as a member of the UPU. Let me
know if you start receiving all the emails that are sent to the discussion
list.


Steve

-----Original Message-----
From: Juan Carlos Cruellas [mailto:cruellas@ac.upc.es]
Sent: Monday, April 07, 2003 7:28 PM
To: dss@lists.oasis-open.org
Subject: [dss] Requesr for comments: Proposal of message for XMLDSIG


Dear all,

Could you comment on the text that follows below?.
It is my initial proposal of the message that our TC will address to the
XMLDSIG group.

Regards and thanks

Juan Carlos.


---------------------------------

Dear all,

Within the OASIS Digital Signature Services Technical Committee, that is
currently working in the specification of Web Services for producing and
veriffying digital signatures, the issue of dealing with the requirement of
What You See is What You Sign has been raised by some members. It deals with
the signature of the result of applying transformation(s) to the original
XML data to convert it in a more human readable form (let us say HTML) as
there seem to be situations where this readability requirement is present.
This issue is in consequence related NOT with c1n4 canonicalization but with
additional transformations that, as I mentioned before, transforms the
original XML data in a different document perhaps in a different format...
The aforementioned TC  would like to know if the XMLDSIG group has
identified this as an issue and in such case if you have came up to any
conclusions about how it could be managed. If not, the TC would like to get
your advice in order to address a suitable forum where to address.

Best regards

Juan Carlos Cruellas
Co-chair of the OASIS DSS TC