- From: Anders Rundgren <anders.rundgren@telia.com>
- Date: Sat, 13 Apr 2013 00:38:48 +0500
- To: Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>
- CC: Samuel Erdtman <samuel@erdtman.se>, "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>
On 2013-04-12 11:13, Nick Van den Bleeken wrote: >> On 2013-04-11 11:51, Samuel Erdtman wrote: >>> Hi Anders, >>> >>> And you feel that webcrypto do not fill that space then? What is missing? >> >> That's a good question! I would be wrong if I were to answer for >> anybody but myself and I find that PCs are out-of-scope for innovation >> of this kind (CertEnroll is proof of that). However, mobile devices >> have embedded security hardware or similar and then Web Crypto appears >> to be pretty half-baked. I think that it should be finished according >> to plan but I seriously doubt it will be particularly important until >> there is a "bridge" between platform keys and Web Crypto. > We are seeing an increased interest in Belgium of the use of SmartCard > readers attached to tablet devices (iOS and Android for the moment), > for all kind of applications by both government and private business. I'm personally very skeptical about such arrangements due to the lack of working smart card standards and also due to the awkwardness of external readers using cables or Bluetooth. Using a mere 0.05 mm2 of silicon "real-estate" in the main CPU you can have _any_ number of HW-protected keys: the remaining issue is provisioning. Provisioning of smart cards in PCs is the single most failed security product I'm aware of (Microsoft and the card industry simply can't get their act together), but using _embedded_security_hardware_ it becomes fully manageable. Does this render the Belgian eID useless? On the contrary, it is an excellent bootstrap credential for provisioning an identity "clone" to other devices in a secure way but still based on self-service. I'm currently building exactly this for a central-European bank and the Swedish BankId have issued 10th of millions of certificates on-line using similar methods. There have been some sentiments from Google that IETF's new certificate enrollment protocol EST will fill the bill. From my horizon EST looks like a clear case of DOA. > > Currently those apps are using a proprietary SDK and API. It would be > neat for developers if they could use a cross vendor JS API for there > applications, aside if this requires a custom WebView component based control > or more ideally the standard Web Browser on the platform (but this is probably > a bridge to far initially, because it will require a pluggable native Crypto API > not bound to a specific app). Since the pluggable Crypto API haven't been a source of joy so far I think that we won't see much of that in mobile devices. Abstracting end-to-end-security is essentially undoable and then you are limited to physical distribution of "read-only" tokens which only works for governments and maybe some banks. Gemalto's attempt bringing a smart card interface to the web is also unlikely to get platform-vendor support since it doesn't integrate particularly well. Anders > > Nick >> >> I also don't see that Netflix needs a specific solution. Since they >> have non-standard clients they could let their keys "masquerade" as keys >> provisioned through Web Crypto, possibly including the addition of >> GUI like "hitting OK will give you access to our trial subscription". >> >> Anders >> >>> IMO web crypto now provides the possibility to do certificate >>> enrollment for keys but you will have to build the certificate layer >>> on top of the web crypto key storage and you will be limited to soft >>> certificates. Therefor you might want to use the web crypto API in a >>> different manner then existing key storage e.g do short lived session >>> certificates. >>> >>> Sent from my iPhone >>> >>> On 11 apr 2013, at 08:45, Anders Rundgren <anders.rundgren@telia.com> wrote: >>> >>>> On 2013-04-11 11:42, Samuel Erdtman wrote: >>>>> Hi Anders, >>>>> >>>>> Are you saying that banks and eId (governments) do not have the skills >>>>> or the will to create >>>> >>>> Hi Samuel, >>>> Pardon if I was unclear. >>>> >>>> No, I was referring to Microsoft, Google and Mozilla that to date haven't created a useful solution for on-line certificate enrollment. >>>> >>>> Anders >>>> >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On 11 apr 2013, at 04:57, Anders Rundgren <anders.rundgren@telia.com> wrote: >>>>> >>>>>> On 2013-04-11 03:47, Samuel Erdtman wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Relatively early in the webcrypt work I submitted a set of use-cases (to the public list) that where similar to what you sugests but with a clearer focus on certificates and there keys. You can find it here http://lists.w3.org/Archives/Public/public-webcrypto-comments/2012Jul/0000.html. >>>>>>> >>>>>>> I have requirements similar to yours but since I submitted my use-cases I have learned a lot and changes my position a bit. I still have these requirements, but I think that it should be coupled to certificates not key attributes, and maybe not in webcrypto. >>>>>>> >>>>>>> If I understand the draft that you sent, this discovery mechanism with issuer would not be bound to origin. I think this is wrong since by going outside the SOP we will open pandora's box of security and privacy issues. >>>>>>> >>>>>>> One of the things that we would have to consider is that if I can query for the issuer of eIdīs form every site then it would be very easy to track a user, and the issuer of the eId cannot prevent it. In my initial use-case the webpage would not get the key reference but just the signature if the user accepted to sign and something generic none compromising if the user denied the signature. >>>>>>> >>>>>>> In a later mail I suggested to bind certificate and keys to a domain with an attribute specifying the domain (posible with wildcard), This would put the issuer in control of the usare of the certificate and keys. >>>>>>> >>>>>>> After this I have come more and more to the conclusion that we really should leave smart cards out of webcrypto, for the time being at least. There exists good but propertarian solution for handling smart cards and I thing that to handle smart-cards we would have to have a much wider scoop. I think that we should fokus on solution where we do not need smart cards for example in the nordic countries we are moving away from smart cards for eIdīs and moving towards server-side signares and short lived certificates (one session only) that is issued when the user can provide some other form of strong authentication e.g. OTP. Then we have the mobile situation where smart cards do not suite very well i.e. we need other solutions. Therefor I think that we should let webcrypto solve problems more relevant to the future then smart cards. >>>>>> IMO, the vendors have so much problems with their existing certificate enrollment solutions that it appears unrealistic that they will succeed doing anything useful of it in Web Crypto: >>>>>> >>>>>> http://lists.w3.org/Archives/Public/public-webcrypto-comments/2013Mar/0076.html >>>>>> >>>>>> Anders >>>>>>> >>>>>>> Best Regards >>>>>>> Samuel Erdtman >>>>>>> Technology Nexus Product Manager >>>> >>> >>> >> >> >> >> > > > ________________________________ > > Inventive Designers' Email Disclaimer: > http://www.inventivedesigners.com/email-disclaimer > >
Received on Friday, 12 April 2013 19:39:30 UTC