RE: Omitting Location and Transforms from SignedInfo

> -----Original Message-----
> From: Joseph M. Reagle Jr. [mailto:reagle@w3.org]
> Sent: Wednesday, November 17, 1999 6:44 AM
> To: John Boyer
> Cc: Greg Whitehead; DSig Group
> Subject: RE: Omitting Location and Transforms from SignedInfo
> 
> 
> At 09:54 99/11/12 -0800, John Boyer wrote:
>  >This is quite problematic.  Our core processing rules state 
> that we verify
>  >SignedInfo, then we verify the digest values of the 
> ObjectReferences.  HOW
>  >IS CORE BEHAVIOR GOING TO DO THIS IF CORE BEHAVIOR DOESN'T KNOW 
>  >HOW TO
>  >RETRIEVE THE DATA?
> 
> Just wanted to comment that I think this core behavior was a 
> mistake. We've
> inextricably link the idea of resource validation (does the 
> content when
> dereferenced at a URI and transformed appropriately) with signature
> validation (does the signed blob (SignInfo) when plugged into 
> the specified
> digest and signature method with a key result in a SignatureValue.) We
> specified this core resource validation behaviour because 
> people wanted to
> ensure the signature was over the actual content. We did this 
> because we
> only allowed references and not the actual content. 
> Consequently to force
> signature validation of the actual content we had to (1) 
> include signer
> created validation rules in the ObjectReferences or (2) make 
> that a default
> behaviour of SignedInfo. I didn't like (1) because I don't 
> think we our
> trust model is well thought out; unfortunately (2) has led to 
> a string of
> design decisions that involves us in resource resolution 
> problems which are
> just as nasty ...
> 

Some responses to this message:

1.  The behavior you described is easily obtainable in the current syntax by
putting all of the object references in a manifest and then putting the
object reference to the manifest in the document.  We check the signature,
check the digest on the manifest and stop processing.  The application can
then do whatever verification it things are necessary on the object
references in the manifest. (I actually was originally an opponent of having
more that the reference to the manifest in the signed info, but there were a
large number of people who wanted the current behavior.)

2.  Location is, always has been and always will be in the end a hint.  If
an application wants to add the semantics that the location must be correct
it can, however the fact that the document is not retrieved from the
location specified does not change the validity of the signature.  Trying to
add this will get lots of people, especially lawyers, a lot of work and
nothing else.  If I sign a document and refer to a set of conditions and
terms on a web sight, the fact that the list of conditions gets updated does
not invalidate my signature.  In the event that you want to prove something
for the purpose of enforcing a signature, one would grab and save the
documents referred to and save them with the signature.  The fact that the
documents are not at the same location DOES NOT change the validity of the
signature, nor does the fact that you cannot prove that the document came
from that location.  The important thing is that the digest of the document
you are presenting as coming from that location matches the digest of the
document being signed.

3.  The current wording of the document says:

    1. locate object and apply Transforms  to the specified resource
       based on each ObjectReference(s) in the SignedInfo element.  Each
       transform is applied in order from left to right to the object
       with the output of each transform being the input to the next.

This does not imply in my mind that the location is the only place that the
object can come from.  It merely says find the bytes for the object.
    

jim

Received on Wednesday, 17 November 1999 16:12:35 UTC