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.