[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