Script updating gh-pages from a69bcef. [ci skip]

draft-dekater-scion-pki.html

@@ -1053,7 +1053,7 @@
 </tr></thead>
 <tfoot><tr>
 <td class="left">de Kater &amp; Rustignoli</td>
-<td class="center">Expires 15 March 2024</td>
+<td class="center">Expires 24 March 2024</td>
 <td class="right">[Page]</td>
 </tr></tfoot>
 </table>
@@ -1066,12 +1066,12 @@
 <dd class="internet-draft">draft-dekater-scion-pki-latest</dd>
 <dt class="label-published">Published:</dt>
 <dd class="published">
-<time datetime="2023-09-12" class="published">12 September 2023</time>
+<time datetime="2023-09-21" class="published">21 September 2023</time>
     </dd>
 <dt class="label-intended-status">Intended Status:</dt>
 <dd class="intended-status">Informational</dd>
 <dt class="label-expires">Expires:</dt>
-<dd class="expires"><time datetime="2024-03-15">15 March 2024</time></dd>
+<dd class="expires"><time datetime="2024-03-24">24 March 2024</time></dd>
 <dt class="label-authors">Authors:</dt>
 <dd class="authors">
 <div class="author">
@@ -1121,7 +1121,7 @@ <h2 id="name-status-of-this-memo">
         time. It is inappropriate to use Internet-Drafts as reference
         material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
 <p id="section-boilerplate.1-4">
-        This Internet-Draft will expire on 15 March 2024.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
+        This Internet-Draft will expire on 24 March 2024.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="copyright">
@@ -1403,7 +1403,7 @@ <h3 id="name-trust-model">
 </li>
         </ul>
 <p id="section-1.3-5">Ideally, the trust architecture allows parties that mutually trust each other to form their own trust "union" or "domain", and to freely decide whether to trust other trust unions (domains) outside their own trust bubble.<a href="#section-1.3-5" class="pilcrow">¶</a></p>
-<p id="section-1.3-6">To fulfill the above requirements, which in fact apply well to inter-domain networking, SCION introduces the concept of <strong>Isolation Domains</strong>. An Isolation Domain (ISD) is a building block for achieving high availability, scalability, and support for heterogeneous trust. It consists of a logical grouping of ASes that share a uniform trust environment (i.e., a common jurisdiction). An ISD is administered by one or multiple ASes, called the <strong>voting ASes</strong>. Furthermore, each ISD has a set of ASes that form the ISD core; these are the <strong>core ASes</strong>. The set of core and voting ASes can, but not necessarily have to, overlap.  The set of core and voting ASes can, but not necessarily have to, overlap. It is governed by a policy called the <strong>Trust Root Configuration</strong> (TRC), which is negotiated by the ISD core. The TRC defines the locally scoped roots of trust used to validate bindings between names and public keys.<a href="#section-1.3-6" class="pilcrow">¶</a></p>
+<p id="section-1.3-6">To fulfill the above requirements, which in fact apply well to inter-domain networking, SCION introduces the concept of <strong>Isolation Domains</strong>. An Isolation Domain (ISD) is a building block for achieving high availability, scalability, and support for heterogeneous trust. It consists of a logical grouping of ASes that share a uniform trust environment (i.e., a common jurisdiction). An ISD is administered by one or multiple ASes, called the <strong>voting ASes</strong>. Furthermore, each ISD has a set of ASes that form the ISD core; these are the <strong>core ASes</strong>. The set of core and voting ASes can, but not necessarily have to, overlap. It is governed by a policy called the <strong>Trust Root Configuration</strong> (TRC), which is negotiated by the ISD core. The TRC defines the locally scoped roots of trust used to validate bindings between names and public keys.<a href="#section-1.3-6" class="pilcrow">¶</a></p>
 <p id="section-1.3-7">Authentication in SCION is based on digital certificates that bind identifiers to public keys and carry digital signatures that are verified by roots of trust. SCION allows each ISD to define its own set of trust roots, along with the policy governing their use. Such scoping of trust roots within an ISD improves security, as compromise of a private key associated with a trust root cannot be used to forge a certificate outside the ISD. An ISD's trust roots and policy are encoded in the TRC, which has a version number, a list of public keys that serves as root of trust for various purposes, and policies governing the number of signatures required for performing different types of actions. The TRC serves as a way to bootstrap all authentication within SCION. Additionally, TRC versioning is used to efficiently revoke compromised roots of trust.<a href="#section-1.3-7" class="pilcrow">¶</a></p>
 <p id="section-1.3-8">The TRC also provides <em>trust agility</em>, that is, it enables users to select the trust roots used to initiate certificate validation. This implies that users are free to choose an ISD they believe maintains a non-compromised set of trust roots. ISD members can also decide whether to trust other ISDs and thus transparently define trust relationships between parts of the network. The SCION trust model, therefore, differs from the one provided by other PKI architectures.<a href="#section-1.3-8" class="pilcrow">¶</a></p>
 </section>

draft-dekater-scion-pki.txt

@@ -5,7 +5,7 @@
 Network Working Group                                        C. de Kater
 Internet-Draft                                             N. Rustignoli
 Intended status: Informational                         SCION Association
-Expires: 15 March 2024                                 12 September 2023
+Expires: 24 March 2024                                 21 September 2023
 
 
                         SCION Control-Plane PKI
@@ -56,7 +56,7 @@ Status of This Memo
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on 15 March 2024.
+   This Internet-Draft will expire on 24 March 2024.
 
 Copyright Notice
 
@@ -274,8 +274,7 @@ Table of Contents
    one or multiple ASes, called the *voting ASes*. Furthermore, each ISD
    has a set of ASes that form the ISD core; these are the *core ASes*.
    The set of core and voting ASes can, but not necessarily have to,
-   overlap.  The set of core and voting ASes can, but not necessarily
-   have to, overlap.  It is governed by a policy called the *Trust Root
+   overlap.  It is governed by a policy called the *Trust Root
    Configuration* (TRC), which is negotiated by the ISD core.  The TRC
    defines the locally scoped roots of trust used to validate bindings
    between names and public keys.