Re: Prioritization of secondary features

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>
>