FW: [dss] Requesr for comments: Proposal of message for XMLDSIG

[Gray Steve <steve.gray@upu.int>]

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