Re: Prioritization of secondary features

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