RE: [dss-comment] Public Comment

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

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.  This may be
used with client side signing.

We understand from your suggested change that you are proposing to use the
DSS SignRequest operation to set up the client system for signing, instead
of signing in a DSS server.  We believe that using the current DSS
SignRequest in this way would be overloading the operation.  We would rather
suggest that this is added as an additional operation in DSS.    This is an
interesting function and might be a useful to add this to DSS in the future.

If you are interested in working on such extensions to DSS we would very
much welcome your participation in the DSS TC.  Let me know if you are
interested.

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
>
>