Nick & Trevor,
-----Original Message-----
From: Nick Pope [mailto:po...@secstan.com]
Sent: Tuesday, March 25, 2003 8:49 PM
To: Gregor Karlinger; robe...@entrust.com; tre...@trevp.net
Cc: ML OASIS DSS
Subject: RE: [dss] Groups - dss-requirements-1.0-draft-02.doc uploaded
Gregor,
My understanding that the particular feature which the first
part of you message brings out is that: "style-sheets and
other information needed to identify the specifics of a
transform that may be applied to signed data needs to be
included in the the manifest. This is particularly important
where the the user requiring the signature views the
transformed data."
This definition bears to flaws:
1. Transforms are not applied to signed data, but to the transforms
process input data" (i.e. the data referred to by the URI
attribute of dsig:Reference).
2. The relying party will *always* view the transforms process out-
put data, since this is what is actually signed by the dsig
signature.
I suggest therefore the following definition:
"For use cases where the relying party would like to check the
relationship between the the 'transforms process input data'
(which is the data he wants to operate on) and the 'transforms
process output data' (which is the data the signing party has
actually signed) all the information used by the signing party
to compute the transforms process must be signed.
Most of this information is included in a XMLDSIG signature
anyway. However, there are some exceptions, for instance imported
stylesheets referred to in an XSLT transform. Those additional
information must be signed as well, for instance as part of a
dsig:Manifest."
Is this OK? Do you want the original use case document
updating to only keep the details relating to the Securing
Transform use case?
Yes, the use case document should contain only the Securing
transform use case. The requirements should be coved by the
req document.
/Gregor
63 messages in org.oasis-open.lists.dssRE: [dss] Groups - dss-requirements-1...
.bin