Re: draft for certificate management

On 2013-05-21 20:43, Hutchinson Michael wrote:

Based on the WG-list I think it is fair to say that there's no interest among the
_browser_vendors_ for supporting traditional use-cases through Web Crypto.

I'm sure some of them will do that anyway but through proprietary solutions since
this topic simply fell of the W3C table.

Anders


> 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 19:07:57 UTC