[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [dss] client-side hashing
> 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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC