RE: draft for certificate management

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