[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Groups - dss-requirements-1.0-draft-02.doc uploaded
Trevor, > -----Original Message----- > From: Trevor Perrin [mailto:trevp@trevp.net] > Sent: Tuesday, March 25, 2003 9:42 PM > To: Nick Pope; dss@lists.oasis-open.org > Subject: RE: [dss] Groups - dss-requirements-1.0-draft-02.doc uploaded > > > > At 12:37 PM 3/25/2003 -0800, Trevor Perrin wrote: > > >Right, but then I think you need to sign both the XML *and* the > >transformed, human-readable form. > > For example, an XML-DSIG could have 2 references, both to the same > document, one of which applies a transform to make it > human-readable, the > other of which doesn't. You could sign the XML (the "transforms process input data (TPID)") as well, but it is not necessary in my use case since the relying party knows the TPID and wants to check if feeding the TPID into the transforms process leeds to the actually singned data. > So the transforms (in this and other cases) still might need to be > protected. But that raises another question about this use > case - is the > best way to do this by putting the transforms in a > ds:Manifiest? I would > say it's better to include them as a signed attribute, so > you're guaranteed > that they're verified by a relying party. I agree with you. Putting the additional transforms parameter into a dsig:Manifest is not the best way. A solution would be for instance to put it into a dsig:Manifest, but assign a special value for the Type attribute of the manifest. /Gregor
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]