- From: Anders Rundgren <anders.rundgren@telia.com>
- Date: Mon, 01 Apr 2013 14:05:55 +0200
- To: Aymeric Vitte <vitteaymeric@gmail.com>
- CC: Anders Rundgren <anders@primekey.se>, Mountie Lee <mountie@paygate.net>, Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>, "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>
On 2013-04-01 12:16, Aymeric Vitte wrote: > Mountie, > > Maybe you forgot to copy the list... I will look at the document Actually Mountie wanted to perform a _limited_review_ by people he felt could be useful. I think that was good idea. Now it is "unlimited"... > > 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 ? If you look closely on my reply to Mountie, I noted that he is also targeting the system/platform/browser keystore. This is (AFAICT...), _way_ outside of the Web Crypto agenda and that's more significant than if storing certificates in IndexDB is quirky compared to a high-level Web Crypto method doing something similar. Anders > > 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 >>> >>> >>> >
Received on Monday, 1 April 2013 12:06:44 UTC