- From: Mark Watson <watsonm@netflix.com>
- Date: Thu, 31 Jan 2013 15:44:20 +0000
- To: Harry Halpin <hhalpin@w3.org>
- CC: Aymeric Vitte <vitteaymeric@gmail.com>, Mountie Lee <mountie.lee@mw2.or.kr>, "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>
- Message-ID: <ED8B4113-C620-4A78-B220-45A58E6124AF@netflix.com>
Sent from my iPhone On Jan 31, 2013, at 5:47 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. I believe the above should be the criteria for prioritization and so key import/export (which are already partially included in the spec) and key wrap/unwrap (for which we have a detailed proposal and a high probability of implementation) should go ahead. ... Mark 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 * this is different from key generation * CMP can be considered. * certificate validation * certificate chain validation * CRL or OCSP validation * certificate selection with binded private key * has UI related requirement * access certificate extension fields * 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 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>
Received on Thursday, 31 January 2013 15:44:50 UTC