Whether KeyingMaterial internal slot can be stored and retrieved #1723
Conversation
Clarification for Issue #1694
|
@ekr Can you review? |
webrtc.html
Outdated
| @@ -4626,7 +4626,8 @@ <h2>Methods</h2> | |||
| contains unstructured binary data.</p> | |||
| <p>Note that an <code>RTCCertificate</code> might not directly hold | |||
| private keying material, this might be stored in a secure module.</p> | |||
| <p>The <code>RTCCertificate</code> object can be stored and retrieved | |||
| <p>The <code>RTCCertificate</code> object, with the exception of the | |||
| the <a>[[\KeyingMaterial]]</a> internal slot, can be stored and retrieved | |||
There was a problem hiding this comment.
This isn't necessary. The object can be stored and retrieved, including the KeyingMaterial internal slot.
Firefox implements this. An RTCCertificate can be stored to indexedDB and later retrieved and used. This is exactly the same process that we use for keys in WebCrypto. See https://w3c.github.io/webcrypto/Overview.html#concepts-key-storage
There was a problem hiding this comment.
So the keying material can be stored on storage that is persistent to the browser, but there's no way of getting it out so that it can be accessed by the Javascript client, is that right?
#1694 was complaining about using the word "persistent" for that kind of storage.
There was a problem hiding this comment.
If private keying material is held in a secure module, does this affect the ability to store and retrieve the KeyingMaterial internal slot? Just trying to understand what the requirements are for storing and retrieving certificates. Typically the term "persistent" implies the ability to persist across reboots.
There was a problem hiding this comment.
What happens here is that the keying material is stored however the browser can. If it is in a secure module, the browser needs to store a handle to the stored keying material so that it can be used again. If the secure module goes away, then it won't be available until it comes back. It's still persistent though in the sense that if the machine reboots, it's still there unless the user explicitly wipes the storage (or the module).
Javascript can never directly use these keys, it can only ask the browser to use them in certain predefined ways. Just as the browser can't use the keys directly if there is a secure module in use, it can only ask the secure module to use them in predefined ways. For these keys, they can only be used to make new WebRTC connections.
webrtc.html
Outdated
| <code>RTCCertificate</code> might not directly hold | ||
| private keying material, this might be stored in a secure module, | ||
| in which case the <a>[[\KeyingMaterial]]</a> internal slot might not | ||
| be storable and retrievable. When a <a>user agent</a> is |
There was a problem hiding this comment.
If we store it and retrieve it on the same host, would we assume that the KSM can still be accessed?
There was a problem hiding this comment.
all the web crpto seem pretty vague about this. I think the answer is "maybe". AFAIC this is all way under specified. So for example, if the user and told the browser to clear the locally storage, it would almost certainly be gone - I think it is often tied to saving in a one of the web databases / local storage options. So if that is gone, it is probably gone even if it is still in the KSM. How memory on the KSM is ever reclaimed is not clear to me. But .... I don't think we can fix this in WebRTC spec.
|
@fluffy @martinthomson Can you review at the updated PR? |
|
The current text implies that the private keys would need to be extracted from the KSM when doing a structured clone. That's not possible in the general case. I think that instead we need some sort of failure mode for the case when one of these is used. That would also cover the case where you made a cert and the KSM with the private key was removed/flushed before use. |
webrtc.html
Outdated
| represents a handle to both the certificate and the private key, | ||
| implementations MUST support storing and retrieving both the certificate | ||
| and private key, even if the <code>RTCCertificate</code> stores the private | ||
| key in a secure module. When a <a>user agent</a> is required to obtain a |
There was a problem hiding this comment.
Suggested text:
Note that there is no way to access the private key, so it doesn't matter to the user whether the private key is stored directly or if it is stored as a reference to some other key storage such as a KSM.
|
@martinthomson @alvestrand PR updated to clarify that the [[KeyingMaterial]] slot is not accessible by the application, and could represent a reference to the key material stored in a KSM, permitting storage and retrieval as well as structured cloning. |
webrtc.html
Outdated
| directly hold private keying material (it might be stored in a | ||
| secure module), a reference to the private key can be held in | ||
| the <a>[[\KeyingMaterial]]</a> internal slot, allowing the | ||
| private key to be stored and retrieved.</p> |
There was a problem hiding this comment.
Perhaps change "retrieved" to "used"
|
See also #1089 |
Clarification for Issues #1694 and #1739