RTCCertificate Interface should (or should not) be backed up.

[steely-glint]

in "4.10.2 RTCCertificate Interface"
we say
"The RTCCertificate object can be stored and retrieved from persistent storage by an application. "
It isn't clear if this should be backed when the rest of a browser is backed up or indeed sync'd (i.e. bookmarks etc).

In contrast to the rest of localStorage, there is no mechanism for a service to access the privateKeys - so no way for them to be backed up and restored (e.g. in case of a phone being immersed in water).

What is the intended behaviour?

[aboba]

@steely-glint Section 4.10.2 states:
"Note that an RTCCertificate might not directly hold private keying material, this might be stored in a secure module."

The secure module will generally not support retrieval of the private keying material so that we can't assume that private keying material can be stored and retrieved from persistent storage, only the public keys.

[steely-glint]

I guess I'm taking issue with the 'persistent storage' - I'd argue that something that can't be backed up shouldn't be described as persistent.

So I feel we should either change the 'persistent' to something else or we should specify a mechanism to back up the keys - ideally both public and private.

[aboba]

@steely-glint Here is my take on the intended behavior. The specification says that the RTCCertificate represents a handle to both the X.509 certificate and the private key. That would seem to imply that when the RTCCertificate is stored and retrieved, that always includes both elements, regardless of whether the private key is stored in a secure module. The format for storage/retrieval isn't specified, but any format that can represent both the certificate and private key (e.g. PKCS12, PEM, etc.) would suffice. The storage is "persistent" across reboots, but while there is an internal slot for the private key, it cannot be retrieved in JS.

Does this make sense?

[steely-glint]

Yes, I think that is the intended behavior.
I do question however if it is the expected behavior - especially for web devs.
Everything that represents state I can think of in a browser can either be backed-up or at least sync'd with other instances of the same browser on different devices that are owned by the same user.

From the user's perspective, if I have my phone stolen and I remote reset it, I expect to be able to restore all my apps and their state onto a new phone (assuming the replacement supports the same os).

These certs are the single exception I can think of to that experience. If that is the intention, we should clearly state it, possibly flagging their semi-ephemeral nature with a warning to developers.