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

Hi All,

Just a short note, working at neXus Group a company that produces a smart
card middleware and CA software I would have like the WebCrypto group to
have prioritised work to find a solution where keys and certificates from
secure elements could have been exposed to web sites in an acceptable way.
I see this need everyday in for example the case presented by Billy a
nation hands out eIDs on smart cards and the citizens are using them to
sign documents and transactions in the web browser. neXus is one of all the
companies that has created a proprietarian solution for this in Sweden.

I think that WebCrypto will be useful but in a quit limited way, since one
can put limited trust in the keys. I can absolutely see that it is possible
for one to build a layer with certificates on top of web crypto using local
storage and e.g. PKI.js however with SOP enforcement the usefulness will be
limited since the nature of PKI is to go beyond such borders (validation is
possible wherever the CA is trusted) by keeping inside SOP there is no need
for the I in PKI.
I like FIDO but think it suffers from some of the same limitations and it
only addresses one of the three use cases that is addressed with asymmetric
cryptography, authentication, then there is encryption and Signing which is
equally important (IMHO). Finally one can argue the need for fido with a
more and more federated environment.

Whit that said I think that those of us searching for a possibility to use
smart cards from the browser will have to look elsewhere, e.g an improved
and standardised version of Google Native Messaging could be great. Then we
also have to consider that Smart cards might not be the future for national
eIDs, e.g. in Sweden we have migrated to a mobile version and I can see
that happening in country after country and then a completely different
approach is needed.

Best Regards
Samuel Erdtman
(Product Manager at neXus Group)






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

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