RE: [dss] client-side hashing

[Pieter Kasselman <pkasselman@baltimore.com>]

Hi John

A security issue may arise if the entity submitting the document to be
signed is not the same entity that authorises the signature. The authoriser
may want to inspect the document before signing. Do we want to support such
a scenario (I think it is not required)?

The extent to which a server is content aware can be implementation specific
and may be tied to a policy identifier.

I am not sure about the 99.44% number. The probability that a collision
occurs is quite trivial for a cryptographic hash function (2^(-n/2) for a
n-bit hash function). The risk of a collision is negligible for n>=160
(n>=128 may also be acceptable).

Pieter

> -----Original Message-----
> From:	John Messing [SMTP:jmessing@law-on-line.com]
> Sent:	04 February 2003 02:27
> 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>


-----------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only.  If you have received this message in error or
there are any problems please notify the originator immediately.  The 
unauthorised use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for
direct, special, indirect or consequential damages arising from alteration
of the contents of this message by a third party or as a result of any 
virus being passed on.

This footnote confirms that this email message has been swept for Content
Security threats, including computer viruses.
http://www.baltimore.com