[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] RE: [dss-comment] Public Comment
Ed and All, If there is sufficient support we could extend the protocol. However, this is a significant extension and unless there is support I agree we should go back indicating that it currently isn't in our scope. Any other views? I agree that we also can emphasise that the Verify function may be used with client side signing. Nick > -----Original Message----- > From: Edward Shallow [mailto:ed.shallow@rogers.com] > Sent: 04 August 2004 05:31 > To: 'Nick Pope'; 'OASIS DSS TC' > 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_wor kgroup.php . 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]