RE: [dss] RE: [dss-comment] Public Comment

["Nick Pope" <pope@secstan.com>]

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
.