Re: Certificate Enrollment- Already done?

Hi Mountie,

I actually think the current API already supports all of the steps in your lifecycle.

1. window.crypto.generateKey
2. window.crypto.sign over CSR
3. window.crypto.sign over CRL
4. window.crypto.verify over cert / CRL / OCSP response
5. See 1/2

The only thing that is difficult is handling the ASN.1, but that can all be done in content JS (as opposed to the browser).

The current API can't install a certificate for use as a TLS client certificate.  Is that what you're looking for?

--Richard




On Jan 6, 2013, at 8:38 PM, Mountie Lee <mountie@paygate.net> wrote:

> Certificate has it's own lifecycle
> - key generation
> - certificate enrollment
> - revoke certificate
> - verify certificate validaty (CRL or OCSP)
> - renew certificate
> 
> and also have some other issues (access to X509 extensions, same origin policy associated with certificate, password policy for keyStorage...)
> 
> 
> I need to start discussion more for certificate related issues.
> - we need to summarize the list of issues about certificate
> - we need to set boundary that to which level of issues WebCryptoWG approaches
> 
> 
> 
> 
> On Fri, Dec 21, 2012 at 2:33 PM, Anders Rundgren <anders.rundgren@telia.com> wrote:
> Adding certificate enrollment to the Web Crypto API is trivial; a certificate is just an attribute.
> 
> Although my knowledge of IndexedDB is sort of limited
> (  https://developer.mozilla.org/en-US/docs/IndexedDB/Basic_Concepts_Behind_IndexedDB )
> it seems (please don't kill me if I'm wrong...) that you could store a certificate in an
> "associated" table without even touching the Web Crypto API.
> 
> That is, to achieve the level of functionality offered by <keygen> and friends you are probably already there :-)
> 
> I don't see that CMC, CMP, SCEP, EST or anything of that kind would add any interesting to the plot
> since these schemes do not support an end-to-end security provisioning concept.
> 
> However, for the thorny subject known as "Banking Transactions" certificate enrollment is not
> enough, you rather need a token management scheme like SCPnn used in Google's Wallet.
> Gemalto have proposed a webbified version of this in W3C:
> 
>     http://lists.w3.org/Archives/Public/public-sysapps/2012Jun/0058.html
> 
> The problem (as I see it...) is that there's no defined "bridge" between the Web Crypto API
> and *real* banking technology such a featured in the Google Wallet.
> 
> Anders
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> Mountie Lee
> 
> PayGate
> CTO, CISSP
> Tel : +82 2 2140 2700
> E-Mail : mountie@paygate.net
> 
> =======================================
> PayGate Inc.
> THE STANDARD FOR ONLINE PAYMENT
> for Korea, Japan, China, and the World
> 
>

Received on Monday, 7 January 2013 16:28:42 UTC