Re: Webcrypto - project example (and issues)

Thanks for your answer, I missed the secondary features description. 
Indeed certificate validation could be self-implemented, but it is still 
interesting to get it into the API, so you don't have to maintain or 
load ca/revocation lists and/or you don't depend on third party modules 
potential weaknesses.

Indeed for some project like mine there is no way for security purposes 
to load things outside (modules, lists, even revocation checks I 
believe, etc), but then of course the side effect is that you need to 
trust the API and the browser, please take a look too at my answer to 
Lee. Polyfilled modules then need to be included into the code making it 
heavier and more difficult to maintain against API use.

Naive question maybe but does someone has an idea when at least primary 
features will be implemented into major browsers ?

Le 15/11/2012 23:44, Ryan Sleevi a écrit :
> On Wed, Nov 14, 2012 at 9:58 AM, Aymeric Vitte <vitteaymeric@gmail.com> wrote:
>> The draft project is here : http://www.ianonym.com, the "details" section
>> are not specs but a summary, this is an extension inside the browser of
>> https://github.com/Ayms/node-Tor which is a js implementation over node.js
>> of the Tor project.
>>
>> Assuming that the concept works (it seems to on the paper and from some
>> experimentations I made), here is what is needed accessible with js inside
>> the browser and the status today :
>>
>>      - mix node.js Buffers and Typed Arrays --> OK, home made
>>      - URL parser --> OK, home made
>>      - HTTP parser --> OK, home made
>>      - self signed certificates generation (OP) --> NOK
>>      - certificates verification (OP) --> NOK
>>      - implement TLS protocol (OP, inside websockets, both client and server
>> side) --> NOK
>>      - retrieve the certificate used for the first TLS connection between the
>> page and the OP (Evil1 attack) --> NOK
>>      - implement Tor protocol and Tor protocol websocket extension (OP,
>> inside websockets) --> OK, home made
>>      - Webcrypto like features (hash, encrypt, decrypt, rsa, aes, etc),
>> including Tor specific ones (RSA_PKCS1_OAEP_PADDING, aes-128-ctr) --> NOK
>> (or OK with Webcrypto API but when ?)
>>
>> Beside the overall technical difficulty, one of the problems is not to end
>> up with something obsolete (like most of existing js crypto libraries that
>> are not using Typed Arrays) or not to reinvent what will exist tomorrow.
>>
>> And of course, implementing all of this in js will not be efficient, it
>> should better be part of a standard trustable web api.
>>
>> Even if Webcrypto API was already implemented, we see here that a lot of
>> things are still missing for this project. I don't know if it is so
>> specific, probably people will have some equivalent ideas of use with or
>> without websockets.
>>
>> Unfortunately I did not see other webapis projects implementing for example
>> certificates, TLS protocol. Therefore, maybe it should be considered to
>> extend Webcrypto so it does cover the full chain needed for TLS/SSL
>> communications and crypto tools manipulations (unless you are aware that
>> this does or will exist elsewhere as a standard).
> Thank you for your feedback. I may not be clear on everything you are
> asking, but I think I understood enough to respond.
>
> Our charter ( http://www.w3.org/2011/11/webcryptography-charter.html#scope
> ) lists SSL/TLS related functionality as secondary API features that
> *may* be in scope. As noted in the scope, secondary API features are
> just that - secondary to the primary features, and may be implemented,
> if time and interest (from implementers and members) exist. So they
> may be addressed in the future.
>
> As mentioned on other threads, speaking as an implementer, there is
> presently not significant interest in providing certificate validation
> APIs. However, with the current API and primary features, a JS
> application could, if it desired, implement its own certificate
> validation with its own trust anchor management (signature
> verification for X.509 certs is just signature verification). So you
> can certainly have libraries evolve that permit and enhance that - and
> can even do so today, using polyfilled crypto.

-- 
jCore
Email :  avitte@jcore.fr
Web :    www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com

Received on Friday, 16 November 2012 09:27:38 UTC