Re: Prioritization of secondary features

On Thu, Jan 31, 2013 at 7:53 AM, Aymeric Vitte <vitteaymeric@gmail.com>wrote:

>  I don't know what examples were given before and your replies, but the
> two last examples I gave have nothing to do with double-checking
> certificates against browser's checks, we just need to retrieve them for
> other checks.
>

The example you provide in your previous message:
"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."

Appears to be exactly double-checking the browser.

Do you have a concise description (i.e., not a link to a paper) of some use
case that
doesn't have the property that it simultaneously trusts and distrusts the
browser's
cert checking?

-Ekr



> Regards
>
> Le 31/01/2013 16:37, Eric Rescorla a écrit :
>
> FWIW, I agree with Ryan.
>
> There no doubt are scenarios in which certificate processing functionality
> is useful in JS on the client, but I don't believe that double-checking
> that the browser has correctly evaluated the certificate chain is one of
> them, for the security reasons Ryan and I have both argued before.
> (Of course, whether that means that the processing needs to be in
> the browser is yet another story).
>
>  At this time, I don't see sufficient use cases to add a new pile of
> complexity
> to a draft which is already quite complex. Moreover, certificate
> verification
> is conceptually quite different, so deserves to be in a separate spec in
> any case.
>
>  -Ekr
>
>
> On Thu, Jan 31, 2013 at 6:29 AM, Ryan Sleevi <sleevi@google.com> wrote:
>
>> Harry,
>>
>> Surely when you said "put in the spec" you meant "put in a spec" - that
>> is, some other spec entirely. Right?
>>
>> 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.
>>  On Jan 31, 2013 5:46 AM, "Harry Halpin" <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
>>>       - 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
>>>
>>> =======================================
>>> PayGate Inc.
>>> THE STANDARD FOR ONLINE PAYMENT
>>> for Korea, Japan, China, and the World
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> 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
>>>
>>>
>>>
>
> --
> 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
>
>