RE: draft for certificate management

> 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_.

What does API support for PINs look like to you? Must it necessarily include tools for PIN provisioning and management? Why can't the API just prompt the user for PINs inside the private key operation?

-----Original Message-----
From: Anders Rundgren [mailto:anders.rundgren@telia.com] 
Sent: Friday, March 29, 2013 4:22 AM
To: Aymeric Vitte
Cc: Mountie Lee; GALINDO Virginie; Nick Van den Bleeken; public-webcrypto-comments@w3.org; Harry Halpin
Subject: 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 Tuesday, 2 April 2013 08:36:24 UTC