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

On Oct 24, 2013 3:16 AM, "helpcrypto helpcrypto" <helpcrypto@gmail.com>
wrote:
>
> 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
integration (so importing on NSS/PK#11/CSP will let the key accesible to
Webcrypto), as a consequence, this functions shoudl dissapear from draft.

Thank you for your feedback. This use case was already discussed and placed
out of scope. Your proposal has significant UI and security concerns that
are not readily ameliorated.

Do not expect to see this in version one.

Further, do not expect to see importKey disappear. I already described how
they have use regardless of your preferred API.

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

Thank you for your feedback on what end users need. I believe we disagree
on this, rather significantly, but it is helpful to understand.

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

No. I have repeatedly said this is out or scope for our first effort.

Please read our charter, which makes this clear as well.

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