KeyingMaterial internal slot

Fix for Issue #832

index.html

@@ -10843,14 +10843,18 @@ <h3>Example</h3>
     <h2>Certificate Management</h2>
     <section id="rtccertificate-overview*">
       <h3>Overview</h3>
-      <p>The <code>RTCCertificate</code> interface enables the certificates
-      used by an <code><a>RTCDtlsTransport</a></code> or <code><a>RTCQuicTransport</a></code>
-      to be provided in the constructor. This makes it possible to support forking, where
-      the offerer will create multiple <code><a>RTCDtlsTransport</a></code> or
-      <code><a>RTCQuicTransport</a></code> objects using the same local certificate and
+      <p>The <code>RTCCertificate</code> interface represents a
+      certificate used to authenticate communications. In addition to
+      the visible properties, internal slots contain a handle to the
+      generated private keying materal (<dfn>[[\KeyingMaterial]]</dfn>) and a certificate
+      (<dfn>[[\Certificate]]</dfn>]]).</p>
+      <p>Certificates are provided in the constructors of
+      <code><a>RTCDtlsTransport</a></code> and <code><a>RTCQuicTransport</a></code>
+      objects, and are used to authenticate to a peer. This makes it possible
+      to support forking, where the offerer creates multiple <code><a>RTCDtlsTransport</a></code>
+      or <code><a>RTCQuicTransport</a></code> objects using the same local certificate and
       fingerprint. Also, an <code>RTCCertificate</code> can be persisted in
-      [[INDEXEDDB]] and reused. Persistence and reuse also avoids the
-      cost of key generation.</p>
+      [[INDEXEDDB]] and reused, so as to avoid the cost of key generation.</p>
     </section>
     <section>
         <h2><dfn>RTCCertificateExpiration</dfn> Dictionary</h2>
@@ -11061,6 +11065,40 @@ <h2>Methods</h2>
           </dl>
         </section>
       </div>
+        <p>For the purposes of this API, the <a>[[\Certificate]]</a> slot
+        contains unstructured binary data. No mechanism is provided for
+        applications to access the <a>[[\KeyingMaterial]]</a> internal slot.
+        Implementations MUST support applications storing and retrieving
+        <code>RTCCertificate</code> objects from persistent storage.
+        In implementations where an <code>RTCCertificate</code> might not
+        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 used.</p>
+        <p>When a <a>user agent</a> is required to obtain a structured
+        clone [[!HTML51]] of an <code>RTCCertificate</code> object,
+        it performs the following steps:</p>
+        <ol>
+          <li>Let <var>input</var> and <var>memory</var> be the corresponding
+          inputs defined by the internal structured cloning algorithm, where
+          <var>input</var> represents an <code>RTCCertificate</code> object to
+          be cloned.</li>
+          <li>Let <var>output</var> be a newly constructed
+          <code>RTCCertificate</code> object.</li>
+          <li>Copy the value of the <code>expires</code> attribute from
+          <var>input</var> to <var>output</var>.</li>
+          <li>Let the <a>[[\Certificate]]</a> internal slot of <var>output</var>
+          be set to the result of invoking the internal structured clone
+          algorithm recursively on the corresponding internal slots of
+          <var>input</var>, with the slot contents as the new
+          "<var>input</var>" argument and <var>memory</var> as the new
+          "<var>memory</var>" argument.
+          </li>
+          <li>Let the <a>[[\KeyingMaterial]]</a> internal slot of <var>output</var>
+          refer to the same private keying material represented by the
+          <a>[[\KeyingMaterial]]</a> internal slot of <var>input</var>.
+          </li>
+        </ol>
     </section>
   </section>
     <section id="privacy-security">