Re: Proposed API Extension for X.509 Certificates and Smart Cards

On 2014-02-14 00:17, Ryan Sleevi wrote:
>
>
>
> On Thu, Feb 13, 2014 at 1:09 PM, Samuel Erdtman <samuel@erdtman.se <mailto:samuel@erdtman.se>> wrote:
>
>     I do think that it would be useful to have some level of access to keys on secure storage, smart card, from javascript in the browser.
>
>     The use case that I think is relevant is:
>     Organisations that does not trust other storage then e.g. smart cards wants to sign web forms. This problem has been solved by browser plugins and similar solutions. Or has been excluded from the possible use for the smart cards.
>     With the suggested solution we could move away from browser plugins and still use keys on e.g. smart cards.
>     Is that not a use case? or a problem worth solving?
>
>
> "Is that not a use case" - No, not really. It fails to capture the problem the why of the problem you're trying to solve, which makes it impossible to consider other solutions other than the proposed solution.
>
> Look at http://www.w3.org/TR/webcrypto-usecases/ to understand that the goal of the use case should be to try to break requirements into decomposible operations - with the goal of demonstrating how there is missing "goop" that is needed.

I did:
http://www.w3.org/TR/webcrypto-usecases/#banking-transactions

Unfortunately it doesn't match anything I have seen in spite of being a long-time user and more recently a vendor representative in this particular space.

BTW, a primary reason for using smart cards is simply the fact that they are distributed (handed over to the user) physically.

Regarding the attack-vectors you describe, I think it would be extremely valuable having some kind of guidelines on how to build secure sites using WebCrypto including cross-origin applications.  Your message seems to be that even well-written web-applications are susceptible to XSS. That's at least news to me (here disregarding self-induced XSS via the JS console).

Cheers
Anders


>
> Your use case fails to explain the trust relationship between organizations. Is the idea that every website I go to will issue me a new hardware token? Surely not, so now we're into situations where we're either talking about issuing parties and relying parties (ie: what everyone so far has really been talking about), and _why_ they don't trust storage, and _what_ they're trying to accomplish.
>
> The example of non-repudiation is a prime example of security snake oil. A smart card doesn't buy you any more protection from malware than storing the key on disk. Further, I think if we work through some of the flows, it MAY appear that other solutions - whether OpenID Connect, FIDO, Browser ID, or who knows what - may make a more sensible alternative for the web.
>
> It also helps highlight the security assumptions and threat models. What good is storing the key in hardware if hostile JS can sign arbitrary messages? The arbitrary JS may be from XSS on the site, from local extensions injecting into the DOM, or even from self-XSS (eg: via the JS console). Or consider CA compromise or misissuance - the latter of which is a problem of unknown scope. All the security benefits of a secure element disappear under such a MITM attack, and would be the modern-day equivalent of drive-by malware being added to users machines.
>
> Further, by establishing the composed operations, we can also more reasonably discuss whether a different solution is better suited for the web platform, or where there are gaps in the available technologies (independent of Web Crypto) that need to be filled. Consider "middleware" implemented as postMessage + Service Workers as an example of such a hypothetical.
>
>
>     Regarding having to reissue lots of certificates, several setups that I have seen have self service for renewal of cards so it might not be super hard to do. Further certificates might be valid for three years i.e. within three years it would be possible to have this attribute on all certificates that needs it (seems reasonable in my world). 
>
>
>     Finally if a card is issed for a domain, then you cannot sell or leave that domain until those cards have expired, more or less three years (not an eternity). That will have to be a consideration to take into account when starting to issue certificates with this attribute.
>
>     Cheers
>     //Samuel
>
>
>
>     On Thu, Feb 13, 2014 at 7:49 AM, Ryan Sleevi <sleevi@google.com <mailto:sleevi@google.com>> wrote:
>
>
>
>
>         On Wed, Feb 12, 2014 at 10:03 PM, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
>
>             On 2014-02-13 00:15, Ryan Sleevi wrote:
>             > I have not heard from a single participant with experience in smart cards or desiring smart cards who would desire to see all issued certificates re-issued to support the scheme.
>             >
>             > It also fails to take into the serious security considerations that would exist if a certificate was provisioned for example.com <http://example.com> <http://example.com>, but then the certificate issuer lost control over example.com <http://example.com> <http://example.com>.
>             >
>             > While you're correct that a proposal is a proposal, I think your time would be better served - as would those who are interested in CMP and more complex KMS - to first draft a set of problem statements and reach consensus on the problems that you're trying to solve, rather than continually approaching the WG with proposals that you believe solve your problem, but do not do so in a clear and direct way.
>
>             Dear Ryan,
>
>             Proposals tend to have pros and cons.  You have clearly identified a couple of weaknesses in the plot.
>
>             I'm cool with that.  Now I look forward seeing the *other* proposals that Virginie have indicated is in the workings.
>
>             Regarding the use-case, it's pretty straightforward:
>
>                                   "Blending traditional PKI (including how it is packaged and distributed), with WebCrypto."
>
>             Cheers,
>             Anders
>
>
>         Anders,
>
>         While I appreciate you taking the time to reply, I fear that the amount of time people will spend reviewing and considering your proposal should and will be limited to the amount of time you spent drafting a problem statement and use cases.
>
>         I'm sure with your expertise you can certainly provide a more meaningful set of problems, along with a demonstration of how they can only be solved with your proposed integration, and which cannot be addressed by the existing solution. Stating "Because we want it" or "because that's how we do things" is not a productive contribution to a meaningful discussion.
>
>         Again, it's more useful for the WG if you can share the set of problems you're wishing to solve, rather than presenting specific solutions that you believe will solve them.
>
>         All the best,
>         Ryan
>          
>
>
>             >
>             >
>             > On Wed, Feb 12, 2014 at 1:33 PM, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com> <mailto:anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>>> wrote:
>             >
>             >     Ladies and Gentlemen,
>             >
>             >     A year ago I submitted a pretty complex proposal for adding X.509 and smart card capabilities
>             >     to WebCrypto based on a "bridging" scheme.  Approximately the same time a fellow developer
>             >     in this field Samuel Erdtman of NexusSafe suggested a much simpler way forward, albeit still
>             >     building on a bridge concept.
>             >
>             >     Following the golden rule that "less is more" I have with Samuel's permission merged a
>             >     minor portion of my API ideas with his concept:
>             >
>             >     http://webpki.org/papers/PKI/x509-webcrypto-extension-scheme.pdf
>             >
>             >     Enjoy!
>             >
>             >     Anders Rundgren
>             >
>             >
>
>
>
>

Received on Friday, 14 February 2014 06:32:16 UTC