W3C home > Mailing lists > Public > public-web-security@w3.org > October 2014

Re: [Web Crypto Next] Lets start discussing !

From: helpcrypto helpcrypto <helpcrypto@gmail.com>
Date: Fri, 31 Oct 2014 09:00:29 +0100
Message-ID: <CAHMQSguLmi1hrtKX=9C4Tu74QH8SB_ofwS_ibKQHoDw2zduf6Q@mail.gmail.com>
To: Sean Michael Wykes <sean.wykes@nascent.com.br>
Cc: Anders Rundgren <anders.rundgren.net@gmail.com>, public-web-security@w3.org
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

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?

Received on Friday, 31 October 2014 08:01:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:33 UTC