Re: Hello world

On 26 Nov 2011, at 18:04, Ron Garret wrote:

> Hello,
> 
> I'm late to this party and I'm still working on coming up to speed on the group's progress so far, but I wanted to come out of lurker mode and introduce myself.  

I’m in a similar position, so I thought I’d take this opportunity.

I’ll start by saying that crypto in Javascript sets alarm bells ringing for me, but I’m less concerned about native implementations of crypto primitives than I am about implementing crypto *in* Javascript (which to be frank, gives me the willies). This does raise issues with respect to graceful degradation — what do you do when the native primitives aren’t available? (I don’t know the answer).

My hit-list of issues in this arena runs like this:

> 4.  Client-side certificates are very nice technology (but see the next point), but the UI renders them virtually unusable, and hence almost entirely unused.  This is a shame.


This is #1 on my list. In fact, the entire set of UIs around certificates (client *and* server) are a complete bust, but I’m more concerned about client certs — particularly self-issued client certs — than I am server certs.

> 5.  The CA infrastructure is a pain in the ass to use, and it's starting to get pretty creaky from a security point of view.  With over 200 root CA's there are an awful lot of potential points of failure.  We've already seen some near-misses.  It wold probably be prudent to have a replacement ready to deploy BEFORE the current system actually collapses.

#2 for me. CA-issued client certs haven't happened outside of some very specific and niche applications (which most of, to be honest, don't actually need CA-issued certs anyway — policy-driven key-generation and validating the key itself would work just fine). On the server side, where this stuff is actually being used, the cracks are even more apparent. EV is a band-aid on a broken arm here. There is, I suspect, a whole heap of research/prototyping to be done around aggregate trust indicators drawing on social networking connections (though what's really screwing up the CA model is the “trust us, we’re your national telco!” CCITT-of-yore holdover which means that trust, assurance, identification and connection-level security get bundled up with one another even more than seems necessary).

I don't have a problem with X.509 or TLS themselves, just the process and policy stuff that's been heaped around them. Strip it down to the useful technical stuff and build up an architecture that works (before you ask: no, I’m not 100% sure what that is yet).

3. I have scenarios where there's an HTTPS front-end server or two talking to a back-end server and the two need to share auth, but shouldn't share a credentials database — i.e., a client cert gets presented to the front-end, and somehow it needs to pass this on to the back-end server. A means for this to happen which doesn't involve inherently trusting the front-end would make my life a lot simpler (don't assume the front- and back-end servers are operated by the same people).

4. Exploration of UIs and related extensions for uploading X.509 attribute certificates via HTML forms: that is, a server can provide an “Please provide a form of ID” <input> and the browser will present a native UI for selection/unlock, with the server able to specify (with the aid of attributes on the element) how it should be filtered, including:

- A list of authorities who must have issued the certs used to sign the assurance document
- A list of OIDs of assurance claim types
- (Implicitly) contains the public key matching that presented to the site for identification

Supporting this would allow assurance exchange in a relatively un-complicated fashion, satisfying the “Provide proof of your employment”, “Provide evidence from your utility company or bank that this is your address” real-world style of assurance, which currently relies on faxing(!) or scanning paper equivalents…

All the best,

Mo.

-- 
Mo McRoberts - Technical Lead - The Space,
0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E,
Project Office: Room 7083, BBC Television Centre, London W12 7RJ

Received on Sunday, 27 November 2011 01:12:35 UTC