- 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