|Subject:||RE: [dss] RE: [dss-comment] Public Comment|
|From:||Nick Pope (po...@secstan.com)|
|Date:||Aug 12, 2004 3:48:14 pm|
I propose the following revised response below to the comment posted by Veiko Sinivee early next week. Can I have any comments before ASAP before then:
Thanks very much for you comments on the OASIS DSS protocol, external views on the DSS protocol are very much welcome.
You are correct in your comment that the current scope being aimed at server based signatures. However, there are other scenarios where a shared server may be applicable other than just corporate signatures. Firstly, where the server is trusted to maintain "control" of user keys they may be used to sign on the behalf of a individual user within a corporation. Secondly, where signatures are used to preserve the authenticity of documents, rather than apply an equivalent to a handwritten signature of an individual, then again a network service has a role.
The DSS "verify" function may also be of interest to confirm the validity of signature and also add additional properties (time-stamp, reference to CRLs / certificates used to verify signature) which can be useful for signatures that may need to be checked again long after the signing event. This may be used with client side signing.
We understand from your suggested change that you are proposing to use the DSS SignRequest operation to set up the client system for signing, instead of signing in a DSS server. We believe that using the current DSS SignRequest in this way would be overloading the operation. We would rather suggest that this is added as an additional operation in DSS. This is an interesting function and might be a useful to add this to DSS in the future.
If you are interested in working on such extensions to DSS we would very much welcome your participation in the DSS TC. Let me know if you are interested.
Nick Pope - Co-chair DSS
Comment from: veik...@seb.se
Dear sirs, My company has produced a similar webservice for digital signing. Unfortunately we started before this spec was published. Now after comparing our results with this spec I find the following differences. The spec handles only the case for creating digital signatures on a special server and not on the customers PC as in our case. This makes the spec unusable for us because we try to promote writing webapplications that allowe customers use smartcards for digital signatures. So the customers would have to sign the data on his own PC and a server cannot provide all of the functionality. Servers signature is only useful for a company issuing digitally signed documents but not for a private person wishing to confirm some document with his own digital signature. The signing process in our case has many steps. First the customers environment (operating system, browser type & version, availibility of Java etc.) is determined. Then a suitable signature component (ActiveX, Java applet etc.) is sent to the customers browser. Now all card readers and smartcards are searched. Customer can add info to be incorporated in a digital signature (e.g. <ClaimedRole> and/or <SignatureProductionPlace>) and customers certficate (possibly one of many) is sent to the server. Finally customer signs the hash of <SignedInfo> and signature is completed.
Ok I recommend the following change to the spec: <xs:element name=.SignRequest.> ... <xs:element ref=.dss:InputDocuments. minOccurs="0"/> ... Thus element <InputDocuments> would no longer be required in <SignRequest>. This would enable us to send <SignRequest> -s with <OptionalInputs> for the customers signing environment negotioation phase. regards, Veiko Sinivee
To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_wor