Re: [dss] client-side hashing

[John Messing <jmessing@law-on-line.com>]

I agree totally with this post. As the chair of the ABA's Electronic Filing Committee, I think it would be imprudent for a court or government agency to accept a hash of a document for filing rather than the original document. Although hashes are 99.44% pure, there is always a risk that another document will resolve to the same hash. Even if the DSS service does not save the file, the fact that the DSS service as a trust third party hashed the document in the first place rather than a requestor provides an incremental measure of assurance over accepting a hash from a requestor. It also resolves certain legal liability aspects in favor of the DSS service, for the same reasons.

---------- Original Message ----------------------------------
From: Rich Salz <rsalz@datapower.com>
Date:  Mon, 03 Feb 2003 20:43:52 -0500 (EST)

>> The best way I can think of to support this, then, would be to have the
>> client send a list of ds:References, and a selector for what type of
>> signature he wants (CMS, XML DSIG, etc.).
>
>This brings to mind an interesting security issue.
>
>I understand the needs for sending the hash (privacy, performance, etc);
>we did this at my previous company.  But a third-party signing service,
>or an internal cost-center service, might be concerned about signing
>something that it didn't actually see.  (I don't think "send the hash"
>has similar security issues for verification.)
>
>So I think we need to at least mention the implications of providing
>this.
>        /r$
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>