Re: Will the WebCrypto API allow discovery/enumeration of certificates?

On Thu, Jun 25, 2015 at 8:21 AM, Billy Simon Chaves <b.simon@hermes-soft.com
> wrote:

> Thans Ryan for you detailed answer,
>
> On Jun 25, 2015, at 12:57 AM, Ryan Sleevi <sleevi@google.com> wrote:
>
> Billy,
>
> I'm a bit surprised that you mentioned your countries CA, but then don't
> see the privacy implications. I'm not familiar with Costa Rica's eID
> scheme, but under much of the eIDAS regulation in the EU, the certificates
> contain a variety of uniquely-identifying PII, such as the users name,
> their government-assigned ID, and, in some cases, biometric or photographic
> identifiers.
>
>
> I get your point. In my country, Costa Rica, certificates only have the
> subject's name and national ID.  That information is already public and you
> can download it from our national registry official site (
> http://www.tse.go.cr/descarga_padron.htm). I understand that that would
> be unacceptable in many other countries.
>
> That's simply unacceptable to expose to an arbitrary webpage without
> permissions, and we should strive for APIs that function without
> permissions, as permissions are a usability pox upon users.
>
> Even if we accepted that users are willing to identify themselves to
> websites in undeniable ways, you end up with a tremendously dangerous
> security model. In your document signing case, you may have a document
> signing application at hermes-soft.com/signing. However, if
> evilhacker.example.com/muahaha was able to get access to your private key
> (using the exact same mechanisms that hermes-soft.com/signing), then
> evilhacker.example.com could cause your smart card to generate signatures
> that the user hadn't authorized.
>
> The PIN prompt is simply not a security mechanism, and it should hopefully
> be clear the various ways in which evilhacker.example.com could make you
> think the prompt is coming from hermes-soft.com/signing (via timing
> attacks) when it's actually coming from evilhacker.example.com. Even if
> the prompt included the URL, there's huge phishing opportunities.
>
>
> Digital signature stealing by a phishing site is a big concern.  No
> security mechanism is perfect, but at least the PIN prompt gives the user
> the chance to make a decision. If the PIN prompt is generated by the
> browser and includes relevant information like the site url, certificate
> name, what for the private key will be used, can not the user agent deter
> or minimize the kind of attacks you mentioned?
>

​"what for the private key will be used"

Therein lies the reason WebCrypto is not a suitable API for this kind of
use-case. WebCrypto is a very low-level ​API. Once a site has a CryptoKey
object with usage "sign" it can use it to sign any arbitrary string of
bytes. The UA could present every byte string the site wants to sign to the
user for permission, but this does not seem like a path to a very
user-friendly experience. If you provide a separate API for the site to
indicate to the UA what the key will be used for in a more user-friendly
form, how would the UA then ensure that the key was indeed only used for
that purpose ?

I suspect a somewhat higher level API is needed to support these use-cases
in the web environment.


>
> By the way, we deal with that issue in our digital signature component
> restricting which domains can use our component.
>
> Hopefully this makes it a bit more explicit the deep concerns with the
> security and why there isn't really a path forward for such keys,
> especially when alternative, modern systems exist.
>
>
> My point raising these issues is that at least in Costa Rica, sadly, we
> won’t be able to use Web Crypto with its current limitations for eGov or
> Banking or any serius applications because by law we have to use digital
> certificates issued by our national approved CAs and private keys stored in
> FIPS 140‐2 level 3.  I think that could be the case in many other countries
> that have national CA’s, I think Costa Rica borrowed its CAs model from
> Spain.
>
> Thanks again,
>
>
> On Wed, Jun 24, 2015 at 3:48 PM, Billy Simon Chaves <
> b.simon@hermes-soft.com> wrote:
>
>>
>>
>>
>> Hello Ryan,
>>
>> It is not obvious to me the privacy or security reasons why a web
>> application should not be able to enumerate trusted roots and client
>> certificates in the user certificate store. The whole point of a digital
>> certificate is that it is public. Can you elaborate on those reasons?
>>
>> Regarding security and privacy to me it is more concerning that web
>> crypto only works with private keys stored in the browser store, and
>> doesn’t allow me to use private keys stored in secure devices, like
>> physical tokens.
>>
>> For instance my application needs to be able to sign documents and
>> transactions, (something like web crypto scenario "2.4 document signing")
>> using a private key associated to a certificate issued by my country’s
>> official CA.  First my application needs to find in the user store for a
>> certificate issued by my country’s CA, that has a matching private key,
>> then ask the browser to generate a digital signature using that private
>> key, the browser ask the user for permission to use the private key (in my
>> case it has to ask for a PIN cause the private key is stored in a smart
>> card), if the user accepts the browser ask the smart card to generate the
>> digital signature.  In my case for security and privacy reasons all the
>> crypto operations are done inside the smart card, the private key never
>> leaves the smart card.
>>
>> Thanks in advance,
>>
>>
>> *Su aliado en la Web...*
>>
>> *Ing Billy Simón Ch.*
>>
>> Gerente de Tecnología
>> Tel. 2234-9900 ext 102
>> www.hermes-soft.com
>>
>>
>>
>>
>>
>> On Jun 24, 2015, at 3:00 PM, Ryan Sleevi <sleevi@google.com> wrote:
>>
>>
>>
>> On Wed, Jun 24, 2015 at 1:50 PM, Jeffrey Walton <noloader@gmail.com>
>> wrote:
>>
>>> I see the WebCrypto API will allow discovery of keys
>>> (http://www.w3.org/TR/WebCryptoAPI/):
>>>
>>>     In addition to operations such as signature generation
>>>     and verification, hashing and verification, and encryption
>>>     and decryption, the API provides interfaces for key
>>>     generation, key derivation, key import and export, and
>>>     key discovery.
>>>
>>> Certificates have public keys, and they are not as sensitive as private
>>> keys.
>>>
>>> Will the WebCrypto API allow discovery/enumeration of certificates?
>>>
>>> Examples of what I would like to discover or enumerate (in addition to
>>> the private keys):
>>>
>>>  * Trusted roots
>>>  * Client certs
>>>
>>> Trusted Roots are in the platform's trust store. Client certs may be
>>> in the trust store.
>>>
>>> Thanks in advance,
>>> Jeff
>>>
>>>
>> There are no plans from Chrome to implement such, on the hopefully
>> obvious and significant privacy grounds.
>>
>> Client certs contain PII.
>> Trusted certs contain PII and fingerprinting.
>>
>> In modern, sandboxed operating systems, such as iOS and Android,
>> applications cannot enumerate either, as those platform providers reached
>> the same conclusion.
>>
>> So no. Never.[1]
>>
>> [1] For some really long value of never
>>
>>
>>
>
>