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

Billy,

WebCrypto keys are constrained by SOP which is the fundamental feature or
problem depending to who you talk to :)

anders
On Jun 25, 2015 8:27 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
>>>
>>>
>>>
>>
>>
>
>