RE: [dss-comment] Public Comment

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

Vieko,

In response to the specific points raised below:

> how is it different from non-PKI approaces such as username/password,
digipass etc.

DSS signatures still have the significant advantage of public key systems in
that any relying party can validate the authenticity of any digital
signature bound to data.

> Keeping the keys on the server essentially makes it a shared-secret
system, doesn't it ?

Not necessarily, it is a common point of trust, but it is possible to have
sepatate keys with access control based on user ID.

> ..... It would be like a swiss-knife that you can use for anything.

Yes - like the analogy.

> Sure we would like to contribute to enhancing the DSS protocol.

Would you be able to join the DSS Technical Committee? We have a phone
conference every 2 weeks to review progress and discuss major issues,
otherwise work is carried out by email.  See
http://www.oasis-open.org/committees/join.php for details.

> the right place to start would be describing the use cases and comparing
the requirements in various cases.

I agree.

Rergards

Nick

>
> -----Original Message-----
> From: Veiko.Sinivee@seb.se [mailto:Veiko.Sinivee@seb.se]
> Sent: 16 August 2004 11:53
> To: pope@secstan.com; dss-comment@lists.oasis-open.org
> Cc: tarvi@sk.ee
> Subject: RE: [dss-comment] Public Comment
>
>
> Dear Nick,
>
> thank you for your response. I agree, that a fully server based
> signature operation is much less complex to use and removes most
> possible error cases (setup of card readers, user platform
> detection etc.).
> It also simplifies the usage of the service because the above mentioned
> problems no longer exist. One doesn't have to explain all customers
> how to setup card readers (or any other siganture device like
> USB, PCMCIA, etc.)
> and the user of such a service can code a pretty ordinary web application.
>
> In my country we use smartcards issued by the government to citizens.
> There are already more than 500 000 cards issued. We have also cards
> issued to corporations. One of the implications of a personal signature
> device is that if used, it creates a digitally signed document that is
> binding (just like handsigned one) for this particular citizen. Having
> the keys on a smartcard (or any other "removeable" device) makes me
> feel safer. Depends on how much you trust the service provider offcourse.
> I think keeping keys on a server is ok for most cases where the keys
> are restricted (for example by using certificate policies?) to a certain
> domain. For example a corporate server signing on behalf of a salesperson
> working for the same company. Such a signature is really more binding to
> the company, not the person. Otherwise how do you achieve non-repudiation?
> If any administrator might have had enough knowledge access the server...
> Administrative measures to prevent this are good but then how is
> it different
> from non-PKI approaces such as username/password, digipass etc. Keeping
> the keys on the server essentially makes it a shared-secret
> system, doesn't
> it ?
>
> I agree also that the change I recommended might make the
> particular request
> too broadly understood. It would be like a swiss-knife that you
> can use for anything.
> Sure we would like to contribute to enhancing the DSS protocol. Perhaps
> the right place to start would be describing the use cases and
> comparing the
> requirements in various cases. The goal might be to achieve a
> clear protocol
> such that any two services claiming to support the same protocol version
> could be interoperable and everything described using OptionalInputs and
> OptionalOutputs would not be required to understand in order to guarantee
> basic interoperability.
>
> regards,
>
> Veiko Sinivee
>
>
>
>
>
> -----Original Message-----
> From: Nick Pope [mailto:pope@secstan.com]
> Sent: Monday, August 16, 2004 12:40 PM
> To: Sinivee, Veiko; dss-comment@lists.oasis-open.org
> Subject: RE: [dss-comment] Public Comment
>
>
> 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
> >
> >
>
>
>
>