Re: Certificates

Anders,

Sorry, I still don't get it, I don't see what is so extraordinary with 
specifying certificates format and manipulations at UA level in an API, 
why "secondary" would mean partially or wrongly designed while I guess 
it should be understood as "based on the low and/or high level API", why 
a major company would specify this better while everybody is already 
around the table here, why PKI general issues should influence, what the 
specific Netflix use case has to do with this, what is the difference 
with smart cards and why the certificate should just be a "blob" stored 
in "indexDB".

Probably missing some past discussions, what is so magical or mysterious 
with certificates?

Regards,

Aymeric


Le 15/03/2013 05:01, Anders Rundgren a écrit :
> On 2013-03-14 22:08, Aymeric Vitte wrote:
>> Le 14/03/2013 20:48, Jeffrey Walton a écrit :
>>> Be careful here. We know PKI with Internet profiles (PKIX) has
>>> problems in practice.
>>>
>>> In the big picture, a certificate or public key (with its
>>> corresponding private key) is how we identify folks. Making
>>> certificate and public key management a secondary goal may have the
>>> unintended effect of leaving gaps in authentication.
>> Le 14/03/2013 20:48, Jeffrey Walton a écrit :
>>> (courtesy of PKIX and Public CAs) coupled with lack of client
>>> capabilities.
>> Le 14/03/2013 20:48, Jeffrey Walton a écrit :
>>> Since you can't fix PKI, you have to improve client capabilities.
>> Maybe I am missing the point but what do you mean exactly for the three
>> points above?
> Aymeric et al,
>
> The WG has operated for over a year without getting a single bit closer to defining what they envision in terms of certificate support.  Some people still believe there is a pot of gold called second phase deliverables.
>
> Based on the existing certificate support in the platforms that will run the Web Crypto API, I would be surprised if that actually happens, since the abysmal foundations would still shine through.
>
> My guess is that the market-leader (probably Google) will define a working credential platform that W3C, years later, will formalize as a standard in a "rubber-stamping" process like ISO did with MS-Office XML.
>
> If you look into the Netflix use-case, it IMO doesn't have a place in the Web Crypto standard since it builds on using specifically "prepared" devices. In fact, a minor patch in the key-discovery part of a Web Crypto implementation would work right out-of-the-box without any additions.
>
> Summary: standardization has it possibilities and limitations.  The wast majority of security standard efforts fail.
>
> By keeping Web Crypto tight and neat, Ryan & Co has a very good chance succeeding.
>
> Anders
>
>
>> Regards,
>>

-- 
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 Friday, 15 March 2013 09:56:19 UTC