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

Re: Prioritization of secondary features

From: Aymeric Vitte <vitteaymeric@gmail.com>
Date: Thu, 31 Jan 2013 16:37:37 +0100
Message-ID: <510A8FC1.8020300@gmail.com>
To: Harry Halpin <hhalpin@w3.org>
CC: Ryan Sleevi <sleevi@google.com>, Mountie Lee <mountie.lee@mw2.or.kr>, public-webcrypto-comments@w3.org
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 31 January 2013 15:35:15 GMT