- From: Aymeric Vitte <vitteaymeric@gmail.com>
- Date: Thu, 31 Jan 2013 16:37:37 +0100
- To: Harry Halpin <hhalpin@w3.org>
- CC: Ryan Sleevi <sleevi@google.com>, Mountie Lee <mountie.lee@mw2.or.kr>, public-webcrypto-comments@w3.org
- Message-ID: <510A8FC1.8020300@gmail.com>
Ryan, you did answer once that my examples were dubious but did not really consider my last answer [1] below. That's not a webIDL spec but a concrete example is here [4]. Another example is [3] below if the client is the browser (using wss) A common point is that you might not trust the browser's checks and/or (are not using)/(can not) use valid certificates and/or do not trust a site, but there might be some other uses, I have seen on the web some posts from people requesting it and it was put in your Use cases chart far before I mentioned it. But indeed, it's complicate to specify, so instead of a debate let me try to put something together and let's see. Harry, what do you mean by "very soon"? Regards, [4] http://www.ianonym.com see Details section Le 31/01/2013 15:35, Harry Halpin a écrit : > On 01/31/2013 03:29 PM, Ryan Sleevi wrote: >> >> Harry, >> >> Surely when you said "put in the spec" you meant "put in a spec" - >> that is, some other spec entirely. Right? >> > > We haven't officially closed scope there, so it could go in a number > of specs - for example, I would be open here to a separate > "certificate spec" if someone stepped forward to draft it AND > implementers actually implemented it. If no-one implemented it, it > could be put out as a non-normative WG note for future work. >> >> 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. >> > > I think the problems are likely solvable for future work (I see no a > priori why certificate related features are impossible per se). > > Howver, people (not you obviously, as you have more pressing and > foundational issues to deal with rather than secondary features as > editor) actually need to explain what they want in detail and provide > use-case text, WebIDLs and ideally even implementation code-patches. > But they have to do so very soon, as otherwise this will all > definitely go out of scope in *any* spec or note due to timing > considerations. > > And in the end, as you correctly point out, if its too complex to be > implemented then its not going to happen in a spec. Yet the first step > is to at least draft what is imagined to be implemented. > >> 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:35:14 UTC