[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [pki-guidlines] spc input please
Anders, Its not that I don't like it; I don't believe it meets the requirements that I'm focusing on. I am in the middle of validating those requirements from 2 end-user customers which will drive this effort (as required by the Member Section of OASIS PKI-TC; as soon as I receive it their input, I will post it to the list for consensus. If those requirements are met by WASP, then I believe we have something we can work with; if not, we'll discuss as a group what will meet those requirements. If you believe you can gather some end-user requirements that your contacts are willing to support, then please feel free to send them the attached DRAFT, so they may add/subtract from these requirements. Thanks. Arshad Noor StrongAuth, Inc. > DRAFT requirements for the "Transaction-PKI" projct > =================================================== > > In order to provide improved security against rising risks, > the following capabilities are desirable for web-applications: > > 1) The ability to digitally sign a web-form using public-key > cryptography with a local private-key - i.e. the private-key > must reside on the client side of the application; > > 2) The ability to encrypt web-form content using public-key > cryptography with public-keys embedded in the form, or that > can be found using URIs at encrypt-time; > > 3) The signing capability must be native in the browser; i.e. > there must be no downloaded applets or locally installed > plug-ins. Just as the browser natively performs crypto > operations to establish an SSL/TLS session, it must so > perform the signing/verification of the form-content in the > transaction. The encryption/decryption capabilities must be > native to the browser too; > > 4) The signing capability must work with any locally-defined > crypto token, known to the browser, using either the CAPI > or PKCS#11 interfaces; > > 5) The capability must leverage existing standards such as > XHTML, JavaScript, XForms, XML Signature, XML Encryption, > OASIS Web Services Security, etc. where it can. If new > code needs to be written, then the gap must be identified > and defined very clearly; > > 6) The capability must work with existing browsers - Firefox, > IE, Opera and Safari; ----- Original Message ----- From: Anders Rundgren <anders.rundgren@telia.com> Date: Monday, October 17, 2005 12:05 pm Subject: [pki-guidlines] spc input please > Arshad, > > I'm still waiting on more info on what you had in mind regarding > web signing. > And I'm also curious to know what you don't like in WASP except > that it does not encrypt. > > You may post that to the guideline list. > > But as I wrote. Very little progress can be expected until > somebody else > also tries to cast the purchasing process in PKI. > > Anders > > ----- Original Message ----- > From: "Arshad Noor" <arshad.noor@strongauth.com> > To: "Stephen Wilson" <swilson@lockstep.com.au> > Cc: "Anders Rundgren" <anders.rundgren@telia.com> > Sent: Monday, October 17, 2005 15:15 > Subject: Re: Comments to the DoD - "Smart cards failed" analysis > > > Sigh, because Anders persists on sending some e-mail to us > directly rather than to the Applications Guidelines SC alias > despite my request. To be fair, he is starting to send some > e-mail to the list. > > Stephen, please feel free to respond to the list by explicitly > adding them to the mail header where you believe it to be > appropriate. Thanks. > > Arshad > > Stephen Wilson wrote: > > > > > PS I am still not sure why this debate is happening between you > and Arshad > > and me. > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]