W3C home > Mailing lists > Public > public-webcrypto-comments@w3.org > January 2013

Re: Prioritization of secondary features

From: Aymeric Vitte <vitteaymeric@gmail.com>
Date: Thu, 31 Jan 2013 16:53:18 +0100
Message-ID: <510A936E.5050203@gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
CC: Ryan Sleevi <sleevi@google.com>, Harry Halpin <hhalpin@w3.org>, Mountie Lee <mountie.lee@mw2.or.kr>, public-webcrypto-comments@w3.org
I don't know what examples were given before and your replies, but the 
two last examples I gave have nothing to do with double-checking 
certificates against browser's checks, we just need to retrieve them for 
other checks.

Regards

Le 31/01/2013 16:37, Eric Rescorla a écrit :
> FWIW, I agree with Ryan.
> There no doubt are scenarios in which certificate processing functionality
> is useful in JS on the client, but I don't believe that double-checking
> that the browser has correctly evaluated the certificate chain is one of
> them, for the security reasons Ryan and I have both argued before.
> (Of course, whether that means that the processing needs to be in
> the browser is yet another story).
>
> At this time, I don't see sufficient use cases to add a new pile of 
> complexity
> to a draft which is already quite complex. Moreover, certificate 
> verification
> is conceptually quite different, so deserves to be in a separate spec in
> any case.
>
> -Ekr
>
>
> On Thu, Jan 31, 2013 at 6:29 AM, Ryan Sleevi <sleevi@google.com 
> <mailto:sleevi@google.com>> wrote:
>
>     Harry,
>
>     Surely when you said "put in the spec" you meant "put in a spec" -
>     that is, some other spec entirely. Right?
>
>     Because I absolutely positively do not see anything like this
>     making it in to our current work - both for reasons of interest (I
>     have explained several times the problems with what is being
>     asked) and for reasons of complexity.
>
>     On Jan 31, 2013 5:46 AM, "Harry Halpin" <hhalpin@w3.org
>     <mailto:hhalpin@w3.org>> wrote:
>
>         On 01/31/2013 01:57 PM, Aymeric Vitte wrote:
>>         Hi,
>>
>>         I think it's not in your list, then I would add :
>>
>>         "Exposing the server certificate (possibly structured, if not
>>         we'll need a bullet-proof, signed, X.509 library) and path of
>>         the TLS connection as JavaScript objects."
>>         (http://www.w3.org/2012/webcrypto/wiki/Use_Cases#Miscellaneous)
>>
>>         I have given examples already why it's needed [1], see
>>         another use case here [2] chapter 4.2 (and [3] for more
>>         details - the client identifies the server by checking that
>>         the pub_key used in the TLS handshake matches the
>>         certified_key received from the server in CERTS messages,
>>         where the certified_key is the pub_key signed with the
>>         id_priv_key of the server and therefore verified with its
>>         public id_pub_key)
>
>         What is missing from these proposals is concrete,
>         well-specified proposals. In other words, WebIDLs that we
>         could put in the spec. Also, implementers would have to agree
>         its reasonable to implement this functionality within the
>         current WG's timeframe.
>
>         So, please specify some example code!
>
>            cheers,
>              harry
>
>>
>>         Regards,
>>
>>         [1]
>>         http://lists.w3.org/Archives/Public/public-webcrypto-comments/2012Nov/0037.html
>>         [2]
>>         https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=tor-spec.txt
>>         [3] http://archives.seul.org/or/dev/Jan-2011/msg00052.html
>>
>>         Le 31/01/2013 02:17, Mountie Lee a écrit :
>>>         Hi.
>>>         at WebCrypto WG Charter
>>>         (http://www.w3.org/2011/11/webcryptography-charter.html)
>>>         following secondary features are listed.
>>>
>>>           * control of TLS session login/logout
>>>           * derivation of keys from TLS sessions
>>>           * a simplified data protection function
>>>           * multiple key containers
>>>           * key import/export
>>>           * a common method for accessing and defining properties of
>>>             keys
>>>           * the lifecycle control of credentials such enrollment,
>>>             selection, and revocation of credentials with a focus
>>>             enabling the selection of certificates for signing and
>>>             encryption
>>>
>>>         as discussed in previous concall,
>>>         we need to set priority for secondary features.
>>>
>>>         I feel certificate related features has more priority than
>>>         others.
>>>         also TLS related features also have relationship with
>>>         certificates.
>>>         so with my view, I listed following certificate related
>>>         secondary features
>>>
>>>           * certificate enrollment
>>>               o this is different from key generation
>>>               o CMP can be considered.
>>>           * certificate validation
>>>               o certificate chain validation
>>>               o CRL or OCSP validation
>>>           * certificate selection with binded private key
>>>               o has UI related requirement
>>>           * access certificate extension fields
>>>               o including optional fields
>>>           * multi-origin crypto operation with certificate associated.
>>>           * control of TLS session login/logout
>>>           * derivation of keys from TLS sessions.
>>>
>>>         any comments?
>>>
>>>         regards
>>>         mountie.
>>>
>>>         -- 
>>>         Mountie Lee
>>>
>>>         PayGate
>>>         CTO, CISSP
>>>         Tel : +82 2 2140 2700 <tel:%2B82%202%202140%202700>
>>>         E-Mail : mountie@paygate.net <mailto:mountie@paygate.net>
>>>         =======================================
>>>         PayGate Inc.
>>>         THE STANDARD FOR ONLINE PAYMENT
>>>         for Korea, Japan, China, and the World
>>>
>>>
>>>
>>>
>>
>>         -- 
>>         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>
>
>

-- 
jCore
Email :  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
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
Received on Thursday, 31 January 2013 15:50:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 31 January 2013 15:50:51 GMT