W3C Web Identity Standardization Woes

Anders,

Again, if you believe in your below statements, I kindly suggest you
join another mailing list. Furthermore, there is no new information in
your email, just the same opinion you re-iterated earlier a number of times.

cheers,
harry

Post by Anders Rundgren
http://www.w3.org/2011/08/webidentity-charter.html
I hope you don't get too upset but I believe the last 12 months have shown that
standardization of security and identity solutions on the web, particularly for
schemes that introduce changes in the client-platform, is more or less infeasible.
Why is that? The interest in cooperating among the very few vendors that own
the web is minimal. In addition, the majority of all efforts in this space fail
like Microsoft's Information Cards initiative.
Regarding DomCrypt, I see this as a Mozilla project which the other vendors can
take up or not depending if they find it useful.
DomCrypt also shows the difficulty running open processes. It has been claimed
that DomCrypt could be "extended" to support smart cards. No document or
writeup has though been provided showing how this would work. 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

Ron Garret

2012-02-08 18:10:59 UTC

+1. The belief that something is infeasible is in nearly all cases a self-fulfilling prophecy.

Post by Harry Halpin
Anders,
Again, if you believe in your below statements, I kindly suggest you join another mailing list. Furthermore, there is no new information in your email, just the same opinion you re-iterated earlier a number of times.
cheers,
harry

Anders Rundgren

2012-02-08 19:50:21 UTC

Post by Ron Garret
+1. The belief that something is infeasible is in nearly all cases a self-fulfilling prophecy.

That standardization is infeasible isn't equivalent to no progress,
it just means that for those who want to achieve something tangible (which
Google hasn't already done), you IMO need to come up with a better plan.

The "big three" are putting all their power into mobile computing and
outsiders simply aren't welcome.

Anyway, I let you continue with whatever you do in peace; I stick to
the Open Source/Hardware route and skip standardization. There are
no surefire successes in this space and I wish you luck.

Anders

Post by Ron Garret

Henry B. Hotz

2012-02-09 01:04:41 UTC

Post by Anders Rundgren
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?

Post by Anders Rundgren
There are
no surefire successes in this space and I wish you luck.
Anders

Post by Anders Rundgren
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. 1) I'd hardly call TLS a "trusted application"; 2) A PIV card is a well-defined client credential, with good security properties. 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"?

Is the phrase "non-domain-restricted credentials" as Microsoft-centric as it sounds, or are you referring to DNS?

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz-***@public.gmane.org, or hbhotz-***@public.gmane.org

Anders Rundgren

2012-02-09 07:20:57 UTC

Post by Anders Rundgren
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.

BTW, I haven't seen a single posting from Microsoft or Apple regarding
DomCrypt. I honestly believe they are not really here either...

Post by Anders Rundgren
There are
no surefire successes in this space and I wish you luck.
Anders

Post by Anders Rundgren
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.

Post by Henry B. Hotz
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.

Post by Henry B. Hotz
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.

Post by Henry B. Hotz
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.

Post by Henry B. Hotz
Is the phrase "non-domain-restricted credentials" as
Microsoft-centric as it sounds, or are you referring to DNS?

If I understood it right the current DomCrypt presumes that
the issuer=relying party=domain for its keys. This idea
has severe usage limitations but is at least secure in the
sense that an RP can only screw-up for himself. Going beyond
that is a different story and AFAICT, possibly not even
related to DomCrypt. It would have been great knowing a
bit more about things like Google's Wallet and Microsoft's
W8/TPM2 stuff but apparently we cannot.

Cheers,
Anders
member of Trusted Computing Group

Post by Henry B. Hotz
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.

Henry B. Hotz

2012-02-14 06:48:44 UTC

Post by Anders Rundgren
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?

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?

Post by Anders Rundgren
There are
no surefire successes in this space and I wish you luck.

???

Post by Anders Rundgren
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.

Post by Anders Rundgren
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?

Post by Anders Rundgren
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.

Post by Anders Rundgren
Obviously, if someone can *otherwise* break in to the machine it's

Post by Henry B. Hotz
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.
Henry.B.Hotz-***@public.gmane.org, or hbhotz-***@public.gmane.org

Anders Rundgren

2012-02-14 08:56:47 UTC

On 2012-02-14 07:48, Henry B. Hotz wrote:
<snip>

Post by Henry B. Hotz
If you don't believe in standards, then what are you trying to accomplish here?

I believe in standards but not in standards that claim to do things they
weren't originally designed for which in this particular case includes
"financial transactions".

My interpretation of the current charter + the input documents is that
there are two *independent* work items. If this interpretation is right
I would suggest taking on one of them rather than mixing apples and oranges.

I'm actually quite interested in financial transactions through digital signatures,
maybe even as a standardization item. In fact, I have suggested this numerous of
times before to W3C officials. Anyway, the current signature specification is not
clear enough, not even for a charter. It appears to me that the interest in such
a facility in this list is marginal which makes the original DOMCrypt suggestion
a better choice as a standardization item.

<snip>

Anders
http://webpki.org/papers/wasp/wasp-tutorial.pdf
http://webpki.org/papers/wasp/wasp-faq.html

Post by Anders Rundgren
There are
no surefire successes in this space and I wish you luck.

???

Post by Anders Rundgren
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.

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

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.

Post by Anders Rundgren
Obviously, if someone can *otherwise* break in to the machine it's

Post by Henry B. Hotz
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.

Anders Rundgren

2012-02-09 21:07:02 UTC

http://www.w3.org/2011/11/webcryptography-charter.html

"The ability to select credentials and sign statements can
be necessary to perform high-value transactions such as those
involved in finance, corporate security, and identity-related
claims about personal data"

"The provisioning and use of keys within Web applications can
be used for scenarios like increasing the security of user
authentication and determining whether a particular device is
authenticated for particular services"

If you combine these high-level requirements you essentially get
a "webbified" Google wallet (and more). However, the Google
wallet is not an API, it is a system and architecture.

For financial transactions and key provisioning the DOMCrypt stuff
that Mozilla showcased last summer, IMO doesn't even come close
to the already shipping Google product so we are apparently (?)
talking about something entirely different.

"Out of scope: features include special handling directly for
non-opaque key identification schemes, access control mechanisms
beyond the enforcement of the same-origin policy, and functions
in the API that require smartcard or other device-specific behavior"

The Google wallet builds on smart card technology.

Anders

Anders Rundgren

2012-02-11 09:09:07 UTC

This is a follow-up to my previous (enclosed) posting.

I don't see that the keys provisioned in the second section have
much relevance for the signatures mentioned in the first section.

That is, we are effectively talking about two free-standing work-items
although they both build on JavaScript.

Creating a scheme that combines the requirements would be an entirely
different mission. Taking a simple example: Mozilla's "soft token"
doesn't support individual PIN-codes. AFAIK, the situation is roughly
the same for Internet Explorer. PIN-codes are more or less mandatory
in bank-contexts and it is always the *bank* that sets the policy.

That's why (for example) the Swedish banks that are into strong
authentication roll their own PKI clients which (of course) support
their own "hard-coded" PIN-policies. Not very universal but that's
what we got...

Anders

-------- Original Message --------
Subject: Web Cryptography Working Group Charter
Resent-Date: Thu, 09 Feb 2012 21:07:36 +0000
Resent-From: public-identity-***@public.gmane.org
Date: Thu, 09 Feb 2012 22:07:02 +0100
From: Anders Rundgren <anders.rundgren-***@public.gmane.org>
To: public-identity-***@public.gmane.org <public-identity-***@public.gmane.org>

http://www.w3.org/2011/11/webcryptography-charter.html

"The ability to select credentials and sign statements can
be necessary to perform high-value transactions such as those
involved in finance, corporate security, and identity-related
claims about personal data"

"The provisioning and use of keys within Web applications can
be used for scenarios like increasing the security of user
authentication and determining whether a particular device is
authenticated for particular services"

If you combine these high-level requirements you essentially get
a "webbified" Google wallet (and more). However, the Google
wallet is not an API, it is a system and architecture.

For financial transactions and key provisioning the DOMCrypt stuff
that Mozilla showcased last summer, IMO doesn't even come close
to the already shipping Google product so we are apparently (?)
talking about something entirely different.

"Out of scope: features include special handling directly for
non-opaque key identification schemes, access control mechanisms
beyond the enforcement of the same-origin policy, and functions
in the API that require smartcard or other device-specific behavior"

The Google wallet builds on smart card technology.

Anders

Dick Hardt

2012-02-08 22:47:21 UTC