RE: [dss] client-side hashing

["Kaliski, Burt" <BKaliski@rsasecurity.com>]

> Although hashes are 99.44% pure, there is always a risk that another
document will resolve to the same hash. 

Agreed. However, this risk applies whether or not the DSS service hashes the
message.

As far as I can see, there are only three reasons to have the DSS service
hash the message: 

(1) the DSS service decides whether or not to sign the message based on the
content of the message
(2) the DSS service needs to keep the message for later auditing
(3) the DSS introduces randomness into the hashing process to prevent
"birthday attacks" (this is done in some signature schemes but not the
standard ones such as DSA or RSA)

-- Burt

-----Original Message-----
From: John Messing [mailto:jmessing@law-on-line.com]
Sent: Monday, February 03, 2003 9:27 PM
To: Trevor Perrin; Rich Salz
Cc: dss@lists.oasis-open.org
Subject: Re: [dss] client-side hashing


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>
>

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>