RE: [dss] client-side hashing

[Nick Pope <pope@secstan.com>]

I see that there are two types of service.

A notarisation type of signing service where the trusted third party
examines the document to be signed and only signs if the document meets
certain requirements, and possibly archives the document on behalf of the
requestor.  The other is a pure signing service where the server just
returns a digital signature against a document.

In the second case I see no difference between the document or a hash of the
document being submitted.   In both cases if "birthday attacks" are
considered to be a risk, and there exist two documents with the same hash
value, assuming that the signature algorithms uses encrypted hashes, then
substitution can occur whether or not the hash is calculated at the client
or server.

Is the DSS concerned with what I refer to as a notarisation type service?
If so we need a use case.

Nick



> -----Original Message-----
> From: Pieter Kasselman [mailto:pkasselman@baltimore.com]
> Sent: 04 February 2003 15:17
> To: 'jmessing@law-on-line.com'; Trevor Perrin; Rich Salz
> Cc: dss@lists.oasis-open.org
> Subject: RE: [dss] client-side hashing
>
>
> 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
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>