[sugar] XO identity shared via Browse

[Martin Langhoff]

On Tue, Dec 2, 2008 at 8:46 PM, Luke Faraone <luke at laptop.org> wrote:
> On Tue, Dec 2, 2008 at 17:42, Martin Langhoff <martin.langhoff at gmail.com>
> 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
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff