OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[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

smime.p7s



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]