On 2013-02-15 11:32, helpcrypto helpcrypto wrote:
>> The problem with this approach is that you expose keys to arbitrary
>> javascript
>> code which is rather different to for example TLS-client-certificate
>> authentication which only exposes a high-level mechanism as well as a
>> [reasonably] secure credential filtering scheme and user GUI.
>
> clear as water.
>
> Shouldnt we be able to expose "key handles" rather than keys?
Yes, that's was the intention.
> ie: javascript invoke getKeyFromPKCS11("modulename") and "#1" is
> returned, but can be used.
How do you envision that this access should be controlled?
Here imagine that you have dozens of keys, not just a single key in a smart
card.
A difference to keys compared to for example "your location" (which is
exclusively your resource) is that keys in most cases are given to users
by external providers. The providers do not want their keys to be misused,
particularly not by users who accidentally made the wrong trust assertion.
A scheme that doesn't take this in account IMO has little chance of getting
market acceptance.
In my professional life I deal with PKIs for EAC (Extended Access Control)
which is used in e-passports for selective access to biometric information.
Using EAC it is the *passport* that grants access based on credentials provided
by the inspection systems so what I'm proposing is by no means a "novelty";
it just haven't reached the web. Yet.
Anders
>
>
>> Traditional signed code is IMO rather lame since anybody can buy
>> a valid code-sign certificate. I.e. a code signature from someone
>> you never heard about is doesn't add much to the table.
>
> Agree
>
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
