Re: [Web Crypto Next] Lets start discussing !

On Wed, Oct 29, 2014 at 10:30 AM, Sean Michael Wykes <
sean.wykes@nascent.com.br> wrote:

> Hi Nick / Anders / All,
>
> Just like to add a couple of thoughts on the below.
>
> The use-case you presented on document-signatures is extremely relevant to
> a number of real-world situations, and thus I believe should be considered
> by the WG. Your suggested additions to the Web-Crypto API, findX509 etc,
> seem  a great match for the “use” case, by which I mean the USE of the keys
> and certificates for signature creation, given that the underlying “box”
> implementation supports at least a PIN verification dialog, and a
> permissions system that will allow the user to choose which origens can use
> which certificates.
>
> Note however, that these last two points are issues that raised somewhat
> conflicting positions during the workshop.
> 1. Browser-controlled UI - should the browser be responsible, and to what
> extent.
> 2. Permissions - how to reconcile permissions between two currently
> distinct universes - smart-cards and web.
>
> The first issue rapidly becomes complicated, since although you may start
> by specifying a simple PIN entry dialog, you must maybe consider issues
> such as valid PIN lengths, allowed character sets (numeric, alphanumeric,
> symbols) as defined by some cards, different PINS for different keys or
> certificates, biometrics, PIN-error handling, retries, blocked-PIN
> handling, the list just goes on and on.
>
Will PKCS#11 spec fit those requirements?



> I’m sure we can define a baseline, applying the KISS principle, and maybe
> get a standard dialog, but then what about identification (enter pin for
> “X” certificate on “Y” card), branding (which site), and principally intent
> (enter PIN to sign important document … )? All pertinent points.
>
I agree with you that the "you are going to sign this:" dialog could be not
the perfect solution, but:
 -Actually you dont know what u signing, or even worse, a dialog saying
<node><element Id="foo"...> is shown. WTF!!!
 -A browser showing what the developer sent to sign (PDF preview or
XML+XSLT) and what the user is going to sign will improve the current
scenario.
Perhaps not the best solution, but its a first step to refine the use case.



> The second issue is, I believe, more tricky, since you have a very simple
> model from the web side (single/same-origin), and a more complex one on the
> card side. Should card permissions be controlled at the card, application
> (AID) or stored-object (certificate) level?  User-defined (via
> “camera”-style “permit access to ..”), or card-defined (a lá Global
> Platform)? I believe we need to discuss this more openly, and in more
> detail, to come to any conclusion.
>
IMHO the permissions should be defined by the owner of the key.
If an enroll company doesnt want their certificate to be used outside
___domain.com, the certificate should state that.
If PKI doesnt support this, then a workaround could be done: the signature
(done with user cert) is not valid until authorised/approved by company
(counter-sign)

Anyhow, as you said, theres a lot to discuss in here.



> As per batch-signing, can you implement this in your web-application
> without requiring special functionality from the web-crypto API?  Or do you
> need at least a “beginMultiSignature” .. “endMultiSignature” pair in the
> API?  Can a time-limited PIN cache help with this?
>
I dont know if current API allows multiple document signing with just one
PIN request. A cached pin could do the trick


If we can solve / decide on these issues, I think your API extension would
> work. Of course, you must still install the PKCS#11 module into the
> browser, and maybe deal with a MS-CAPI alternative, or should MS implement
> a PKCS#11 adapter in IE ?  How could this work for your use-case and
> customers?
>
We are deploying middleware on controlled-environments and request the user
to install it on unmanaged ones.
I partially-agree with Anders: requiering the end-users install middleware
sucks, but this API will improve current state of the art of Webv
Cryptography


Thanks a lot for your answers.