Re: Editorial comments - W3C Candidate Recommendation 11 December 2014

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."

?
> 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)
> >
>
> 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. "

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. "

> 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