Re: draft for certificate management

On 2013-03-29 11:55, Aymeric Vitte wrote:
> Maybe I have a too simplistic view of the certificate subject but as I 
> see it the API should provide tools to create, manage, store 
> certificates and associated keys based on the WebCrypto API, 

As far as I can see _all_is_already_there_ if IndexDB can be used to
hold arbitrary attributes associated with a key including certificates.


> then people can build on top of it CMP, EST things if they like and
> if web technics allow it securely, the API should support the "standard"
> enrollment/provisioning procedures (see next sentence).

They may be able to do that although it would be pretty pointless
since they anyway have to provide JS-based bootstrap code and ASN.1
encoding/decoding.


> Now, as someone else mentionned in another thread, it seems like we have 
> to read between the lines to know what everybody want, would be good to 
> have clear scenario of what is required from any interested people.

In particular how they intend to use an API that doesn't support
PIN-code-protected keys which at least in the context of e-banking
and e-government PKIs is the _de-facto_standard_.

Since none of the browser-vendors have figured out how to do this in
their current web-platforms, this brings up the #1 question:
_What_ is the target audience?

And then we have the hardware security issues...

Regards,
Anders

> 
> Regards,
> 
> Le 29/03/2013 09:55, Anders Rundgren a écrit :
>> On 2013-03-29 08:49, Mountie Lee wrote:
>>> Hi.
>>>
>>> my timeframe is same what you think.
>>>
>>> please understand it is more complex than ever I expected.
>>>
>>> I will try to post draft before F2F.
>> I would like to understand why CMP or EST would be suitable candidates.
>>
>> CMP was designed for advanced RA<-->CA exchanges using statically configured clients and servers.
>> On the web you have multiple issuers, and client configuration doesn't apply at all.
>> In addition, CMP and EST put user authentication in the protocol.
>> On the web you rather put that in the "web-layer" like in <keygen>.
>>
>> Implementing a new enrollment protocol on the server side is actually
>> _piece_of_cake_, I have personally implemented not less than four such in
>> http://ejbca.org so you may very well start from scratch with a list of
>> requirements.  I haven't see _much_ requirements to date.
>>
>> What does for example key management mean? CMP supports key-management
>> but it is usually based on _manual_intervention_ by an RA manager
>> (when a user's card has expired) which doesn't translate to the web.
>> I.e. in order to do automated key renewals there must some attribute
>> holding the renewal URL or similar for the key in question.
>> Standardizing such functionality is probably not particularly easy.
>>
>> Anders
>>
>>
>>> regards
>>> mountie.
>>>
>>>
>>> On Fri, Mar 29, 2013 at 1:55 AM, GALINDO Virginie <Virginie.GALINDO@gemalto.com <mailto:Virginie.GALINDO@gemalto.com>> wrote:
>>>
>>>      Mountie, Nick, Aymeric,
>>>
>>>      Some time will be allocated during our San Jose F2F meeting to present a draft for this feature. That would be great if you could make it available a little bit before the F2F.
>>>
>>>      Regards,
>>>      Virginie
>>>
>>>      -----Original Message-----
>>>      From: Aymeric Vitte [mailto:vitteaymeric@gmail.com <mailto:vitteaymeric@gmail.com>]
>>>      Sent: lundi 4 mars 2013 14:52
>>>      To: Harry Halpin
>>>      Cc: Nick Van den Bleeken; Mountie Lee; public-webcrypto-comments@w3.org <mailto:public-webcrypto-comments@w3.org>
>>>      Subject: Re: draft for certificate management
>>>
>>>
>>>      Le 04/03/2013 13:04, Harry Halpin a écrit :
>>>      > Also, when writing the spec try to determine if you could use the
>>>      > low-level API to build what parts, and what other parts would need
>>>      > some level of access to browser internals. Some features could be done
>>>      > in a library on top of the Crypto API I hope.
>>>
>>>      Of course!!! It has to use/extend the low-level API, the example I am giving can only be a real world example facilitator.
>>>
>>>      Regards
>>>
>>>      Aymeric
>>>
>>>      --
>>>      jCore
>>>      Email :  avitte@jcore.fr <mailto:avitte@jcore.fr>
>>>      iAnonym : http://www.ianonym.com
>>>      node-Tor : https://www.github.com/Ayms/node-Tor
>>>      GitHub : https://www.github.com/Ayms
>>>      Web :    www.jcore.fr <http://www.jcore.fr>
>>>      Webble : www.webble.it <http://www.webble.it>
>>>      Extract Widget Mobile : www.extractwidget.com <http://www.extractwidget.com> BlimpMe! : www.blimpme.com <http://www.blimpme.com>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -- 
>>> 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 Friday, 29 March 2013 11:22:15 UTC