- From: Ryan Sleevi <sleevi@google.com>
- Date: Tue, 21 May 2013 11:53:23 -0700
- To: Hutchinson Michael <Michael.Hutchinson@gemalto.com>
- Cc: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>, Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>, Anders Rundgren <anders.rundgren@telia.com>, Aymeric Vitte <vitteaymeric@gmail.com>, Mountie Lee <mountie.lee@mw2.or.kr>, GALINDO Virginie <Virginie.GALINDO@gemalto.com>, "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>, Harry Halpin <hhalpin@w3.org>
Michael, I would suggest such conversations are out of scope from our charter. In part, because they are concepts that do not map beyond a single API. Cheers, Ryan On Tue, May 21, 2013 at 11:43 AM, Hutchinson Michael <Michael.Hutchinson@gemalto.com> wrote: > Vijay, > > As the keys belong to the server application; it could be desirable for the server application to "silently" pass the PIN through the WebCrypto API to the UA so they don't have to rely/wait on a user prompt. e.g. CryptSetProvParam(PP_KEYEXCHANGE_PIN | PP_SIGNATURE_PIN) > > Another use case would be for the server application to provide its own PIN entry dialog rather than relying on the UA to do this. e.g. Window logon (Winlogon/LogonUI) > > This would mean a change in the specification to allow the PIN through for private operations. > > This would equally apply to keys on a smart card, in a password-protected software-based KSP, or password-protected keystore. > >>Michael > >> -----Original Message----- >> From: Vijay Bharadwaj [mailto:Vijay.Bharadwaj@microsoft.com] >> Sent: Tuesday, April 02, 2013 4:07 AM >> To: Nick Van den Bleeken >> Cc: Anders Rundgren; Aymeric Vitte; Mountie Lee; GALINDO Virginie; public- >> webcrypto-comments@w3.org; Harry Halpin >> Subject: RE: draft for certificate management >> >> I agree. In that case, wouldn't you say that the current API has support >> for PIN-protected keys? The UA just needs to prompt for the PIN when it >> performs a private key operation. >> >> -----Original Message----- >> From: Nick Van den Bleeken >> [mailto:Nick.Van.den.Bleeken@inventivegroup.com] >> Sent: Tuesday, April 2, 2013 2:03 AM >> To: Vijay Bharadwaj >> Cc: Anders Rundgren; Aymeric Vitte; Mountie Lee; GALINDO Virginie; public- >> webcrypto-comments@w3.org; Harry Halpin >> Subject: 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? >> In my opinion it is the responsibility of the API to prompt for the PIN, >> because the application should not have access to the PIN. >> >> Kind regards, >> >> Nick Van den Bleeken >> >> > >> > -----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 >> >>>> >> >>>> >> >>>> >> >>>> >> >> >> > >> > >> > >> > >> > >> >> >> ________________________________ >> >> Inventive Designers' Email Disclaimer: >> http://www.inventivedesigners.com/email-disclaimer > >
Received on Tuesday, 21 May 2013 18:53:55 UTC