OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Nick,

I agree with the text
Juan Carlos.
Missatge citat per Nick Pope <pope@secstan.com>:

> I propose the following revised response below to the comment posted by
> Veiko Sinivee early next week.  Can I have any comments before ASAP before
> then:
> 
> 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
> > >
> > >
> >
> >
> >
> > 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.
> 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]