Re: draft for certificate management

On 2013-04-02 10:35, Vijay Bharadwaj wrote:
>> 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?

I think I have provided you earlier with such information.  But it surely represents _my_ take on the subject.
I don't know anything about Microsoft's, Google's or Mozilla's feelings concerning PINs.


>  Must it necessarily include tools for PIN provisioning and management?

Absolutely.


> Why can't the API just prompt the user for PINs inside the private key operation?

It should indeed do that but the question as I see it is: Which PIN?  How did it "landed" on the key?

Anders

> 
> -----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 10:20:39 UTC