[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [dss] client-side hashing
There may be an even better way to do this, with ds:Manifest. A client could submit a Manifest just like submitting any document, and the service would return a ds:Signature on that Manifest. Doing this for CMS (i.e. S/MIME) signatures wouldn't be so easy. You'd need a special-case protocol where the client sends the DigestAlgorithmIdentifier and digest value and gets back a SignerInfo and some certificates, which the client could put together into a SignedData, or something like that... Trevor At 12:14 AM 2/3/2003 -0800, Manoj K. Srivastava wrote: >Content-Transfer-Encoding: 7BIT > >This may already be covered by the Non-XML data signing use case >http://www.infomosaic.net/DSS-UseCases.htm#NonXMLData. Basically the >service simply treats the input, which in this case is ds:SignedInfo >element, as an arbitrary bit stream and returns its signature back to >the requester. The requester can then put it in the ds:SignatureValue >element and complete the signed XML preparation. The only issue to be >considered would be if the value returned by the DSS service is little >endian or big endian. > >Regards, > >Manoj Srivastava >President & CEO >Infomosaic Corporation >2118 Walsh Avenue, Suite 200 >Santa Clara, CA 95050 >Voice: (408) 988-4337 >Fax: (408) 516-9427 >http://www.infomosaic.net > >Confidentiality Notice: This e-mail message, including any attachments, >is for the sole use of the intended recipient(s) and may contain >confidential and/or privileged information. Any unauthorized review, >use, disclosure or distribution is prohibited. If you are not the >intended recipient, Please contact the sender by reply e-mail and >destroy all copies of the original message. > >-----Original Message----- >From: Trevor Perrin [mailto:trevp@trevp.net] >Sent: Sunday, February 02, 2003 9:09 PM >To: dss@lists.oasis-open.org >Subject: [dss] client-side hashing > > > >Greetings, > >I'd like to propose that a client may compute the hash on some document >himself, then request the service to sign/verify this hash. This would >be >more efficient that submitting the whole document. > >It would also keep the document's contents hidden from the service. >This >might be a disadvantage in use cases like Carlisle's "Corporate Seal", >where the corporation would like to keep a record of what it has >signed. It might be an advantage in Carlisle's "Identified Requester" >case, where the service is simply a private-key-holder for the client, >and >the less the client has to trust it the better. > >To sign, a client could send a ds:SignedInfo and receive back a >ds:Signature. To verify, the client would perform reference validation >himself, then forward the ds:Signature to the service for signature >validation. > > >Trevor > > >---------------------------------------------------------------- >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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC