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

On Wed, Oct 23, 2013 at 1:21 AM, helpcrypto helpcrypto <helpcrypto@gmail.com
> wrote:

> 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?*
>

Sure. If you have existing keys you want to use.


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

These allow two user agents to communicate and perform key exchange, among
other things.

There is a "Keystore" functionality - Key objects are Structured Clonable,
and thus can be stored with any persistence layer that supports Structured
Clone - such as IndexedDB.

I'm sorry you don't see the point, but perhaps you meant that you don't see
the point for your use case?


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

By "recovered" I suppose you mean how keys exist? It does say how this
happens: Structured Clone. You can then use it with any of the mechanisms
that support Structured Clone - eg: IndexedDB.

There is no need to depend on key discovery.


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

No, they're recovered using Structured Clone. Key Discovery is a separate
draft that looks to expose additional types of keys that are
(intentionally) not covered as part of the Web Crypto "base" spec.


> 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?
>

This is out of scope, as was already mentioned, so there's no need for
further comment.


>
>
>
>>> 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!
>
>