Re: UseCase : Strong Personal Identity Certificate by CA

Hi Mountie,

Although the WebCrypto WG probably violently disagrees, I think you need something much more powerful than a measly key-pair generator to make client certificate issuance generally useful.

Related:

  VISA drops the password and replaces it with - NOTHING
  http://www.finextra.com/news/announcement.aspx?pressreleaseid=45624

Anyway, this is pretty much like the on-line banking use-case which I have been nagging the WebCrypto WG about from day one :-)

Anders


On 2012-08-13 19:45, Mountie Lee 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)
> 
> -----------------
> 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 <mailto:sleevi@google.com>> wrote:
> 
>     On Mon, Aug 13, 2012 at 2:42 AM, Anders Rundgren
>     <anders.rundgren@telia.com <mailto: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> <mailto: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>> <mailto: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 <mailto: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 18:56:44 UTC