Re: Editorial comments - W3C Candidate Recommendation 11 December 2014

On Mon, Dec 15, 2014 at 2:17 PM, David Illsley <david@illsley.org> wrote:
>
>  On Mon, Dec 15, 2014, at 09:06 AM, Ryan Sleevi wrote:
>
>
> On Dec 15, 2014 12:57 AM, "David Illsley" <david@illsley.org> wrote:
> >
> <snip>
>
> > 4.3. Operations
> >
> > This section is confusing, contradictory, and I don't think backed up by
> > the rest of the document. I *think* it's trying to say:
> >
> > "Although the API does not expose the notion of cryptographic providers
> > or modules, each key is internally bound to an algorithm and usage, so
> > web applications can be confident that a given key will only be used for
> > the correct set of cryptographic operations."
>
> Not really. It is meant to contrast with the interfaces exposed by common
> native APIs, which have abstractions such as providers, key stores, and
> modules, all of which are meant to expose additional functionality,
> typically hardware (e.g. smart cards or TPMs).
>
> OK. I can't see that in the present wording of 4.3. The present wording
> doesn't seem to be backed up by the rest of the document, because the rest
> of the document doesn't mandate that it is implemented using a
> "cryptographic provider or module". If I tried once more:
>
>  "Although the API does not expose the notion of cryptographic providers
> or modules, the API allows for each key to be internally bound to a
> cryptographic provider or module, allowing browsers to ensure that the
> right cryptographic provider or module will be used to perform
> cryptographic operations involving that key."
>
> ?
>

Actually, re-reading this, it should just be struck. As you note, the spec
doesn't require it be implemented in this way (either on top of
cryptographic providers or requiring the key use the same provider). It
may, but that's internal.

Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=27617


> The API designed intentionally avoids this, because such a pattern is
> fundamentally and irretrievably insecurable. That is, there is no secure
> way to expose these legacy hardware devices to a (hostile) web. Note I say
> insecurable because having to resort to prompting the user is fundamentally
> ceding security.
>
> Just so that I understand, are you referring to exposing the choice of a
> (hardware) crypto provider to the page? (As opposed to making it opaque to
> the page, but configurable in the user agent/OS as mentioned in 5.1)
>

Well, there's (intentionally) no way to expose pre-existing keys in this
specification - whether hardware or software. Other specs have been
explored (notably Key Discovery) for ways to do that, but there's a lot of
attendant privacy and security issues that rightfully caused this to be out
of scope.

It also doesn't define a way to get keys into specific
tokens/providers/storage (as noted in 4.4)


> >
> > 5.1. Underlying Cryptographic Implementation
> >
> > The first paragraph doesn't aid understanding of the specification, and
> > is over-complex. It could be replaced by something simpler eg "This
> > specification allows for cryptographic operations to be implemented
> > separately from the user agent, through the use of existing APIs and
> > modules."
> >
> > Similarly, paragraphs 3 and 4 could be removed entirely, or otherwise
> > substantially simplified.
> >
> >
>
> These were all requested during Last Call review, by both people
> inexperienced with crypto APIs and thus lacked context, and by those
> familiar with crypto APIs and thus desired to understand why this makes
> several substantially different choices.
>
> Could you explain with better precision what you find confusing?
> "Unnecessary" feels like it's a bit more subjective, and given the requests
> during review to include it, I would rather the specification spell things
> out explicitly than omit them and require frequent explanation (as we've
> seen for other aspects all ready).
>
> If it helps other people, I'm all for it. It sort of looked like it's
> mainly to make 'historical' and 'traditional' crypto vendors be comfortable
> that their stuff can be hooked in, so I assumed it could be simplified to:
>
> "This specification allows for cryptographic operations to be implemented
> separately from the user agent, through the use of existing APIs and
> modules, including those with hardware components"
>
> That doesn't help with context though. I wonder if it could be clearer
> with a small amount of shuffling:
>
> "Historically, many user agents have deferred cryptographic operations,
> such as those used within TLS, to existing APIs that are available as part
> of the underlying operating system or to third-party libraries that are
> managed independently of the user agent. This specification assumes, but
> does not require, that conforming user agents do not directly implement
> cryptographic operations within the user agent itself. "
>

Sounds good.


>
> and then paragraph 4:
>
> "This specification assumes, but does not require, that most user agents
> will be interacting with a cryptographic provider that is implemented
> purely in software. As a result, the capabilities of some implementations
> may be limited by the capabilities of the underlying hardware, and,
> depending on how the user has configured the underlying cryptographic
> library, this may be entirely opaque to the User Agent. "
>

Hrm, still feels weird.

"While this specification assumes that most user agents will be interacting
with a cryptographic implementation that is implemented purely in software,
this is not required. As a result, User Agents that chose other
implementation strategies, such as implementing via hardware, may find that
the capabilities of the User Agent are limited by the underlying hardware.
Further, even when using a software-based implementation, if the
cryptographic implementation y is maintained separately than the User
Agent, such as via external configuration, the User Agent may be limited in
the capabilities it can expose in ways that are opaque to it until
executing an operation."


Even the above reads a little weird, but I'm curious how you feel.


>
>
> However, if there are things confusing or worded wrong, it would help to
> know what and why, so that we can explore if it might be worded clearer.
>
> Thanks for the feedback!
>
> Cheers,
> David
>