- From: Aymeric Vitte <vitteaymeric@gmail.com>
- Date: Thu, 31 Jan 2013 16:53:18 +0100
- 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
- Message-ID: <510A936E.5050203@gmail.com>
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 UTC