Re: [dss] client-side hashing

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

It could be done the second way (client is responsible for the hash resolving to the proper document) if the relying parties understood exactly what assertions were being made to them and accepted the attentuated risks. This might require certain policies at the DSS server in order to distinguish the document vs. document hash cases. It might also require upon verification that the relying party expreslly accepted the risks associated with the second case. This gets very close to the type of use case that was suggested by Pieter Kasselman with regard to policies and pointers to the policies.

---------- Original Message ----------------------------------
From: Trevor Perrin <trevp@trevp.net>
Date:  Mon, 03 Feb 2003 19:09:13 -0800

>At 08:43 PM 2/3/2003 -0500, Rich Salz wrote:
>
>>But a third-party signing service,
>>or an internal cost-center service, might be concerned about signing
>>something that it didn't actually see. [....]
>>So I think we need to at least mention the implications of providing
>>this.
>
>I agree.  I think this highlights a basic difference between the "Corporate 
>Seal" and "Identified Requester" use cases:
>http://lists.oasis-open.org/archives/dss/200301/msg00002.html
>
>In the Corporate Seal case, the corporation is making an assertion, and so 
>would definitely want to archive and probably review the document (manually 
>or automatedly) before signing it .  An example is someone producing a 
>press release, or committing the company to a purchase order, or 
>code-signing an executable.
>
>In the Identified Requester case, the user is making an assertion, and the 
>service is just some machinery that's supporting him, by holding his 
>private key and performing expensive calculations for him.  An example 
>would be a 3rd-party service hosted on the internet.  You could open an 
>account with this service and then point your DSS-compatible email client 
>to them to get your mails signed.  But you wouldn't want the inefficiency 
>or privacy loss of sending all your mails to them.
>
>I think the TC was chartered with the first case in mind, where client-side 
>hashing is undesirable.  But I think the second case is potentially quite 
>exciting, so even if it's a stretch I hope it can be included.
>
>Trevor 
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>