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

["Edward Shallow" <ed.shallow@rogers.com>]

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
.