Allow to import existing certificate

[arielt]

In-browser, RTCPeerConnection provides an option to generate RTCCertificate or can generate it by itself.
https://w3c.github.io/webrtc-pc/#dom-rtcpeerconnection-generatecertificate

It would be helpful to allow it to import existing certificates, for instance when we want to use the same certificate for communication with signalling server.

Generator with such functionality(FromPEM) is already implemented in Chromium code:
https://github.com/chromium/chromium/blob/0aee4434a4dba42a42abaea9bfbc0cd196a63bc1/content/renderer/media/webrtc/rtc_certificate_generator.h

[atsakiridis]

Given that WebRTC needs separate signaling protocol for which we typically need a certificate and everyone is striving for better and better connection times, I think this is will help a bunch.

[martinthomson]

Having a site provide a private key would enable a bunch of attacks. And besides, private keys shouldn't move.

Let me ask: what is your use case?

[lgrahl]

Can't tell about their use case but I have one: I already have a session key established using SaltyRTC signalling and I would like to have the possibility to derive a private key from that instead of being given an arbitrary private key (I don't care about the certificate).

[martinthomson]

@lgrahl, if your intent is to use an existing context to validate the session, then that is what the IdP process is for. On the other hand, having the site in control of the private key undermines all of the protections provided by that system.

[arielt]

@martinthomson Sure. Let's say for signalling, I want to use websockets, in secure mode + authenticating client's certificate. To setup such communication I need to issue CA-signed certificates and let CA be known both to server and browser.

Now, let's say for WebRTC channels, I want to pin certificates. Since I already have one certificate, CA-issused, I'd like to use that, to authenticate the same entity, rather than generate a new one.

I understand the argument that certificates should be managed outside of the in-browser code, like websockets do, but since we already have an ability to generate it with RTCPeerConnection API, not sure why it would be much worse to allow to import it.

[lgrahl]

This is roughly similar to my use case but yours fits more into the certificate environment, so I'll hold back my use case since it requires to elaborate quite a lot.

@martinthomson Suppose the other peer expects a specific certificate (I think @steely-glint does something like that - maybe you can comment here, too?). Although I think it's already possible to store such a certificate using Web Storage, it's not possible to create a backup or import a certificate.

[martinthomson]

The reason you expect a particular certificate is because it is the same entity. Allowing import would undermine Tim's use case as much as anything else.

[steely-glint]

I agree with @martinthomson that allowing the importing a server-made cert causes more trouble than it solves (in my usecase at least).

I have wondered about the feasibility of having a server sign the browser made cert (instead of it being self-signed). This would allow the provenance of a call to be evaluated in cases where the media processing is separated from web service. This isn't a use case I personally care about, it's more of a telco gateway thing.

[lgrahl]

@steely-glint I guess that's where IdP could come into play instead of getting the certificate signed.

I realise at least my current use case is hard to justify (setting the private key of the certificate). Since I trust the browser to implement WebRTC safely, I guess I should trust it to generate a safe private key, too.

[aboba]

@lgrahl @marthinthomson Yes, certificates, once created, can be stored to IndexDB and subsequently restored. So a scenario requiring persistence can be implemented (and is supported in Chrome today).

[aboba]

@arielt Moving from self-signed certificates to certificates chaining to trust anchors is a considerable change and could require support for validation configuration, not just certificate importation. For example, in a scenario where the browser attempts to validate a gateway certificate, you'd probably want to restrict the valid trust anchors (e.g. to just the CA of the gateway).

[martinthomson]

Firefox also supports persisting of certificates (and their corresponding keys).

@aboba, I don't think that this would necessarily need validation, though it certainly suggests that it would have value. If we were to do anything here, I'd suggest that it be to support signing of certificates by a CA. That's a pretty cumbersome process that involves exporting a PKCS#10 CSR and importing the signed certificate (including validation of the same). We'd need significant motivation to support even that.

As stated, this could be used to subvert the security mechanisms we have implemented. It's not mere trouble as Tim suggests, but a full-blown undermining of our identity mechanism. I would recommend closing this, then opening other issues to track the stated alternatives if those are still desirable.

[steely-glint]

One thing I did yearn for when I was looking at this from a telco/pbx perspective a few years ago was the ability to use the same client certificate in webRTC as was used in the https which downloaded the origin page.
The reason being that telcos like to split the media from the signalling at as early stage as possible, this might allow the media provenance to be identified in a media server (and billed for) in a way that the IdP mechanism would struggle to do.
This could probably be done by an extension of the existing IndexDb certificate storage.
However I'm not convinced that there is any current demand for it, you'd need to ask others closer to the PBX space to know.

[lgrahl]

@martinthomson I'm a little confused by this... I don't think anyone is suggesting to do the signing process inside of the browser. IIRC it's just about importing a certificate (possibly including an intermediate certificate) that may or may not be self-signed.

[martinthomson]

@lgrahl, maybe you could help by explaining whether this is importing a certificate (for an key generated by the browser), and importing a certificate plus private key. I inferred the latter from the OP based on the qualification of existing certificate. If it's the former, then my concerns about this destroying security mechanisms go away, it's merely a question of utility.

[lgrahl]

@martinthomson The latter indeed - importing a certificate (chain) and a private key. I guess I was confused by you mentioning the CSR. Still, I don't understand what kind of security mechanism this would undermine but I'm not an IdP expert.

[martinthomson]

If a site can install a private key and certificate on two different browsers - which is what this would enable - then that implies two things:

1. the site has access to the private key - the site can impersonate the browser
2. both browsers have access to the private key - each browser can impersonate the other

In particular, the latter means that an identity assertion obtained by one user can be used by a completely different user.

[lgrahl]

I had to glance through the IETF draft to understand that... this is because only the fingerprints are included in the identity assertion, right? Now the RTCWeb mailing list makes more sense to me, too. And I would be in favour of the idea to bind the assertion to the session and the cert (instead of only the latter).

Let's put the IdP issue aside for a moment. The site would have access to the private key, correct. Is there a problem with that (other than malicious third party scripts)?

[arielt]

@aboba Certificate chaining is asking for itself, but I'd limit the scope of this proposal only to the import of the certificate (BYW, if I wasn't clear, the certificate should include private key), both from the holistic implementation point of view, product point of view - to see if there will be an ask for chaining, and also some conceptual stuff, that I hardly can reason about right now - should be there an authority in P2P communication?

@martinthomson In my mind, importing certificate means importing private key as well.
I can confirm that generated RTCCertificate can be happily stored in indexed DB and re-used afterwards. As such, I can put same RTCCertificate in 2 different browsers even today, so again don't see how my proposal makes anything less secure. I just propose to expose an ability to create RTCCertificate from some existing one.

[martinthomson]

@arielt, are you suggesting that you are copying the indexedDB backing store from one machine to the other? I don't think that's the same as providing an API to install a key.

@lgrahl, yes, having a private key known by more than one entity is bad. Leave aside the possibility that a site might be compromised, the fact that a site can now impersonate me is a big deal.

[lgrahl]

@martinthomson The browser can also impersonate me. It's a question of how much you trust a specific part of the application and, granted, this level of trust can be different between sites and users. I've always advocated the opinion that if a site is compromised, there are no security guarantees for what happens on the site itself. It doesn't need to impersonate you. It can just create a new peer connection and send your data somewhere else. Nevertheless, I see your point that it is a rather large attack surface.

[martinthomson]

Having a browser impersonate its users is its primary function. That is done with user permission, or that is a failing in the browser. Sites impersonating users without their knowledge or control is something browsers are tasked with preventing.

[alvestrand]

My personal opinion is that exporting secret keys should be a "just say NO", and importing secret keys needs to have a VERY good use case to justify it.
Exporting public keys for signing and re-importing the signed cert may make sense, but as Bernard says, this is not a simple thing to introduce.

[aboba]

This discussion has already pointed out some potential security vulnerabilities from the existing mechanism (such as the problem Martin has addressed in PR #1870 ). At this stage, I'd prefer to focus on enumerating and fixing all of those than adding yet more surface area.

[alvestrand]

Closing this issue.
Conclusion:

• We're not going to allow importing private keys for use in generating fingerprints.
• Adding API to let a CA sign the browser-generated key is a major undertaking, and needs similar major documentation of the benefits. At the moment, it's not a priority item.

[ibsusu]

This was a shortsighted decision. It would have been good if this was designated as a privileged api instead of outright saying no. Extensions exist too.

[kraskixxx]

Firefox also supports persisting of certificates (and their corresponding keys).

@aboba, I don't think that this would necessarily need validation, though it certainly suggests that it would have value. If we were to do anything here, I'd suggest that it be to support signing of certificates by a CA. That's a pretty cumbersome process that involves exporting a PKCS#10 CSR and importing the signed certificate (including validation of the same). We'd need significant motivation to support even that.

As stated, this could be used to subvert the security mechanisms we have implemented. It's not mere trouble as Tim suggests, but a full-blown undermining of our identity mechanism. I would recommend closing this, then opening other issues to track the stated alternatives if those are still desirable.

Are there any sample about Firefox about import an existing certificate ?