Re: please review table of contents for web certificate API Specification

Mountie,

Maybe you forgot to copy the list... I will look at the document

Anders,

Yes things are already available if you want to create your own 
certificate stuff, but what's the problem with having an API designing 
this instead of everybody making his own ?

And the server can be inside the browser too, example : [1] Interception 
Detector, for those that might find this dubious that's not a 1st of 
April joke :-) , I don't know the efficiency in reality but for sure it 
will detect if there is someone in the middle, the browser does create 
certificates and establish TLS connections with himself via a server on 
top of Websockets, see [2] and email me separately if you want to try 
it, funny to see what browsers do again, for example Chrome if you use 
abcd.google.com thinking that you are trying to do bad things to google 
and not allowing it.

Regards,

[1] http://www.ianonym.com/intercept.html
[2] http://www.ianonym.com/check-min.html

Le 01/04/2013 08:43, Anders Rundgren a écrit :
> On 2013-04-01 02:14, Mountie Lee wrote:
>> Hi.
>> before going futher,
>> I need comment for table of contents for Web Certificate API Specification
> Hi Mountie, although I'm qualified as a reviewer it seems that people don't
> like my ideas on certificate enrollment because I was _thrown_out_ (!) from the
> IETF PKIX list when I criticized http://tools.ietf.org/wg/pkix/draft-ietf-pkix-est
>
> The core motive for EST was keeping the ASN.1 constructs engineers know, not making
> client-side PKI a better solution.  For me keeping PKCS #10 is a non-goal. In addition
> Apple's _shipping_solution_ (XML bootstrap + SCEP) for iOS is _much_better_ than EST.
>
> _Your_ stated motivation is keeping the existing RA/CA interface.  IMO, that's
> fine but it won't make client certificates more useful because these interfaces where
> _not_ designed for direct provisioning to "ordinary" end-users using web-browsers.
>
> If you don't mind here are some high-level comments on the draft:
>
> - Revocation.  Is an RA function and doesn't make sense in a client
>    (you rather call the bank and say that you lost the card)
>
> - Targeting existing TLS solutions _and_ the Web Crypto API. This is
>    where I get completely lost :-(
>
>    The Web Crypto API already have key generation and key storage; adding
>    a returned certificate wouldn't require any additional API you would
>    rather use IndexDB storage.
>
>    Targeting the existing TLS solution means using the "platform keystore".
>    Since I have already spent 5000 hours and 5 years on this topic I think
>    we are talking about something which is _extremely_hard_ from every possible
>    point-of-view (political, technical, commercial, privacy, security etc).
>    There are also a bunch pf "patent trolls" waiting for a chance to sue
>    Google or Microsoft if they start using methods which _I_ claim are
>    _necessary_ such as "Secure Messaging".  Ryan knows that for sure:
>
> http://lists.w3.org/Archives/Public/public-webcrypto-comments/2013Mar/0074.html
>
>    My take on this is developing a scheme with _Chinese_makers_ because they
>    are not bound by US patents.   Their internal market + Asia + Africa +
>    South America pretty much offsets the "old world" (Europe) and the
>    "new world" (USA) which probably won't get a working certificate
>    solution this decade unless IPR-holders give up their rights.  That
>    Mozilla still don't dare providing ECC support sort of says it all.
>
> Returning to the core again: I don't see that you actually _can_ target
> Web Crypto key storage _and_ platform/PKCS #11 storage without running
> into very severe GUI, privacy and security issues.
> The Web Crypto WG have shown no interest in discussing this topic.
>
> Best
> Anders
>
>> the contents are extracted by WG charter and email comments.
>>
>> please comment any missing parts or different what you think.
>>
>> this mail is unofficial
>>
>> regards
>>
>> Web Certificate API Specification
>> http://mountielee.github.com/webcertapi/webcertapi.html
>>
>>
>> -- 
>> Mountie Lee
>>
>> PayGate
>> CTO, CISSP
>> Tel : +82 2 2140 2700
>> E-Mail : mountie@paygate.net <mailto: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

Received on Monday, 1 April 2013 10:14:36 UTC