Re: Certificate Enrollment- Already done?

On 2013-01-07 17:28, Richard Barnes wrote:
> Hi Mountie,
> 
> I actually think the current API already supports all of the steps in your lifecycle.

Me too.  Do you agree with my way of storing the certificate?

> 
> 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?

If that is the case we are talking about something way outside of the web crypto scope.

> 
> --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 20:13:33 UTC