[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: [dss] Requesr for comments: Proposal of message for XMLDSIG
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]