Re: Certificate Enrollment- Already done?

On 2013-01-07 02:38, Mountie Lee 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

Dear Mountie,

Based on the list's (lack of) activity on this subject as well as similar
discussions in IETF-PKIX, Mozilla crypto, and TrustedComputingGroup, I think
that it might be better leaving this topic "as is".

Unless I got things completely wrong regarding IndexDB (quite possible,
this is not my area of expertize...), certificates are already fully supportable
without any additions to the Web Crypto API using the method I described.

Creating standards for traditional PKI users seems futile since the
US tech giants already have invested in propriety and NDA-protected
solutions in this space:

Intel: http://communities.intel.com/community/vproexpert/blog/2012/05/18/intel-ipt-with-embedded-pki-and-protected-transaction-display
Microsoft: http://www.microsoft.com/en-us/download/details.aspx?id=29076
Google: http://www.google.com/wallet

>From your perspective it may even be a better idea talking to Samsung,
I would gladly join you on such a mission :-)

Anders


> 
> 
> 
> 
> On Fri, Dec 21, 2012 at 2:33 PM, Anders Rundgren <anders.rundgren@telia.com <mailto: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 <mailto:mountie@paygate.net>
> 
> =======================================
> PayGate Inc.
> THE STANDARD FOR ONLINE PAYMENT
> for Korea, Japan, China, and the World
> 
> 
> 
>

Received on Monday, 7 January 2013 05:11:53 UTC