W3C home > Mailing lists > Public > public-webcrypto-comments@w3.org > February 2014

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

From: Ryan Sleevi <sleevi@google.com>
Date: Thu, 13 Feb 2014 15:17:23 -0800
Message-ID: <CACvaWvZv5NnJapGKr5riVGLnSoo6Ac3-Ex7PB=HQxdTfExpaQw@mail.gmail.com>
To: Samuel Erdtman <samuel@erdtman.se>
Cc: Anders Rundgren <anders.rundgren.net@gmail.com>, "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>, Harry Halpin <hhalpin@w3.org>, GALINDO Virginie <virginie.galindo@gemalto.com>
On Thu, Feb 13, 2014 at 1:09 PM, Samuel Erdtman <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.

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> wrote:
>
>>
>>
>>
>> On Wed, Feb 12, 2014 at 10:03 PM, Anders Rundgren <
>> 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>, but then the certificate issuer lost control over
>>> 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>>
>>> 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 Thursday, 13 February 2014 23:17:51 UTC

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