Re: Certificate Enrollment- Already done?

On 2013-01-07 08:18, Mountie Lee wrote:
> I think
> the reason we are talking about standardization of crypto technology is
> being vendor independent.

Mountie,

There is no disagreement here.

However, formal standardization by an SDO is just one way of establishing
a "standard".  For this particular task, I feel that there's no ground
for traditional standards work because the examples I gave, all build on
using secure hardware for storing keys and IMO this is what it takes
to address banking and national PKIs.

Samsung is a better bet because they are the biggest smartphone supplier
in the world and they also build their own CPUs.

Making PCs useful for consumer-PKI is Microsoft's and Intel's call.  The
cited examples are targeted at the enterprise.

Anders

> 
> if the technology is perfect but belong to specific vendor, we can not adopt in nation wide use.
> 
> Korea NPKI means Korea NATIONAL Public Key Infrastructure.
> 
> I fee still we need to discuss more for certificate related issues.
> 
> 
> On Mon, Jan 7, 2013 at 2:11 PM, Anders Rundgren <anders.rundgren@telia.com <mailto:anders.rundgren@telia.com>> wrote:
> 
>     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> <mailto: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> <mailto:mountie@paygate.net <mailto:mountie@paygate.net>>
>     >
>     > =======================================
>     > PayGate Inc.
>     > THE STANDARD FOR ONLINE PAYMENT
>     > for Korea, Japan, China, and the World
>     >
>     >
>     >
>     >
> 
> 
> 
> 
> -- 
> 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 08:44:50 UTC