Re: [Web Crypto Next] Lets start discussing !

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

>
> 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?
>
IE should support/implement W3C stantdars, but sometimes they don't.
If Microsoft is present on the group member list, it implies they have
interest on this and we could know their position.



> 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 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?
>
If you give that APDU api (and the browsers implement it), then all this
conversation will be over.
I'll send APDUs to each car until i find mines, and then use them directly,
easily, and transparent for user.
Have anyone supported this???


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.
>
Cards itself usually have an owner/issuer.
In our case, card are from Gemalto but we, as company, are the owners.
Users dont have SO_PIN so we are the only ones capable of unlocking the
card.



On Wed, Oct 29, 2014 at 3:44 PM, Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:
>Since it is the browser-vendors that eventually have to support the
>solution, the ball is effectively in their court.

Isn't the role of W3C to tell browsers "what/how to implement"?

My bet: we have to find a solution which includes current scenario, altough
it could also expand to new approaches, but dumping smartcards isnt going
to work.


To sum-up:
 A - Although cards are not web-oriented if we find a solution to include
them in WebCrypto, it will be positive
 B - Card management (PIN/PUK) can be done by the owner/issuer or even the
user using specific applications, imho: out of scope
 C - Card usage from Webcrypto: seems we all agree its quite ok to use an
already populated card.
 D - Key usage: keys/certs could/should be restricted to specific domains
(actually hard to do it). user must know what is happening.
 E - Key provisiong: is where most of the problems arise

Are those bullets correct?

Regards.