Script updating gh-pages from 6cb1402. [ci skip]

cdk-security-considerations/draft-dekater-scion-pki.html

@@ -3460,7 +3460,7 @@ <h3 id="name-dependency-on-certificates">
           <h4 id="name-compromise-of-an-isd">
 <a href="#section-5.1.1" class="section-number selfRef">5.1.1. </a><a href="#name-compromise-of-an-isd" class="section-name selfRef">Compromise of an ISD</a>
           </h4>
-<p id="section-5.1.1-1">Compared to DNSSEC and BGPsec, in SCION there is no central authority that could "switch off" an ISD, as each ISD relies on its own independent cryptographic trust roots. Each AS within an ISD is therefore dependant on its ISD's PKI for its functioning. This section discusses potential compromises of the PKI at various levels of the hierarchy.<a href="#section-5.1.1-1" class="pilcrow">¶</a></p>
+<p id="section-5.1.1-1">Compared to DNSSEC and RPKI, in SCION there is no central authority that could "switch off" an ISD, as each ISD relies on its own independent cryptographic trust roots. Each AS within an ISD is therefore dependant on its ISD's PKI for its functioning. This section discusses potential compromises of the PKI at various levels of the hierarchy.<a href="#section-5.1.1-1" class="pilcrow">¶</a></p>
 <ul class="normal">
 <li class="normal" id="section-5.1.1-2.1">
               <p id="section-5.1.1-2.1.1">On TRC level: The private root keys of the root certificates contained in an TRC are used to sign CA certificates. If one of these private root keys is compromised, the adversary could issue illegitimate CA certificates which may be used in further attacks. To maliciously  perform a TRC update, an attacker would need to compromise multiple voting keys. This number depends on the voting quorum set in the TRC: the higher the quorum, the more unlikely a malicious update will be.<a href="#section-5.1.1-2.1.1" class="pilcrow">¶</a></p>
@@ -3491,8 +3491,6 @@ <h4 id="name-recovery-from-compromise">
               <p id="section-5.1.2-2.3.1">On AS level: In the event of a key compromise of a (non-core) AS, the impacted AS needs to obtain a new certificate from its CA. This process will vary depending on internal issuance protocols.<a href="#section-5.1.2-2.3.1" class="pilcrow">¶</a></p>
 </li>
           </ul>
-<p id="section-5.1.2-3">If a core AS has not been compromised, but is instead acting maliciously (e.g., by not issuing or renewing certificates for certain ASes), one way to recover is for downstream ASes to self-organize and form a new ISD. By now operating autonomously, the new ISD can begin path discovery and traffic forwarding. SCION, unlike BGP, has no notion of routing convergence and instead the flooding of PCBs disseminates topology information. This means that in the worst case if all paths have to be re-created, fresh paths are established after a single flood has reached all ASes.<a href="#section-5.1.2-3" class="pilcrow">¶</a></p>
-<p id="section-5.1.2-4"><strong>Note</strong> that in the above case, it may not be clear whether the core AS acting as described is actually behaving maliciously. It is the job of the core AS to enforce an ISD's policy. If a non-core AS within an ISD does not agree with ostensibly legal behavior of the core ASes, it is up to the non-core AS to stay within the ISD. Alternatively, the non-core AS could move to another ISD that suits its needs better.<a href="#section-5.1.2-4" class="pilcrow">¶</a></p>
 </section>
 </div>
 </section>

cdk-security-considerations/draft-dekater-scion-pki.txt

@@ -2421,7 +2421,7 @@ Table of Contents
 
 5.1.1.  Compromise of an ISD
 
-   Compared to DNSSEC and BGPsec, in SCION there is no central authority
+   Compared to DNSSEC and RPKI, in SCION there is no central authority
    that could "switch off" an ISD, as each ISD relies on its own
    independent cryptographic trust roots.  Each AS within an ISD is
    therefore dependant on its ISD's PKI for its functioning.  This
@@ -2474,24 +2474,6 @@ Table of Contents
       the impacted AS needs to obtain a new certificate from its CA.
       This process will vary depending on internal issuance protocols.
 
-   If a core AS has not been compromised, but is instead acting
-   maliciously (e.g., by not issuing or renewing certificates for
-   certain ASes), one way to recover is for downstream ASes to self-
-   organize and form a new ISD.  By now operating autonomously, the new
-   ISD can begin path discovery and traffic forwarding.  SCION, unlike
-   BGP, has no notion of routing convergence and instead the flooding of
-   PCBs disseminates topology information.  This means that in the worst
-   case if all paths have to be re-created, fresh paths are established
-   after a single flood has reached all ASes.
-
-   *Note* that in the above case, it may not be clear whether the core
-   AS acting as described is actually behaving maliciously.  It is the
-   job of the core AS to enforce an ISD's policy.  If a non-core AS
-   within an ISD does not agree with ostensibly legal behavior of the
-   core ASes, it is up to the non-core AS to stay within the ISD.
-   Alternatively, the non-core AS could move to another ISD that suits
-   its needs better.
-
 5.2.  Denial of Service Attacks
 
    As described previously, the SCION's control-plane PKI lays the