RE: Omitting Location and Transforms from SignedInfo

> -----Original Message-----
> From: John Boyer [mailto:jboyer@uwi.com]
> Sent: Wednesday, November 17, 1999 3:58 PM
> To: Jim Schaad (Exchange)
> Cc: DSig Group
> Subject: RE: Omitting Location and Transforms from SignedInfo
> 
> 
> 
> That is not at all what I am proposing.  I think it is just 
> fine to sign
> something that is not a manifest and is not in the current 
> document.  What I
> am stating is that if the application does not want the 
> behavior that we
> automatically go and try to verify what is being signed, then 
> it goes in a
> manifest.  If you want to have the core code automatically 
> very what is
> being signed, it can be in the SignerInfo object.  The 
> locality of the data
> is unimportant.
> 
> <John>
> Oh, I thought I'd already said why that wasn't such a hot idea.
> 
> 1) We want core code to automatically verify the DigestValue of
> ObjectReference because this is equivalent to verifying the 
> bulk of the data
> that the signer actually wanted to sign.

I don't know that I agree with this statement, but it's not that important.
Verifying that a manifest is correct does not validate any large amount of
data.

> 
> 2) The core rules automatically verify DigestValue of 
> ObjectReference if and
> only if Location is invariant once the signature is created. 
> If the Location
> of a piece of data is expected to change, then our core 
> processing rules
> cannot accommodate the signature.  This has nothing to do 
> with some weird
> application-specific need that only a handful of people have. 
>  Locations
> change, auxiliary documents get updated.  If someone wants to 
> preserve a
> signature, they may need to change a Location here or there.  
> This is likely
> to be a commonplace event with long-term signatures on 
> high-value documents.

I disagree with this statement.  I believe that the if and only if statement
is wrong, and everything following from that is therefore also incorrect.

> 
> The point is that yes, they could push this off to a 
> Manifest, but manifests
> rely on application-specific behavior to validate. What we're 
> saying is that
> a certain class of signatures cannot be validated by core 
> code for reasons
> that don't seem to have anything to do with the needs of the 
> application.
> 
> It would be much cleaner to design a syntax that, by its 
> design, does not
> have us chasing things down outside of the current document.  
> I expect it
> will also be somewhat common to have signatures that point to 
> things outside
> of the document, and such signatures will need application 
> logic to validate
> the signature.  But, at least the need for application validation has
> *something* to do with a direct need of the application-- 
> esp. given that
> such a need may already depend on application specific 
> caching systems,
> resource resolution schemes and so forth.
> 
> John Boyer
> Software Development Manager
> UWI.Com -- The Internet Forms Company
> 
> </John>
> 
> jim
>

Received on Wednesday, 17 November 1999 19:17:21 UTC