RE: Re[2]: Omitting Location and Transforms from SignedInfo

Hi John,

> Proposal 2:
> * Transforms are in SignedInfo
> * Location is in SignedInfo
> * view Location only as a hint
> * applications can use non-signature information to find the object and
> transform it into something appropriate to feed into the Transforms
> 
> <John>
> This part I don't like because it means that every signature is
> application-specific and noone can validate anyone else's signatures.
> Everyone needs that application-specific plugin that tells how to
> dereference the Location.  Yuck!
> </John>

I would expect that many (most?) applications will just use Location as
given.  If they are using embedded signatures, they will know how to do
internal references, and if they are signing external resources they will
know http and maybe ftp.  Perhaps you could use "application-specific
plugin" to describe these in this context but I don't see this as an onerous
burden or an interoperability issue.  Those applications that use Location
only as a hint obviously *need* application-specific behaviour.

I could put foo:bar into Location, but of course nobody could understand it
except for the foo application, just as nobody could if I stuck foo:bar as a
link in a web page (unless they had the foo plugin).

Hmm, the other issue you could be referring to is that if the application
just takes Location as a hint and the object does move, we leave it up to
the application to figure out the new location.  I personally don't mind
allowing a second Location element outside of SignedInfo (with an Encoding
attribute but no Transforms) that applications that don't care if the object
has moved can use.  But I also have no problem with leaving it to the
application.

Perhaps I'm not understanding what you are saying?  Could you give examples
of the problems you see?

-Mark Bartel
JetForm Corporation

Received on Thursday, 18 November 1999 10:32:47 UTC