- From: Mountie Lee <mountie.lee@gmail.com>
- Date: Tue, 14 Aug 2012 02:45:28 +0900
- To: Ryan Sleevi <sleevi@google.com>
- Cc: Anders Rundgren <anders.rundgren@telia.com>, public-webcrypto-comments@w3.org
- Message-ID: <CAE-+aYJ66AUMqEDRwAMD5tXJ6pD_YxedrKr7jrH+Q0ZUR2p_0A@mail.gmail.com>
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) ----------------- 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 17:46:16 UTC