Re: Certificates

On 2013-03-15 10:53, Aymeric Vitte wrote:
> 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?

In a nutshell, there haven't been any past discussions about certificates in the _WG_
because the _WG_ has rightly or wrongly (take your pick), pushed this forward.

Successful standardization efforts are practically without exceptions based on a
predecessor, industry standard or conceptual design.  For the phase one deliverable
this was David Dahl's DOMCrypt.

For the secondary phase there's nothing.   Creating "something" out of pure vacuum
is a doomed mission, particularly for a bunch of fierce competitors.

Anders


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

Received on Friday, 15 March 2013 12:02:09 UTC