Origin-bound versus origin-unbound keys

FWIW, let me bring you some input regarding some existing (built-in and proprietary) browser applications that use origin-unbound keys:

Keys: X.509 certificates

Key Selection: UI + optional filter like TLS's issuer + Key Usage
(in some cases the issuer has a specific key-container solution which removes this part)

Key Discovery: Never in the browser layer

Key Algorithm selection: Usually not selectable

Sample Applications: Mozilla's signText (), HTTPS URL reference

The only mainstream application that doesn't follow this scheme I'm aware of is Microsoft's "CertEnroll".
However it comes at a price: A gazillion security/privacy dialogs that no ordinary user can understand.

I don't see any legitimate reason for exposing such keys through a browser-API, the existing methods are quite satisfactory, only the "filtering" could need an upgrade.

I could though imagine something like:

    unboundCertificateOperation ("filter stuff", operation, "arguments");

where "operation" is a small set of predefined high-level operations.  OTOH, the advantage over building all in one price seems marginal.


Regarding origin-bound keys I don't see any problems.  They are as somebody noted close to cookies.


Pre-provisioned origin-bound keys should IMO be addressed through an X.509 extension; I'm sure that issuers would like to have the ability to shield their users from logging in to a fake site using "their" credentials.

Anders

Received on Tuesday, 7 August 2012 07:54:09 UTC