On Tue, Dec 2, 2008 at 8:46 PM, Luke Faraone <[EMAIL PROTECTED]> wrote: > On Tue, Dec 2, 2008 at 17:42, Martin Langhoff <[EMAIL PROTECTED]> > wrote: >> >> If we could switch to https easily, we could skip all this song and >> dance and just use client certs. > > Why can't we, exactly? More and more non-standardness is _bad_ for security.
Note that this won't be 200% bulletproof -- we're talking about a brief reasonably secure exchange prefacing a naked http conversation. We may later use https a bit more, but it's way overkill for now. So we are aiming for moderate security. Also note that OpenID is in the conversation, and that is _not_ a particularly secure protocol (see the archive, and the many _many_ very good posts from Ben Laurie here and on his blog on the matter). OpenID is somewhat standard though ;-) Back to your good question > Why can't we, exactly? [ Note - this is, again, fruit of a lot of analysis and discussion. I cannot write a huge long essay on each little point - if you wonder why a particular point is made, it might be worthwhile a quick google over the archives... let's avoid shallow conversation ;-) ] To use client certs, we have to use server certs. As I mentioned in earlier emails, at registration time, the XO gives the XS its pubkey. The XS gives _nothing_ to the XO. a - we need a server cert - the XS upon installation can generate one. How do we pass it to the XO so it can whitelist it and avoid the "dodgy cert" dialogues that mean nothing to a 6 year old? (Registration? see my notes below) - the XS could be preloaded with a trusted cert that OLPC distributed - if they all get the same cert, anyone can impersonate an XS at any time. If we push it to regional certs, it generates a lot of additional work for the deployment team (remember - the deployment team is usually 3~4 admins to 5K or more XSs, half of which have no internet connection). b - the XO needs to trust the XS's cert - - trust a cert received at registration? (yes, but see below...) - get it via PKI (a ton of infrastructure work, not worthwhile for moderate security) - get it whitelisted directly in the OS image - if all XSs have the same cert. - trust any cert? Woes of changing the registration process... Yep, probably the best solution is to change the reg process. However that means a lot of changes, and it means that this will require 9.1 And it's very important that we do this in a way that can be deployed on 8.2 . Many large deployments are going ahead with 8.2 soon and may not deploy 9.1 for a very long time. OTOH, they have easier means to deploy an updated Browse.xo, and may be even waiting for 8.2.1 If we are to change the protocol for 9.1 we need to - Change things on the XS and on the XO (yes) - Add a "refresh/update" registration mechanism - which we don't have now - Think carefully how we are going to support interop between old clients / new server and viceversa. Add that to the test matrix (ouch!). luckily, the protocol is a trivial xml-rpc. But getting it all done with good polish (think "what would Apple do?") is not. cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff _______________________________________________ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar