Re: Feedback, comments and so about WG Web Cryptography API

Hi Ryan.

Thanks for your answers, altought they let me no much hope for the
future...Replying inline.
;)


On Tue, Oct 22, 2013 at 8:53 PM, Ryan Sleevi <sleevi@google.com> wrote:

>
> On Tue, Oct 22, 2013 at 11:13 AM, helpcrypto helpcrypto <
> helpcrypto@gmail.com> wrote:
>
>>
>> Firstly, there are some parts I have interest in:
>>     13.2.6. The generateKey method
>>     13.2.9. The importKey method
>>     13.2.10. The exportKey method
>>
>> *I know that "handling the keys" is out of the scope of this document
>> (smartcards too)*, but I'll like to know if, as an integrator, I'll be
>> able to generate a key pair on CSP/NSS/PKCS#11 modules, or import/export
>> keys from my smartcards using -for example- a PKCS#11 interface. In other
>> words:
>> *Will this invoke microsoft-csp or linux-nss operations under this layer
>> to get access to keystores?*
>> (I think so, but looking for confirmation)
>>
>
> As you acknowledge, it's out of scope of this document. You're asking a
> question about how implementations decide to expose potentially
> security-relevant features and the risks to users.
>
> The API provides no statement of this.
>

I will ask it another way:
*Does it has sense having an importKey/exportKey functions if they arent
going to be working with keystores?*
Considering these functions have the purpuse to import a key to be able to
use it through WebCrypto or to export a key to somewhere, it will have
sense to expect these functions to communicate to keystores, isnt it?
*If only webcrypto generated keys are going to be used, i dont see the
point having these functions.*



>
>>
>> I'm also missing a* getKey(filter)* function that returns a handler to
>> use keys in operations like sign(key,data).
>> *Do you plan to add it?*
>>
>
> Considering the above comment, this is not intended for this release.
>

I agree with you: WebCrypto defines a way to sign, but it doesnt say how
keys are recovered.
IMHO, getKey doesnt say how the keys are recovered, but shows user could
query for keys to use, so it has sense for me.
In other words: webcrypto - getkey - keydiscovery
*Doesnt it seems correct?*
Probably this question could be moved to keydiscovery API.



>
>
>>
>> *Will be possible to specify a filter/unicode string to search on
>> subject/cert?*
>>
>
> Not in scope.
>
I understand your aswer and agree with it, but something -imho- is missing
from webcrypto spec.
Webcrypto spec says "a key is used", not detailing how the keys are
recovered. But it should also say "keys are recoverey according to
keydiscovery API(link)".
At this momento, webcrypto is not linking keydiscovery, but the opposite
way, which seems confusing. At least for me.

Thinking about this, the getKey function I proposed could be "moved" to
keyDiscovery API, but referencing text/link should shall be mantained.



>
>> I think key protection is also outside of the scope of this document, but:
>> *Will it be possible to make a key "sticky", being able to sign more
>> than 1 document with "one PIN" only? (batch mode)
>> *
>>
>
> PINs handling is not in scope.
>
You can call it fingerprint match if you like.
Probably this should go on keyDiscovery API, but the question remains.



>
>
>> * *
>> Finally, [3] says "Also, the system must display to the user the data
>> that is being signed, so that he knows what he is signing"
>>
>
> This is a much older, unmtained document.
>
>
>> I'll like to publicly ask, request, beg, plead, pray...this to be human
>> readable.
>> Old Mozilla's signText was one of the worst -imho- *human *friendly GUIs
>> ever made.
>> *Could it be possible to display what the user is going to say using
>> tools like PDF.js (for PDF files)?
>> Could it be possible to display a short customizable message like: "Hi
>> peter, here are the documents you have to sign!"?*
>>
>
> As above, this is not something the WG is providing.
>

As keydiscovery its only about "discovery", but not usage, i think it could
be a good idea to add an annex or a reference about how these things could
be implemented.
This will help us, for example, to prevent useless dialogs showing
unreadable xml and a "do you accept?" message.
I dont know if you see my point.



>
>>
>> KeyDiscovery: [4]
>> This document purpose is to define how the keys will be recovered from
>> the browser.
>>
>> IMHO, the *getKey *function IS the link between these two documents, and
>> thats the reason why WebCrypto spec should contain the function and
>> reference to KeyDiscovery (not the way around).
>>
>>
>> Reading this document, I not sure if I understood this part:
>>   interface NamedKey : Key {
>>       readonly    attribute DOMString  name;
>>       readonly    attribute DOMString? id;
>>   };
>>
>> *Will getKeyByName("PETER") will look for all keys containing (in any
>> attribute) the word "PETER"?*
>> (If that's correct, im happpy to hear it!)
>>
> Any comments on this?



>
>> Also, will be great to be able to filter by keystore like
>> getKey(keystore,filter).
>> This keystore could match CSP name or PKCS#11 library. All keystores
>> should be queried if no keystore provided.
>> *Could this be possible?*
>>
>
Any answers about this?



>> Some examples, like [5] will be much appreciated.
>>
>>
>> High-Level API: [6]
>>
>> *Cant this document be merged with [1] as callbacks?*
>>
>
> Considering that David Dahl is no longer with Mozilla and, to the best of
> my knowledge, no longer participating in this group, I suspect that either
> another (WG member) needs to step up as editing or, as discussed during the
> eBay F2F, this document be discontinued and removed. Harry?
>

Thank again you for your answers Ryan!