- From: Hutchinson Michael <Michael.Hutchinson@gemalto.com>
- Date: Tue, 21 May 2013 20:43:20 +0200
- To: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>, Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>
- CC: 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>
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:50:12 UTC