Re: [Web Crypto Next] Lets start discussing !

Before we bury us in details regarding underpinnings like PKCS #11
I think the key access model must be more or less settled
(agreed upon) as it was with the original WebCrypto effort.

If this is already fixed (=SOP) most people attending the work-shop
in Mountain View won't be able to use the outcome of WebCrypto.Next,
they will rather have to take the "app" route [1].

Pardon for bringing up a controversial issue but it appears better
taking difficult decisions upfront than finding out somewhere in the
middle of the journey that we are not even looking at the same map...

Since it is the browser-vendors that eventually have to support the
solution, the ball is effectively in their court.

Anders
1] http://techcrunch.com/2012/09/11/mark-zuckerberg-our-biggest-mistake-with-mobile-was-betting-too-much-on-html5/

On 2014-10-29 15:10, Sean Michael Wykes wrote:
>
> On 29 Oct 2014, at 12:50, helpcrypto helpcrypto <helpcrypto@gmail.com <mailto:helpcrypto@gmail.com>> wrote:
>
>> On Wed, Oct 29, 2014 at 10:30 AM, Sean Michael Wykes <sean.wykes@nascent.com.br <mailto: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 think PKCS#11 spec would be an excellent underlying fit for the “middle”-level box that integrates with Web-Crypto, especially when the key discovery mechanism (and cert-discovery) can be used to get a handle on a group of PKCS#11 objects, specifically the triple private-key, public-key and certificate, matched by the same object-id (CKA_ID) as per actual NSS implementation. The PKCS#11 security-model AFAIK is somewhat restrictive (only supporting User-PIN/SO-PIN), with per-token access-control, and thus relatively easy to support.
> Cross-browser issue: Will MS support PKCS#11 in IE?
>
> The “use” of PKCS#11 with pre-provisioned keys and certs is a low-hanging fruit. Your proposed extension would be excellent for this. However, supporting provisioning of tokens, key-generation, certificate-less keys, pin-unblock and the many edge-cases is a bit more difficult.
>>
>>
>>     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.
> I agree, if we can see a route forward to supporting the rest (provisioning, admin) and an adequate security model.
>
> One thing that troubles me is how to “increment” security or functionality of any “first-try” solution, once we have an advanced solution available. What is to stop a compromised web-site from calling the “first-try” solution as a means of bypassing higher-level security checks.
>
> For example, if we give APDU access to smart-cards/sim-cards/secure-elements, how can we ensure that these won’t be used to bypass the security of a PKCS#11 module, or even a higher-level “sign what you see” function that may be made available sometime later?
>>
>>     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 <http://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)
> Two or three cases here - user-controlled, domain-controlled and “open” (multiple-domain, any-domain).
> For the PKCS#11 case, you could probably just default to a “user-controlled” permission (do you want to allow siteX to access certificateY for signatures/encryption [y-once]/[y-forever]/[n]).
>
> Permissions for the token-administration/provisioning case are more sensitive.
>
>>
>> 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
> OK. I don’t think the current CryptoAPI even deals with PINs, so whatever method is deemed more acceptable would be ok.
>
>>
>>
>>     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
> Also agree. Each use-case (open-ID, corporate, COTS) has different requirements and can support more/less admin overhead. Going forward, this would ideally be plug-and-play or browser-downloadable for new solutions.
> The middleware question is a thorny one, since it envolves platform issues, win/nix/mac/mobile, 32/64 bits, etc.
> IMHO, an interesting solution would be a standard cross-browser “plugin” architecture, using javascript, signed-code etc, but we are a long way from this, chrome/firefox/IE extensions are totally incompatible, let along android/iOS.
>
>>
>> Thanks a lot for your answers.
>>
>

Received on Wednesday, 29 October 2014 14:45:35 UTC