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

Re: Prioritization of secondary features

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:

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!



[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 :
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?


Mountie Lee

Tel : +82 2 2140 2700
E-Mail : mountie@paygate.net<mailto:mountie@paygate.net>

PayGate Inc.
for Korea, Japan, China, and the World

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:12:49 UTC