- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Tue, 24 Dec 2013 16:28:48 +0100
- To: Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>
- CC: "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>
On 2013-12-24 15:56, Nick Van den Bleeken wrote: > 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). Hi Nick, I'm painfully aware of this :-( :-( A question comes to my mind, is it technically impossible upgrading cards in a self-service process using the original certificate as authenticator? I guess the answer is no which is yet another reason why I'm struggling with an "alternative" smart card scheme, targeted at the connected generation. A possibility is using the eID as a secure "bootstrap" for a derived credential stored in _another_ key-container like a mobile phone. Happy Christmas BTW! Anders > > 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, > > Nick > > 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: > http://www.inventivedesigners.com/email-disclaimer
Received on Tuesday, 24 December 2013 15:29:21 UTC