W3C home > Mailing lists > Public > public-webcrypto-comments@w3.org > December 2013

Re: SOP Exception versus Key-based Domain Labels

From: Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>
Date: Tue, 24 Dec 2013 14:56:55 +0000
To: Anders Rundgren <anders.rundgren.net@gmail.com>
CC: "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>
Message-ID: <CAC5A9A7-84E5-4263-8A94-C23F19E918E5@inventivegroup.com>
Hi Anders,

Thank you for raising the topic again. I have one remark on your proposal of using a _domain_label_ in an extension attribute.

In Belgium the eID is valid for 5 years, they even want to extend this to 10 years (to save costsÖ). This means that it will take 6 years ( or 11 in the future), before all citizens will have an eID card with the new extension field on it. This approach might be usable for smart cards that are distributed by private companies, where they could afford distributing new cards sooner. But for eIDís this isnít feasible.  (In practice it will take even longer because one year for getting an extra field from proposing it to getting it approved, implemented, tested and production is quite optimistic).

I donít have a better proposal at the moment, but this was the feedback we got from Fedict (Fedict defines and implements the federal e-government strategy. And is responsible for the Belgian eID cards).

Kind regards,


PS: I donít want to start the discussion about the validity period here, it is way too long but that is another discussion...

On 21 Dec 2013, at 04:51, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:

> Dear List,
> Mountie and Nick have independently of each other proposed SOP exceptions managed by
> the _user_ as a solution for facilitating access to non-origin-bound pre-provisioned keys.
> At first sight this appears to be a viable solution.  A deeper dive into this topic reveals
> a few snags such as the fact the browser will have to offer _all_ certificates for the [poor]
> user to select from.  This will only work satisfactory if we had this one ID that everybody
> trusts/accepts which is a restriction that doesn't fit particularly well in a _standard_.
> I have said it before and I say it again [things become more true when repeated, right? ;-)]:
> It is the _key_ that should do the initial filtering (which indirectly already is the case in WebCrypto)
> because no serious issuers would accept _arbitrary_web_code_ accessing their keys.  The latter
> would be like inviting skimming of credit-cards in fake payment terminals.
> The user _may_ (depending on the implementation) further restrict access but then from a
> much more reasonable selection (only the keys that actually matches the RP's need).
> In a WebCrypto world it would mean that a pre-provisioned key as a minimum should
> have a _domain_label_ which in an X.509 use-case typically would be put in an extension.
> Leaving the somewhat crippling domain sand-box can be performed through _postMessage ()_
> arrangements, but this decision is still in the hands of the issuer.
> Anders


Inventive Designers' Email Disclaimer:
Received on Tuesday, 24 December 2013 14:57:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:26 UTC