WebCrypto API comments

Dear W3C Web Crypto Working Group,

I have just read the Sept. 13 Working Draft after being forwarded the 
request for feedback by Virginie.  I think that it is remarkably clear 
and easy to follow and it has been designed at a reasonable level of 
abstraction (at least, roughly the level I expected).  At a first glance 
it seems not dissimilar to javax.crypto and slightly more abstract than 
the crypto API provided by middleware such as nodejs, which are likely 
to be the most familiar prior art for many developers.

I have some comments, and while many are quite general I primarily have 
out-of-band provisioning of keys in mind.  Apologies if some of these 
comments go back over ground you have already discussed. I should also 
add a disclaimer - I know enough about cryptography to know that I can't 
comment on specific algorithm usage details or weaknesses.

Comments:

(1) The use case "Protected Document Exchange" is fine, but implies that 
User Agents will be able to distinguish between different users when 
encrypted data is received.  There are several contexts where this wont 
be the case (shared devices), so I suggest that this use case become 
more specific.  What kind of documents or scenarios are intended?  
Furthermore, I'm not sure that the specification necessarily supports 
this use case unless we make quite a few further assumptions about how 
the user agent must protect keys, which was (as I understand) 
intentionally avoided.

(2) I don't buy the Cloud Storage use case, I'm afraid.  Johnny still 
can't encrypt his email [2] so I'm suspicious of any use case suggesting 
he might choose a key to encrypt his data.  A better use case would make 
the role of the application (which I would expect to be more supportive 
and mask the use of cryptography and keys) clearer.

(3) I wondered whether there was any plan to integrate use cases based 
around keys created in TLS-OBC [3]?  I guess this is out of scope.

(4) I agree with ISSUE-33.  Any automated way of spotting that keys or 
key materials are being misused should be seriously considered.  
Similarly, I'm assuming any attempt to misuse an encryption key for 
signing (or vice versa) could result in errors?  If memory serves, the 
Trusted Computing Group specifications make the effort to dictate what 
operations each kind of key may be used for, it might be worth following 
their lead.

(5) Very minor grammatical error in section 4.1 - "avoids developers to 
care about" should be something like "avoids developers having to care 
about"

(6) 5.1 - obtaining 'express permission' from users is impractical, 
considering the general usability of crypto systems. I don't recall 
seeing any use cases or details for why or when keys might be re-used by 
different origins in the specification, so it isn't clear why this is 
discussed or what the implications are.

(7) I think the 'security considerations for developers' in 5.2 could be 
improved.  It is important to note that secure storage isn't guaranteed, 
but what *is* supposed to be guaranteed by user agents?  Maybe nothing?  
Perhaps more details about the threat model this API is assumed to be 
operating in would make sense. For instance - does it make sense to use 
this API when the browser is considered relatively trustworthy, but 
other web applications are not?  Or when the user and the web 
application trust each other?  I think the specification is fine, but a 
bit more rationale would be useful here, as well as a definition of the 
agents/principals involved.

(8) I have a more high-level concern that this API could be misused as a 
way of trying to push liability for security onto users and away from 
service providers.  As in, by using this API a service 
provider/developer might feel that it is then up to the *user* to store 
their keys safely and they can disclaim all responsibility.  This would 
be unfair.  There's not that much that can be done in a specification to 
prevent this, but I think it is worth bearing in mind when writing the 
'security considerations for developers' section.

(9) Section 11.1 - The specification would be improved with a state 
machine diagram as well as the text.  I also found it odd that the 
"processing" state was described as "ready to process data".  I would 
intuitively assuming "processing" meant "busy". Perhaps this could be 
rephrased?

(10) How does a web application discover what algorithms are supported 
by the user agent?  I may be have overlooked something, but I couldn't 
see any examples.

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

I hope this feedback is useful.  I am happy to discuss or elaborate further.

Best wishes,

John


--
John Lyle
Research Assistant
Department of Computer Science, University of Oxford
http://www.cs.ox.ac.uk/people/john.lyle/

Part of the webinos project - http://webinos.org/bio-john/

[1] http://www.w3.org/TR/2012/WD-WebCryptoAPI-20120913/
[2] http://www.gaudior.net/alma/johnny.pdf
[3] http://tools.ietf.org/html/draft-balfanz-tls-obc-00

Received on Monday, 1 October 2012 17:45:50 UTC