[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] RE: [dss-comment] Public Comment
Nick, To be more clear ... Veiko's problem is that he has no DSS core operation upon which to place his "here are my signing platform characteristics, please return me a page with a suitable signing control (i.e. ActiveX Automation Control or Java Applet) to perform the user's local signing". You correctly state this use unduly overloads the Sign protocol, and I agree. Veiko is left with no choice but to perform this exchange outside the scope of DSS since his application is a client-side signing one. The means Veiko can only attempt to make his Verify and Timestamp activities DSS-compliant. That is why I asked in my previous note, can we help "facilitate" client-side signing in the DSS profile ? The whole notion of page-resident signing controls, as I am sure many of you are aware, is very HTML response page centric. That is, ActiveX Controls must reside in HTML object tags (e.g. <Object ID=... CLASSID= ... CODEBASE= ... etc ...>) for them to kick into action under browser control. In a similar way Java Applets travel to the client on their hosting page. This is the domain of numerous and extremely popular HTML thin presentation frameworks (e.g. Active Server Pages, Java Server Pages, Cold Fusion Markup Language, and dozens of others). Is this something DSS really wants to get into, even if only tangentially ? I suspect Veiko's DSS client is in fact such a Control, and based on desktop characteristics he wants to "HTTP GET" a suitably-formatted HTML page in a <SignResponse> with all necessary <object> tagging to be displayed in his current browser session and is wondering if DSS can be extended to do something like this. Actually his hypothetical verb might be better named "CreateSigningPage" which would have a Request and a Response similar to our other operations. This could be complemented with a "VerifySignedPage" with its Request and Response which would be an HTTP POST instead of a GET. You can see the similarity and I don't blame him for asking. I mentioned other things the server could help with, all in a "support and facilitate" role for client-side signing activities. This however is scope expansion for sure. What about non-Browser based signing ? If we do not expand the scope (I am on the fence here), we are clearly stating to the public community that we are exclusively a server-side spec for signing and verifying, period. If we know this answer now, we should simply come clean with Veiko and tell him his request, although interesting, is out of DSS's scope, and that he can strive to make the rest of his service DSS-compliant. Ed -----Original Message----- From: Nick Pope [mailto:pope@secstan.com] Sent: August 3, 2004 4:49 AM To: OASIS DSS TC Subject: [dss] RE: [dss-comment] Public Comment I propose a response below to the comment posted by Veiko Sinivee: Veiko, 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. We/I read with interest the description of your current system. Could you say a bit more about the role of the step "and customers certficate (possibly one of many) is sent to the server". I presume by this you mean the server which supports loading the signing software into the user browser. What is the reason for this? We/I understand from your suggested change that you are proposing to use the DSS SignRequest operation not to actually carry out the signing but to obtain the necessary code to load into the client system. This is an interesting function and might be a useful to add this to DSS in the future, but we believe extending the existing Sign operation to support such functions would overload its use. Thanks again Nick Pope - Co-chair DSS > -----Original Message----- > From: comment-form@oasis-open.org [mailto:comment-form@oasis-open.org] > Sent: 03 August 2004 09:30 > To: dss-comment@lists.oasis-open.org > Subject: [dss-comment] Public Comment > > > Comment from: veiko.sinivee@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_workgroup.php .
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]