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

Hi.
from the members of WebCrypto WG,
different views of key-ownership are exist.

if the key is owned by USER, helpcrypto's comment has meaning.

if the key is owned by key provisioner (normally servers), Ryan's comment
has meaning.

at least, I think the key should be owned by user. (means fully controlled
by user not server side)

the server can initiate crypto operations but
user consent is required for important operations (like signing) .

just different view. both are correct.

current draft is not based on user ownership.

regards
mountie.



On Thu, Oct 24, 2013 at 7:16 PM, 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
> 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!
>



-- 
Mountie Lee

PayGate
CTO, CISSP
Tel : +82 2 2140 2700
E-Mail : mountie@paygate.net

=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World