Re: Editorial comments - W3C Candidate Recommendation 11 December 2014

On Mon, Dec 15, 2014, at 10:33 PM, Ryan Sleevi wrote:
>
>
> 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.

It does a bit. Sentence 2 in particular feels pretty circular. Here's my
attempt at replacing sentences 2 and 3:

"User Agents that depend on a cryptographic implementation which relies
on hardware, or an externally configured (e.g. operating system managed)
module may have their capabilities limited in ways which are not
detectable to the User Agent until attempted execution of an operation.
As a result, a User Agent may not be able to expose an accurate set of
capabilities to web content."

David