RE: Locations but not Transforms as hints (was RE: The XML-DSig N on-standard, or Location/Transforms as 'hints')

Hi John,

Comments embedded...

> I think perhaps that I have misunderstood what people have 
> been meaning
> by
> "location as hint".  To me it means that the application can choose to
> ignore the signed location and locate the object by other 
> means.  Other
> means may be an unsigned location elsewhere in the signature that we
> specify
> in the standard.  Or, the application can ignore both the signed
> location
> and the standard unsigned location and do something else.  Or, the
> application can decide that since it can't verify the signed location
> and is
> not willing to trust the unsigned location, it will not verify the
> signature.  I don't see any inconsistencies here.
> 
> <John>
> The moment you said 'applications can choose...' was the moment that
> Location resolution became application specific.  Either core code is
> self
> contained or core code must rely on applications to choose 
> (in part) how
> it
> operates.
> </John>

Note that whether or not the signer is trusted is necessarily "application
specific."  If I sign something with my Mallory Certification Services
certificate and the verifier doesn't trust Mallory Certification Services,
the verifier will reject the signature even if it is otherwise valid.  I
don't think "application specific" is a dirty phrase.  Indeed, I see it as
useful and not onerous to allow applications to decide in this case.

> Transforms outside of SignedInfo:  we both object to them, just to
> differing
> degrees.  The reason I don't object as strongly as you do is that the
> application can decide which transformations to trust.
> 
> <John>
> That would lead us down the slippery slope of not really 
> knowing what to
> believe after running core code and getting 'VALID' as the response.
> When core code says VALID, then the things that core code signs should
> still
> be VALID.
> </John>
> 
> Note that the Transforms outside of the SignedInfo can be signed by
> another
> signature, and
> applications can use *that* as a criteria for trust.  However, I would
> prefer that we let applications deal with that issue and not have
> Transforms
> outside of SignedInfo.
> 
> <John>
> Obviously, I agree here since signing the transforms by another
> signature
> defeats the purpose of having them unsigned in the first place.
> </John>

You are missing the point.  The application that signs the additional
Transforms is different than the application that created the original
signature.  It may or may not use different credentials to create the second
signature.  The original application may well not know that the document is
going to be moved.  This is Joseph's assertions-about-assertions approach,
which I very much like and think is the only general solution to the problem
we are trying to address.  If the object is moved again, the added signature
can be removed, and a different one put in place.

But as you point out, the idea creates issues when used in the core.  I'm
happy pushing this off to the application to make the necessary
assertions-about-assertions.  At that level, the issue of validity that you
point out goes away.

> Your example:  this is not a problem I was trying to solve.  My main
> concern
> was for the x.com to y.com or base64 on web to unencoded on 
> disk type of
> changes, which my concept of "location as hint" addresses.  I was not
> trying
> to deal with the general document transmogrification case; do we feel
> this
> is a problem we need to solve?
> 
> <John>
> Yes, since the example I gave is the base64 in the document 
> to unencoded
> on
> disk.  This is one of Rich Himes's scenarios, and it was also 
> one of the
> original goals that Dave Solo had. The movement of the bag of 
> bits from
> within the document to without should not break the signature.
> </John>

My bad.  I had forgotten that the base64-encoded document was embedded in
that example.  Yes, a different mechanism has to be used for that.  I don't
see the XPath-over-SignedInfo solution as effective because the signing
application has to *know* that the document is going to move.  To me, the
conceptually proper solution is to use assertions-about-assertions.  I like
location-as-hint because it simplifies what seems to me will be a common
case (http://x.com/this changing to http://y.com/that) without adding
complexity, but I don't have a problem with using assertions for that case
as well.

Perhaps at a later point in the process we should attempt to address such
assertions, and specify how to do the one necessary for this (the document
here is the document that was there).

-Mark Bartel
JetForm Corporation

Received on Tuesday, 23 November 1999 11:13:15 UTC