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

> On Jun 25, 2015, at 9:47 AM, Mark Watson <watsonm@netflix.com> wrote:
> 
> 
> 
> On Thu, Jun 25, 2015 at 8:21 AM, Billy Simon Chaves <b.simon@hermes-soft.com <mailto: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 <mailto: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?
> 
> ​"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.
>  

You are touching two sensitive issues: access control to the private key and trust on the application requesting a digital signature.

Access control to the private key is a critical issue and it has to be dealt at the lowest possible level.  Most scenarios involving digital signature I can think of requiere at minimum:

The private key is locally generated and stored in the user’s device.
The private key has to be securely stored and protected by a strong password or passphrase known only by the user
The private key can not be used without explicit authorization from the key owner.

Those requirements are needed to guaranty authenticity and no repudiation of the digital signatures and can not be delegated to a higher level APIs.

It is hard for me to come up with real live scenarios involving signing documents, transactions or messaging where:
my private keys are generated by a third party and then somehow delivered to my device
a site can ask the UA to generate a digital signature using “my" private key without asking for my permission every single time.  Maybe that's not user friendly, but to me it is dangerous if a site can use my private key without my explicit authorization.

Regarding trust I think that’s up to the user and the application he is using. The UA should not make that decision for the user.  The API signs a hash of the actual data so it can not tell what data is actually being signed. A well behaved application must present the whole information that is being signed when requesting a digital signature, in order to allow the user to read and probably keep a copy of the information that he is going to sign.

The role of the UA regarding trust is:
Guaranty that the private key remains private and is not used without authorization
Provide evidence of the identity of the site requesting the digital signature, so the user can decide whether to trust or not
Make sure that a signature requested by a site is only delivered to that site and can’t be stealed by another site

There are other issues involved in real live scenarios that any one using WebCrypto will have to cope with:
Key expiration and revocation. Are keys going to live for ever or will the expire? if I found out that my key is compromised how I tell the site that revoke it?
Public key distribution and trust (how can Bob be sure he has Alice public key? do I trust to the site? whats the process the site follows to identify and issue keys for its users)
Long time validation of digital signatures, for instance validating a document signature signature many years after It was made
To me it seems that applications using webcrypto will have to assume many of the current CA’s responsibilities...




> 
> 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
>> 
>> 
> 
>