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

On Thu, Oct 24, 2013 at 1:11 AM, Ryan Sleevi <sleevi@google.com> wrote:

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

My keys are on NSS/smartcard/Keystore/keychain.
IMHO, i think *these functions should be replaced with keystore integratio*n
(so importing on NSS/PK#11/CSP will let the key accesible to Webcrypto), as
a consequence, this functions shoudl dissapear from draft.



>
>
>>  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?
>
Probably you are correct.
Signind documents, doing authentication based on certificates, electronic
invoices and such things use -regularly- RSA certificates installed on
keystore, and using those keys though Webcrypto will have a lot of sense.
An alternative for Java/signText is what end user need, and thats what im
talking about.



>
>
>>
>>
>>>
>>>>
>>>> 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.
>
If you understand what im talking about, you will probably see my point.
Maybe we think the same, but im lost on translation.
The question is much more simple:
Do you guys in the WG have in mind "people using their browser installed
personal certificate to do -for example- electronic signatures of a PDF"
using Webcrypto?

IMHO, WG proposals should care about this and let the users "use" the
implementation of this standard. I can request a user to import a pkcs#12
each time he wants to sign (if i understand properly how importKey works)

Again, maybe its my lack of english.


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

Probably i miss something. Can you provide me a link about how this
"structured clone" works? I'll appreciate that


>
>
>> 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!
>>
>>
>
Thanks for the answers!