- From: Ryan Sleevi <sleevi@google.com>
- Date: Mon, 13 Aug 2012 12:10:22 -0700
- To: Mountie Lee <mountie.lee@gmail.com>
- Cc: Anders Rundgren <anders.rundgren@telia.com>, public-webcrypto-comments@w3.org
On Mon, Aug 13, 2012 at 10:45 AM, Mountie Lee <mountie.lee@gmail.com> wrote: > Hi. > I read the thread at http://www.w3.org/2012/07/24-crypto-minutes.html > > but difficult to find discussion about personal identity with client > certificate. > > the "key attributes" mentioned in discussion thread is > I think, different from certificate extention. > > look following my scenarios. > > ---------- > > [getting Personal Certificate with Extended Validation] > > 1. User-A(named Bob) want to get Personal Certificate with Extended > validation > 2. Bob visit to trusted CA > 3. Bob generate(via web crypto API?) key pair and submit public key part to > CA > 4. CA will validate user identify with multiple steps (checking user > identity by face to face meeting and physical drivers license or other fully > trusted validation mechanism) > 5. CA validation will be taken over multiple days. > 6. CA inform to Bob that the validation processes is now completed and > certificate is issued. > 7. Bob visit to CA web site and install cert to user agent's keystore (can > be smartcard or browser keystore with unexportable private key option) > 8. now Bob has the personal certificate with extended validation extension > and can be used globally > 9. User-B(named Alice) get the personal certificate with same extended > validation process from CA > > [CA side] > 1. CA get the CSR from user > 2. CA validate user identify with strong validation process (up to multiple > days, depends on regulations or CA policies) > 3. CA issue certificate with specific certificate extension (not key > attribute controllable by 3rd party, extension is the part of certificate > itself, can not be changed) > 4. CA inform to user that the cert is issued > 5. the user cert will be valid up to expiration date globally > > [Service Provider side] > 1. Service Provider (shorten SP) want signed document from Bob. > 2. SP prepare JS functions that > 2.1 list cert with extended validation from user keystore > 2.2 let user sign document > 2.3 let use send the signed document to SP > 3. SP verify signature and document > 4. SP is able to assure that the signer is Bob who is validated by trusted > CA without any membership registration of Bob > > [Bob send signed document to Alice] > 1. two person(Bob and Alice) want to exchange agreement between each other > 2. Bob sign(using web crypto API) agreement with private key pared with > EVPersonalCert. > 3. Bob send signed agreement to Alice. > 4. Alice verify(using web crypto API) signed agreement > 5. Alice sign(using web crypto API) again for agreement with private key > pared with EVPersonalCert. > 6. Alice send document back to Bob > 7. Bob verify (using web crypto API) signed agreement > > [web crypto API side] > * generate key pair (common?) > * search certificate extension or key attributes (not sure) > * sign and verify (common) Hi Mountie, Yes, we're planning to address the Sign&Verify steps and, as discussed on the 24th of June, the <keygen> use case. Additionally, searching for keys is something that has a strawman (KeyQueryList) that is being incorporated. The search for certificate extensions is secondary features, and currently controversial. Focusing on the entire solution (re: IdP vs PP vs consumer) was what I was and am concerned would be distracting. Regards, Ryan > > ----------------- > currently some limited CAs (some CAs in Korea and EU) issue client cert with > strong validation process. > and many services are developed depending on assured user identity with > client certificate.(but using binary plugins) > > web crypto API can encourage more trusted personal data exchange not > depending service provider. > > best regards > mountie. > > On Tue, Aug 14, 2012 at 12:24 AM, Ryan Sleevi <sleevi@google.com> wrote: >> >> On Mon, Aug 13, 2012 at 2:42 AM, Anders Rundgren >> <anders.rundgren@telia.com> wrote: >> > On 2012-08-13 11:22, Mountie Lee wrote: >> >> Hi. >> >> I'm not requesting more functions. >> >> >> >> it is the recommendation for adding use case. >> > >> > Hi Mountie, >> > I don't understand the use-case. >> > >> > Most important: What is (in your opinion) missing today? >> > >> > How do clients get the certificates? >> > What should trusted mean for the API? >> > >> > Regards, >> > Anders >> >> Hi Mountie, >> >> If I understand you correctly, you're asking that it simply be >> documented in the Use Cases that this API can provide a more flexible >> alternative to <keygen>, is that correct? If so, this seems perfectly >> reasonable, and was discussed and agreed upon during our July 24th >> Face to Face ( http://www.w3.org/2012/07/24-crypto-minutes.html ). It >> looks like that hasn't yet been captured on our use cases wiki. >> >> I don't believe the distinction of client certificates or strong vs >> weak personal identity verification is necessarily important to that, >> so if it's reasonable, it may be worth avoiding mentioning that >> specific case. >> >> Cheers, >> Ryan >> >> > >> >> >> >> regards >> >> mountie. >> >> >> >> On Mon, Aug 13, 2012 at 5:40 PM, Anders Rundgren >> >> <anders.rundgren@telia.com <mailto:anders.rundgren@telia.com>> wrote: >> >> >> >> On 2012-08-13 10:08, Mountie Lee wrote: >> >> > Hi. >> >> > I meant >> >> > CA can issue personal certificate ONCE with strong identity >> >> validation. >> >> > I did not though two factor authentication or others PER USE. >> >> > >> >> > I can search http://www.symantec.com/verisign/digital-id >> >> > but the cert is not enough to trust the personal identity. >> >> > >> >> > just I expect the new ca service like "Digital ID with Extended >> >> Validation" as use case. >> >> > because of web crypto API. >> >> >> >> Hi Mountie, >> >> I'm not sure what function you are requesting. >> >> >> >> Extended Validation is a CA policy for server certificates that are >> >> supposed to be "automatically" highly trusted by user agents. >> >> It is not possible to translate this to client certificates because >> >> the relying party is not your platform/user agent/web browser/etc. It is >> >> another system >> >> >> >> I don't think that even the concept of trusted personal identity is >> >> generally acknowledged. >> >> This tends to be rather local, national or community-based. >> >> >> >> I have a company certificate. It is trusted within the company >> >> since it was internally issued using an approved process. However, outside >> >> of the company it is unknown (non-trusted). >> >> >> >> Best regards, >> >> Anders >> >> >> >> > >> >> > best regards >> >> > mountie. >> >> > >> >> > >> >> > On Mon, Aug 13, 2012 at 4:35 PM, Anders Rundgren >> >> <anders.rundgren@telia.com <mailto:anders.rundgren@telia.com> >> >> <mailto:anders.rundgren@telia.com <mailto:anders.rundgren@telia.com>>> >> >> wrote: >> >> > >> >> > On 2012-08-13 07:46, Mountie Lee wrote: >> >> > > I think following use case can be considered. >> >> > > >> >> > > CA issues strong personal identity certificates. >> >> > > it can be equivalent level to EVSSL on server side. >> >> > > >> >> > > current personal certificate issued by CA is just checking >> >> email validity. >> >> > > >> >> > > if web crypto API is widely accepted in major user agents >> >> > > certificate in user agents will have more functionality by >> >> using API. >> >> > > >> >> > > as a CA, they can consider to issue new type of certificate >> >> with strong personal identity validation. >> >> > >> >> > Hi Mountie, >> >> > >> >> > Certificate provisioning is AFAIK outside of WebCrypto scope. >> >> > >> >> > Banks and government agencies in the EU currently deploy >> >> their own software for provisioning since none of the user agents out there >> >> support provisioning of two-factor (key + PIN) authentication tokens [1]. >> >> > >> >> > Well, this wasn't entirely correct. When there is a >> >> *business incentive* to support provisioning of two-factor tokens, it is (of >> >> course) honored: >> >> > >> >> http://googlecommerce.blogspot.co.uk/2012/08/use-any-credit-or-debit-card-with.html >> >> > >> >> > Regards, >> >> > Anders >> >> > >> >> > 1] If you only need a client certificate and HTTPS you can >> >> use existing schemes like <keygen> and "CertEnroll". >> >> > >> >> > > >> >> > > regards >> >> > > mountie. >> >> > > >> >> > > ======================================= >> >> > > PayGate Inc. >> >> > > THE STANDARD FOR ONLINE PAYMENT >> >> > > for Korea, Japan, China, and the World >> >> > > >> >> > > >> >> > > >> >> > > >> >> > >> >> > >> >> > >> >> > ======================================= >> >> > PayGate Inc. >> >> > THE STANDARD FOR ONLINE PAYMENT >> >> > for Korea, Japan, China, and the World >> >> > >> >> > >> >> > >> >> > >> >> >> >> >> >> ======================================= >> >> PayGate Inc. >> >> THE STANDARD FOR ONLINE PAYMENT >> >> for Korea, Japan, China, and the World >> >> >> >> >> >> >> >> >> > >> > > > > > > -- > Mountie Lee > > Tel : +82 2 2140 2700 > E-Mail : mountie@paygate.net > Twitter : mountielee > > ======================================= > PayGate Inc. > THE STANDARD FOR ONLINE PAYMENT > for Korea, Japan, China, and the World >
Received on Monday, 13 August 2012 19:10:52 UTC