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

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

Nick and Co.,

   The way I understand Veiko's requirement, he definitely could use Verify
and Timestamp, but would like to perform client-side signing. The EPM too is
intending to support both client-side signing as well as server-side signing
for similar demand reasons. The EPM is assuming that the client-side signing
is outside the scope of DSS, but I guess that too is debateable. Could (or
should) DSS expand its scope to "support and facilitate" client-side signing
activities. Clearly DSS could not "execute" the signing operation, but it
could support it. For example, DSS could "screen" the certificate the user
has selected and intends to use. This screening could take the shape of
anything like certificate policy, issuer name, usage, enhanced usage, etc
... This would be based on the user passing up the candidate certificates
before signing, or something. This would be, I imagine, to streamline the
acceptance and legitimacy of the subsequent Verify which would follow. The
DSS service provider would bless signatures created with certain certificate
profiles, etc ... I suspect however that we are getting into XKMS territory
are we not ? But perhaps having a stance on the way XKMS usage (and similar
certificate services) is conducted, within the DSS context, bears some
examination.

   In terms of "supporting" client-side signing, Nick also brings up the
notion of providing the ability to download "client signing code". Yet
another possibility, but a huge scope expansion IMHO.

   Thoughts ? 

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
.