Re: W3C Web Identity Standardization Woes

On Feb 8, 2012, at 11:20 PM, Anders Rundgren wrote:

> On 2012-02-09 02:04, Henry B. Hotz wrote:
>> On Feb 8, 2012, at 11:50 AM, Anders Rundgren wrote:
>>> Anyway, I let you continue with whatever you do in peace; I stick to
>>> the Open Source/Hardware route and skip standardization.  
>> I'm honestly not trying to be hostile, but if this is how you feel why are you here?
> Well, I started by attending the workshop in May 2011.  After that
> a bunch of interesting but completely unrelated "web identity"
> initiatives surfaced which made me come to the conclusion that this
> isn't for me at least.

That explains how you got here, but not why you're staying.  You seem to irritate some people and confuse a lot of others (myself included).  IIUC the purpose of this list is to help craft standards.  If you don't believe in standards, then what are you trying to accomplish here?

>>> There are
>>> no surefire successes in this space and I wish you luck.


>>>>> On 02/08/2012 06:30 AM, Anders Rundgren wrote:
>>>>>> IMO smart
>>>>>> cards using non-domain-restricted credentials such as PIV must not be exposed
>>>>>> on the web; they can only be used by trusted applications such as TLS.
>>>>>> Anders
>> I have absolutely no idea what you are trying to say here. 
> Well, from the discussions 2011 it seems that you are not alone :-(
> If you take a look a Microsoft's CertEnroll you have a system which
> is broken due to a misunderstood web security and privacy concept.

There's an unfortunate amount of stuff which is broken because the designers did not understand the underlying trust model they were using.

> 1) I'd hardly call TLS a "trusted application";
> The TLS code is supplied by the browser vendor which differs in
> trustworthiness from arbitrary transient code from a web-site.

OK, the browser is an application which implements the TLS protocol.  The other un-trusted applications you're referring to are web-apps.  True?

> 2) A PIV card is a well-defined client credential, with good security properties.
> Yes, but if you let arbitrary web code access it you won't be able
> maintaining these properties.

So, IIUC you are concerned that a web crypto standard would provide free and open access to the client identity and use of its private key.

> Obviously, if someone can *otherwise* break in to the machine it's 
>> plugged into, it can be at least temporarily hijacked.
>> Is that what you mean by "exposed on the web"?
> No, see above.

My interpretation of your earlier answers suggests "yes".  If a JavaScript crypto extension allowed arbitrary downloaded JavaScript "free and open access to the client identity and use of its private key", then it would inherently be a way to "*otherwise* break in to the machine".

As they said on Ghostbusters, that would be "bad".

I'm not hard over that it would necessarily always be bad, but would need some serious convincing that restrictions are strong enough and simple enough to be effective.
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government., or

Received on Tuesday, 14 February 2012 06:49:18 UTC