OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [dss] client-side hashing


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 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC