- From: Anders Rundgren <anders.rundgren@telia.com>
- Date: Fri, 29 Mar 2013 09:55:39 +0100
- To: Mountie Lee <mountie.lee@mw2.or.kr>
- CC: GALINDO Virginie <Virginie.GALINDO@gemalto.com>, Aymeric Vitte <vitteaymeric@gmail.com>, Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>, "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>, Harry Halpin <hhalpin@w3.org>
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 08:56:19 UTC