Re: draft for certificate management

I think this is important.

if server decide to give ownership of key to user,
the keys should be protected from any approaches of servers or 3rd party
with PIN or other similar mechanism.

current API design principle is based on
- keys are owned by provisioner (normally server)
- keys is bound to specific origin.

beside origin bound key issue,
the provisioner (as the server) will be able to decide giving key ownership
to user.
after user has key ownership, the key should be out of control of server at
any case.



On Wed, May 22, 2013 at 3: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
>
>
>
>
>
>
>
>


-- 
Mountie Lee

PayGate
CTO, CISSP
Tel : +82 2 2140 2700
E-Mail : mountie@paygate.net

=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World