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

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 <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 <http://hermes-soft.com/signing>. However, if evilhacker.example.com/muahaha <http://evilhacker.example.com/muahaha> was able to get access to your private key (using the exact same mechanisms that hermes-soft.com/signing <http://hermes-soft.com/signing>), then evilhacker.example.com <http://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 <http://evilhacker.example.com/> could make you think the prompt is coming from hermes-soft.com/signing <http://hermes-soft.com/signing> (via timing attacks) when it's actually coming from evilhacker.example.com <http://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?

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 <mailto: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 <http://www.hermes-soft.com/>
> 
> 
> 
> 
> 
>> On Jun 24, 2015, at 3:00 PM, Ryan Sleevi <sleevi@google.com <mailto:sleevi@google.com>> wrote:
>> 
>> 
>> 
>> On Wed, Jun 24, 2015 at 1:50 PM, Jeffrey Walton <noloader@gmail.com <mailto:noloader@gmail.com>> wrote:
>> I see the WebCrypto API will allow discovery of keys
>> (http://www.w3.org/TR/WebCryptoAPI/ <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
> 
>