W3C home > Mailing lists > Public > public-webcrypto-comments@w3.org > October 2012

Re: WebCrypto API comments

From: John Lyle <john.lyle@cs.ox.ac.uk>
Date: Wed, 10 Oct 2012 10:16:05 +0100
Message-ID: <50753CD5.8080506@cs.ox.ac.uk>
To: Ryan Sleevi <sleevi@google.com>
CC: public-webcrypto-comments@w3.org
On 10/10/12 00:10, Ryan Sleevi wrote:

>>
>> Yes, I appreciate that.  I was checking that these usage parameters were
>> _enforced_ as well as specified.   The specification states that they
>> indicate "what CryptoOperations may be used with this key", but the spec
>> doesn't say anywhere what would happen if you provide a key with the wrong
>> usage parameters. I admit that this is probably blindingly obvious.
>
> Anything that relies on being "blindingly obvious" will inevitably
> become a source of mis-implementation.
>
> Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=19416 to clarify
> this in the next draft.


Great.  To clarify one final thing - will keys be allowed to have 
multiple usage parameters, even if this is bad practice?  In the bug 
report you mention requiring the 'encrypt' usage parameter for 
createEncrypter.  But will it also require that the key *not* have the 
'sign' usage parameter?


>
> Simply exposing the certificates, to any origin, without any user
> consent is troubling, since certificates may reveal information about
> the user (eg: government issued ID).


Agreed.


> Likewise, requiring user consent
> to use any cryptographic functions at all is problematic, since a
> number of use cases don't require any access at all to the users'
> certificates. So the balance struck was that, if an origin wishes to
> use some (pre-existing - whether by OS or from some other origin)
> certificate, it must give some set of criteria to the UA, and the UA
> can then respond appropriately (showing a dialog, outright rejecting,
> etc)


I completely understand why this balance was struck.  I remain 
sceptical, however, that UAs will implement something appropriate 
considering previous history.  One reason that UA security warnings have 
often been unusable in the past (e.g., warnings about SSL certificates) 
is that the underlying mechanism is fundamentally difficult to talk 
about with users, or align with their goals, no matter how well designed 
the user interface.  This is something to avoid with the WebCrypto API.

The set of possible circumstances for UA prompting/mediation seems small 
enough that they could be enumerated, particularly if they were based on 
the use cases.  As such, some proof-of-concept mock UIs could be 
developed to demonstrate at least one sensible way of asking for consent 
(or not asking, given the situation) in each circumstance.  This would 
provide a huge amount of validation for the API, in my opinion, and 
might show situations where there really isn't a sensible option.  And 
if there isn't a suitable way to ask for permission, yet it is necessary 
to ask, then there would be a strong case for removing that scenario 
from the API.

It's easy for me to suggest that other people do a lot of additional 
work, though.  So if you do decide to do something like this then I may 
be able to help.



(As a side note: some of my colleagues and I are of the opinion that 
usable security design in context-free situations such as API 
specification might be fundamentally impossible.  The best that might be 
achieved would be to show that within some contexts is is *possible* to 
create *a* usable system.  Even that is clearly inadequate.)


>>>> (11) I agree with ISSUE-31 - particularly for some of the potential OOB
>>>> provision situations I can see that being able to discover a key based on
>>>> custom attributes would be useful.  Of course this might make
>>>> fingerprinting
>>>> a bigger issue.
>>>
>>> Discovery of keys that exist (rather than keys created by/inside of an
>>> origin) are almost certainly operations which require user consent.
>>> What has prevented ISSUE-31 is trying to decide some canonical way to
>>> query for these parameters - which nominally requires enumerating the
>>> existing parameters that would be useful to query on.
>>>
>>> Do you perhaps have examples of attributes you would wish to use to
>>> discover keys - either common or custom?
>>>
>>
>> I would like to be able to query (at least in theory) for a key held in a
>> Trusted Platform Module that is bound to particular platform configuration.
>> E.g., it's possible with a TPM (again, in theory) to create a key that is
>> only accessible when the platform boots into a certain operating system.
>> I'd like to be able to request one of those in my web application.  This
>> could be done by searching for keys with appropriate attributes (where
>> attributes would contain details about the restrictions placed on the use of
>> the key by the TPM).
>
> Yup. This is a use case that we want to support as well.
>
>>
>> However, because this API does not (as far as I can tell) provide a way for
>> a web application to obtaining key validation data (some kind of key
>> certificate guaranteeing the key's attributes) then this isn't useful even
>> you could discover keys based on custom attributes.
>
> No, this is the "We need a good proposal" issue. Wan-Teh Chang raised
> ISSUE-31 ( http://www.w3.org/2012/webcrypto/track/issues/31 ) about
> this, which I had some concerns about.
>
> However, as a rough sketch, is that the sort of API you imagine?


Yes, that's roughly what I had in mind.  However, as I mentioned, the 
use case I was considering requires assurance of the key generation 
process. This is something that a TPM can do.  From what you've said, 
this is not a capability that this API intends to expose to origins.

It's a shame because this means that a provisioned key can't be used to 
provide assurance of dynamically generated keys through this API, but I 
see the need to limit scope.


>
>>
>> This means the only option is to provision keys outside the user agent and
>> keep a record of their ID for later use.
>>
>
> The above has so far been the recommended solution. Key
> *provisioning*, particularly for secure elements, is largely
> hand-waved as out-of-scope (as it requires WG and sub-WG of it own to
> find any sort of common agreement, and ends up more enterprise-y than
> OAuth2). However, once you have such a key, being able to use it via a
> web origin should "Just Work" as if the origin had directly created it
> (mod the above security considerations about origin-authorized-by-user
> keys and origin-specified-during-keygen keys)

Ok, that makes sense.

Best wishes,

John
Received on Wednesday, 10 October 2012 09:16:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 10 October 2012 09:16:30 GMT