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

Thanks for your answers Ryan, so sad there no hope left for the users
neither us (sounds quite dramatic, isnt it??)
Have a nice weekend!


On Thu, Oct 24, 2013 at 6:36 PM, Ryan Sleevi <sleevi@google.com> wrote:

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