Re: draft for certificate management

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