From e8a5eceaaffc5a066c6fae99bf356659da4234e1 Mon Sep 17 00:00:00 2001 From: knmeynell Date: Wed, 29 May 2024 13:44:59 +0200 Subject: [PATCH 01/13] Added overview section --- draft-dekater-scion-pki.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/draft-dekater-scion-pki.md b/draft-dekater-scion-pki.md index 78222d3..f078f1a 100644 --- a/draft-dekater-scion-pki.md +++ b/draft-dekater-scion-pki.md @@ -177,6 +177,17 @@ The control-plane PKI (CP-PKI) lays the foundation for the authentication proced {::boilerplate bcp14-tagged} +## Overview + +SCION is a path-aware internetworking routing architecture as described in [RFC9217]. It allows endpoints and applications to select paths across the network to use for traffic, based on trustworthy path properties. SCION is an inter-domain network architecture and is not concerned with intra-domain forwarding. + +To achieve scalability and trust, SCION organizes existing Autonomous Systems (ASes) into logical groups of independent routing planes called *Isolation Domains (ISDs)*. All ASes in an ISD agree on a set of trust roots called the *Trust Root Configuration (TRC)* which is a collection of signed root certificates in X.509 v3 format [RFC5280]. The ISD is governed by a set of *core ASes* which typically manage the trust roots and provide connectivity to other ISDs. This is the basis of the public key infrastructure which the SCION control plane is reliant on for the authentication of messages used for the SCION control plane. + +The SCION control plane [I-D.dekater-scion-controlplane] is responsible for discovering inter-domain paths between ASes. The core ASes use *Path-segment Construction Beacons (PCBs)* to explore intra-ISD paths, or to explore paths across different ISDs. + +The SCION data plane forwards inter-domain packets between ASes [I-D.dekater-scion-dataplane]. SCION routers are normally deployed at the edge of an AS, and peer with neighbor SCION routers. A SCION border router reuses existing intra-domain infrastructure to communicate to other SCION routers or SCION endpoints within its AS. + + ## Trust Model Given the diverse nature of the constituents in the current Internet, an important challenge is how to scale authentication of network elements (such as AS ownership, hop-by-hop routing information, name servers for DNS, and domains for TLS) to the global environment. The roots of trust of currently prevalent public key infrastructure (PKI) models do not scale well to a global environment, because (1) mutually distrustful parties cannot agree on a single trust root (monopoly model), and because (2) the security of a plethora of roots of trust is only as strong as its weakest link (oligopoly model) - see also {{BARRERA17}}. From c9c08780b46b64a1aa7de83a7c728be1bcc5d1a7 Mon Sep 17 00:00:00 2001 From: knmeynell Date: Mon, 10 Jun 2024 15:13:43 +0100 Subject: [PATCH 02/13] Added revised Introduction --- draft-dekater-scion-pki.md | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/draft-dekater-scion-pki.md b/draft-dekater-scion-pki.md index f078f1a..6bc906e 100644 --- a/draft-dekater-scion-pki.md +++ b/draft-dekater-scion-pki.md @@ -139,10 +139,25 @@ This document first introduces the trust model behind the SCION's control-plane # Introduction -The control-plane PKI (CP-PKI) lays the foundation for the authentication procedures in SCION. It handles all cryptographic material used in the public key infrastructure of SCION's control plane. This section first introduces the key concepts of the SCION CP-PKI, including the trust model, its core elements (certificates, keys, and roles), and their relationships. The sections after the Introduction provide detailed specifications of the building blocks of the CP-PKI. +SCION is a path-aware internetworking routing architecture as described in {{RFC9217}}. It allows endpoints and applications to select paths across the network to use for traffic, based on trustworthy path properties. SCION is an inter-domain network architecture and is therefore not concerned with intra-domain forwarding. -**Note:** For extended information on the SCION next-generation inter-domain architecture, see {{CHUAT22}}, especially Chapter 2, as well as the IETF Internet Drafts {{I-D.scion-overview}} and {{I-D.scion-components}}. +SCION has been developed with the following goals: +*Availability* - to provide highly available communication that can send traffic over paths with optimal or required characteristics, quickly handle inter-domain link or router failures (both on the last hop or anywhere along the path) and provide continuity in the presence of adversaries. + +*Security* - to provide higher levels of trust in routing information in order to prevent IP prefix hijacking/leaks, denial-of-service and other attacks. Endpoints can decide the trust roots they wish to rely on, routing information can be unambiguously attributed to an AS, and packets are only forwarded along authorized path segments. A particular use case is to enable geofencing. + +*Scalability* - to improve the scalability of the inter-domain control plane and data plane, avoiding existing limitations related to convergence and forwarding table size. The advertising of path segments is separated into a beaconing process within each Isolation Domain (ISD) and between ISDs which incurs minimal overhead and resource requirements on routers. + +SCION relies on three main components: + +*PKI* - To achieve scalability and trust, SCION organizes existing ASes into logical groups of independent routing planes called *Isolation Domains (ISDs)*. All ASes in an ISD agree on a set of trust roots called the *Trust Root Configuration (TRC)* which is a collection of signed root certificates in X.509 v3 format {{RFC5280}}. The ISD is governed by a set of *core ASes* which typically manage the trust roots and provide connectivity to other ISDs. This is the basis of the public key infrastructure which the SCION control plane relies upon for the authentication of messages that is used for the SCION control plane. + +*Control Plane* - performs inter-domain routing by discovering and securely disseminating path information between ASes. The core ASes use Path-segment Construction Beacons (PCBs) to explore intra-ISD paths, or to explore paths across different ISDs. See {{I-D.dekater-scion-controlplane}} + +*Data Plane* - carries out secure packet forwarding between SCION-enabled ASes over paths selected by endpoints. A SCION border router reuses existing intra-domain infrastructure to communicate to other SCION routers or SCION endpoints within its AS. See {{I-D.dekater-scion-dataplane}} + +This document describes the SCION PKI used by the Control Plane. ## Terminology @@ -150,7 +165,7 @@ The control-plane PKI (CP-PKI) lays the foundation for the authentication proced **Autonomous System (AS)**: An autonomous system is a network under a common administrative control. For example, the network of an Internet service provider, company, or university can constitute an AS. If an organization operates multiple networks that are not directly connected together, then the different networks are considered different ASes. -**Isolation Domain (ISD)**: In SCION, autonomous systems (ASes) are organized into logical groups called isolation domains or ISDs. Each ISD consists of ASes that span an area with a uniform trust environment (i.e., a common jurisdiction). A possible model is for ISDs to be formed along national boundaries or federations of nations. +**Isolation Domain (ISD)**: In SCION, Autonomous Systems (ASes) are organized into logical groups called isolation domains or ISDs. Each ISD consists of ASes that span an area with a uniform trust environment (i.e., a common jurisdiction). A possible model is for ISDs to be formed along national boundaries or federations of nations. **Core AS**: Each isolation domain (ISD) is administered by a set of distinguished autonomous systems (ASes) called core ASes, which are responsible for initiating the path-discovery and -construction process (in SCION called "beaconing"). From 369d8dd4fbecf2a1165a95f12a849a71e6e75b88 Mon Sep 17 00:00:00 2001 From: knmeynell Date: Mon, 10 Jun 2024 15:22:37 +0100 Subject: [PATCH 03/13] Minor update to Introduction --- draft-dekater-scion-pki.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-dekater-scion-pki.md b/draft-dekater-scion-pki.md index 6bc906e..0f6dd7b 100644 --- a/draft-dekater-scion-pki.md +++ b/draft-dekater-scion-pki.md @@ -157,7 +157,7 @@ SCION relies on three main components: *Data Plane* - carries out secure packet forwarding between SCION-enabled ASes over paths selected by endpoints. A SCION border router reuses existing intra-domain infrastructure to communicate to other SCION routers or SCION endpoints within its AS. See {{I-D.dekater-scion-dataplane}} -This document describes the SCION PKI used by the Control Plane. +This document describes the SCION PKI component used by the Control Plane. ## Terminology From 5f4b313971a9a82c55ab420cdd71867ceb9c3dfe Mon Sep 17 00:00:00 2001 From: knmeynell Date: Mon, 10 Jun 2024 15:36:48 +0100 Subject: [PATCH 04/13] Removed Overview section This is now covered (and replaced by) the new Introduction section. --- draft-dekater-scion-pki.md | 11 ----------- 1 file changed, 11 deletions(-) diff --git a/draft-dekater-scion-pki.md b/draft-dekater-scion-pki.md index 0f6dd7b..c62f39b 100644 --- a/draft-dekater-scion-pki.md +++ b/draft-dekater-scion-pki.md @@ -192,17 +192,6 @@ This document describes the SCION PKI component used by the Control Plane. {::boilerplate bcp14-tagged} -## Overview - -SCION is a path-aware internetworking routing architecture as described in [RFC9217]. It allows endpoints and applications to select paths across the network to use for traffic, based on trustworthy path properties. SCION is an inter-domain network architecture and is not concerned with intra-domain forwarding. - -To achieve scalability and trust, SCION organizes existing Autonomous Systems (ASes) into logical groups of independent routing planes called *Isolation Domains (ISDs)*. All ASes in an ISD agree on a set of trust roots called the *Trust Root Configuration (TRC)* which is a collection of signed root certificates in X.509 v3 format [RFC5280]. The ISD is governed by a set of *core ASes* which typically manage the trust roots and provide connectivity to other ISDs. This is the basis of the public key infrastructure which the SCION control plane is reliant on for the authentication of messages used for the SCION control plane. - -The SCION control plane [I-D.dekater-scion-controlplane] is responsible for discovering inter-domain paths between ASes. The core ASes use *Path-segment Construction Beacons (PCBs)* to explore intra-ISD paths, or to explore paths across different ISDs. - -The SCION data plane forwards inter-domain packets between ASes [I-D.dekater-scion-dataplane]. SCION routers are normally deployed at the edge of an AS, and peer with neighbor SCION routers. A SCION border router reuses existing intra-domain infrastructure to communicate to other SCION routers or SCION endpoints within its AS. - - ## Trust Model Given the diverse nature of the constituents in the current Internet, an important challenge is how to scale authentication of network elements (such as AS ownership, hop-by-hop routing information, name servers for DNS, and domains for TLS) to the global environment. The roots of trust of currently prevalent public key infrastructure (PKI) models do not scale well to a global environment, because (1) mutually distrustful parties cannot agree on a single trust root (monopoly model), and because (2) the security of a plethora of roots of trust is only as strong as its weakest link (oligopoly model) - see also {{BARRERA17}}. From 595b0459a5aacd49a31cf3dbdcb03ce1d0baff21 Mon Sep 17 00:00:00 2001 From: knmeynell Date: Mon, 10 Jun 2024 17:33:16 +0100 Subject: [PATCH 05/13] Added and fixed references --- draft-dekater-scion-pki.md | 26 +++++++++++++++++++++----- 1 file changed, 21 insertions(+), 5 deletions(-) diff --git a/draft-dekater-scion-pki.md b/draft-dekater-scion-pki.md index c62f39b..a87eab1 100644 --- a/draft-dekater-scion-pki.md +++ b/draft-dekater-scion-pki.md @@ -40,6 +40,7 @@ normative: RFC5652: RFC5758: RFC6996: + RFC9217 informative: BARRERA17: DOI.10.1145/3085591 @@ -125,8 +126,23 @@ informative: ins: S. Hitz name: Samuel Hitz org: Anapaya Systems - - + I-D.scion-dp: + title: SCION Data Plane + date: 2023 + target: https://datatracker.ietf.org/doc/draft-dekater-scion-dataplane/ + author: + - + ins: C. de Kater + name: Corine de Kater + org: SCION Association + - + ins: N. Rustignoli + name: Nicola Rustignoli + org: SCION Association + - + ins: S. Hitz + name: Samuel Hitz + org: Anapaya Systems --- abstract @@ -153,11 +169,11 @@ SCION relies on three main components: *PKI* - To achieve scalability and trust, SCION organizes existing ASes into logical groups of independent routing planes called *Isolation Domains (ISDs)*. All ASes in an ISD agree on a set of trust roots called the *Trust Root Configuration (TRC)* which is a collection of signed root certificates in X.509 v3 format {{RFC5280}}. The ISD is governed by a set of *core ASes* which typically manage the trust roots and provide connectivity to other ISDs. This is the basis of the public key infrastructure which the SCION control plane relies upon for the authentication of messages that is used for the SCION control plane. -*Control Plane* - performs inter-domain routing by discovering and securely disseminating path information between ASes. The core ASes use Path-segment Construction Beacons (PCBs) to explore intra-ISD paths, or to explore paths across different ISDs. See {{I-D.dekater-scion-controlplane}} +*Control Plane* - performs inter-domain routing by discovering and securely disseminating path information between ASes. The core ASes use Path-segment Construction Beacons (PCBs) to explore intra-ISD paths, or to explore paths across different ISDs. See {{I-D.scion-cp}} -*Data Plane* - carries out secure packet forwarding between SCION-enabled ASes over paths selected by endpoints. A SCION border router reuses existing intra-domain infrastructure to communicate to other SCION routers or SCION endpoints within its AS. See {{I-D.dekater-scion-dataplane}} +*Data Plane* - carries out secure packet forwarding between SCION-enabled ASes over paths selected by endpoints. A SCION border router reuses existing intra-domain infrastructure to communicate to other SCION routers or SCION endpoints within its AS. See {{I-D.scion-dataplane}} -This document describes the SCION PKI component used by the Control Plane. +This document describes the SCION PKI component used by the Control Plane. ## Terminology From e539bf678c145d82a8683ff6ae513fb290cc47bb Mon Sep 17 00:00:00 2001 From: knmeynell Date: Mon, 10 Jun 2024 17:35:23 +0100 Subject: [PATCH 06/13] Fixed reference --- draft-dekater-scion-pki.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-dekater-scion-pki.md b/draft-dekater-scion-pki.md index a87eab1..b6b943b 100644 --- a/draft-dekater-scion-pki.md +++ b/draft-dekater-scion-pki.md @@ -40,7 +40,7 @@ normative: RFC5652: RFC5758: RFC6996: - RFC9217 + RFC9217: informative: BARRERA17: DOI.10.1145/3085591 From 33252fdb2fa822a7a935bd83d9ba3f7ceaa3e8d6 Mon Sep 17 00:00:00 2001 From: knmeynell Date: Mon, 10 Jun 2024 17:37:55 +0100 Subject: [PATCH 07/13] Fixed reference --- draft-dekater-scion-pki.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-dekater-scion-pki.md b/draft-dekater-scion-pki.md index b6b943b..d32ed61 100644 --- a/draft-dekater-scion-pki.md +++ b/draft-dekater-scion-pki.md @@ -126,7 +126,7 @@ informative: ins: S. Hitz name: Samuel Hitz org: Anapaya Systems - I-D.scion-dp: + I-D.scion-dataplane: title: SCION Data Plane date: 2023 target: https://datatracker.ietf.org/doc/draft-dekater-scion-dataplane/ From c20aaf841976524b7d51851664220c12cc34f1f5 Mon Sep 17 00:00:00 2001 From: knmeynell Date: Thu, 13 Jun 2024 16:56:14 +0100 Subject: [PATCH 08/13] Removed redundant references to SCION Overview & Component Drafts --- draft-dekater-scion-pki.md | 30 ------------------------------ 1 file changed, 30 deletions(-) diff --git a/draft-dekater-scion-pki.md b/draft-dekater-scion-pki.md index d32ed61..93ce8f2 100644 --- a/draft-dekater-scion-pki.md +++ b/draft-dekater-scion-pki.md @@ -79,36 +79,6 @@ informative: ins: A. Perrig name: Adrian Perrig org: ETH Zuerich - I-D.scion-overview: - title: SCION Overview - date: 2022 - target: https://datatracker.ietf.org/doc/draft-dekater-panrg-scion-overview/ - author: - - - ins: C. de Kater - name: Corine de Kater - org: ETH Zuerich - - - ins: N. Rustignoli - name: Nicola Rustignoli - org: ETH Zuerich - - - ins: A. Perrig - name: Adrian Perrig - org: ETH Zuerich - I-D.scion-components: - title: SCION Components Analysis - date: 2022 - target: https://datatracker.ietf.org/doc/draft-rustignoli-panrg-scion-components/ - author: - - - ins: N. Rustignoli - name: Nicola Rustignoli - org: ETH Zuerich - - - ins: C. de Kater - name: Corine de Kater - org: ETH Zuerich I-D.scion-cp: title: SCION Control Plane date: 2023 From 7a2748713477c30d2315be8823f6076ceee79dea Mon Sep 17 00:00:00 2001 From: Nicola Rustignoli Date: Thu, 13 Jun 2024 18:26:10 +0200 Subject: [PATCH 09/13] reword "allowed" --- draft-dekater-scion-pki.md | 18 +++++------------- 1 file changed, 5 insertions(+), 13 deletions(-) diff --git a/draft-dekater-scion-pki.md b/draft-dekater-scion-pki.md index 78222d3..2093aac 100644 --- a/draft-dekater-scion-pki.md +++ b/draft-dekater-scion-pki.md @@ -482,7 +482,6 @@ The recommended **maximum validity period** of a sensitive voting certificate is All certificates used in the SCION control-plane PKI are X.509 v3 certificates. However, the SCION specification is in some places more restrictive. This section defines these additional constraints and conditions compared to {{RFC5280}} for each type of SCION control-plane PKI certificate. -**Note**: The settings for the SCION-specific constraints and conditions are based on the SCION open-source implementation [scionproto](https://github.com/scionproto/scion/). Adjusting these settings to the requirements of a customer implementation may be possible and is allowed. ### Basic Fields: SCION-Specific Constraints and Conditions @@ -490,10 +489,7 @@ This section briefly describes the fields of the SCION control-plane PKI certifi `TBSCertificate` sequence: Contains information associated with the subject of the certificate and the CA that issued it. It includes the following fields: -- `version` field: Describes the version of the encoded certificate. - - - **SCION constraints**: "v1" and "v2" are not allowed. - - **Additional conditions and remarks**: MUST be set to "v3" (as extensions are used and mandatory in SCION). +- `version` field: Describes the version of the encoded certificate. It MUST be set to "v3" (as extensions are used and mandatory in SCION). - `serialNumber` field: A positive integer assigned by the CA to each certificate. It MUST be unique for each certificate issued by a given CA. - `signature` field: Contains the identifier for the algorithm used by the CA to sign the certificate. @@ -528,13 +524,9 @@ This section briefly describes the fields of the SCION control-plane PKI certifi - **SCION constraints**: For constraints regarding the algorithm, see the `signature` field. -- `issuerUniqueID` field: If set, it enables reusing the issuer name over time. - - - **SCION constraints**: This field is disallowed in SCION and MUST NOT be used. - -- `subjectUniqueID` field: If set, it enables reusing the subject name over time. +- `issuerUniqueID` field: it MUST NOT be used. - - **SCION constraints**: This field is disallowed in SCION and MUST NOT be used. +- `subjectUniqueID` field: it MUST NOT be used. - `extensions` sequence: Defines the extensions of the certificate. For a description of all extensions used in SCION, see [](#exts). @@ -712,7 +704,7 @@ The `basicConstraints` extension specifies whether the certificate subject may a The `basicConstraints` extension includes the following attributes relevant for SCION: - `cA` attribute: Specifies whether the certificate subject may act as a CA. If yes, this attribute MUST be set to TRUE. -- `pathLenConstraint` attribute: This attribute is only relevant if the `cA` attribute is set to TRUE. It specifies the maximum number of CA certificates that may follow this CA certificate in the certification chain. Value "0" means that this CA may only issue end-entity certificates, but no CA certificates. If the attribute is not set, there is no limit to the allowed length of the certification path. +- `pathLenConstraint` attribute: This attribute is only relevant if the `cA` attribute is set to TRUE. It specifies the maximum number of CA certificates that may follow this CA certificate in the certification chain. Value "0" means that this CA may only issue end-entity certificates, but no CA certificates. If the attribute is not set, there is no limit to the maximum length of the certification path. The settings of the `basicConstraints` extension differ for each SCION control-plane PKI certificate type. The next table shows the specifications per certificate type. @@ -935,7 +927,7 @@ The value of the `gracePeriod` field in a base TRC MUST be zero. The value of th ##### `noTrustReset` Boolean {#notrustreset} -The `noTrustReset` Boolean specifies whether a trust reset is forbidden by the ISD. Within a TRC update chain, this value CANNOT be changed by a regular or sensitive update. However, it is possible to change the `noTrustReset` value in the event of a trust reset, where a new base TRC is created. +The `noTrustReset` Boolean specifies whether a trust reset is forbidden by the ISD. Within a TRC update chain, this value MUST NOT be changed by a regular or sensitive update. However, it is possible to change the `noTrustReset` value in the event of a trust reset, where a new base TRC is created. The `noTrustReset` field is optional and defaults to FALSE. From 7cd90984b22a52bf810571177ae26d273ceb8308 Mon Sep 17 00:00:00 2001 From: knmeynell Date: Fri, 14 Jun 2024 13:18:10 +0100 Subject: [PATCH 10/13] Made Normative and Informative references consistent --- draft-dekater-scion-pki.md | 72 +++++++++++++++++++------------------- 1 file changed, 36 insertions(+), 36 deletions(-) diff --git a/draft-dekater-scion-pki.md b/draft-dekater-scion-pki.md index 93ce8f2..4b42f4a 100644 --- a/draft-dekater-scion-pki.md +++ b/draft-dekater-scion-pki.md @@ -35,14 +35,48 @@ author: normative: RFC5280: - RFC5398: RFC5480: RFC5652: RFC5758: - RFC6996: RFC9217: + I-D.scion-cp: + title: SCION Control Plane + date: 2023 + target: https://datatracker.ietf.org/doc/draft-dekater-scion-controlplane/ + author: + - + ins: C. de Kater + name: Corine de Kater + org: SCION Association + - + ins: N. Rustignoli + name: Nicola Rustignoli + org: SCION Association + - + ins: S. Hitz + name: Samuel Hitz + org: Anapaya Systems + I-D.scion-dataplane: + title: SCION Data Plane + date: 2023 + target: https://datatracker.ietf.org/doc/draft-dekater-scion-dataplane/ + author: + - + ins: C. de Kater + name: Corine de Kater + org: SCION Association + - + ins: N. Rustignoli + name: Nicola Rustignoli + org: SCION Association + - + ins: S. Hitz + name: Samuel Hitz + org: Anapaya Systems informative: + RFC5398: + RFC6996: BARRERA17: DOI.10.1145/3085591 CHUAT22: title: "The Complete Guide to SCION" @@ -79,40 +113,6 @@ informative: ins: A. Perrig name: Adrian Perrig org: ETH Zuerich - I-D.scion-cp: - title: SCION Control Plane - date: 2023 - target: https://datatracker.ietf.org/doc/draft-dekater-scion-controlplane/ - author: - - - ins: C. de Kater - name: Corine de Kater - org: SCION Association - - - ins: N. Rustignoli - name: Nicola Rustignoli - org: SCION Association - - - ins: S. Hitz - name: Samuel Hitz - org: Anapaya Systems - I-D.scion-dataplane: - title: SCION Data Plane - date: 2023 - target: https://datatracker.ietf.org/doc/draft-dekater-scion-dataplane/ - author: - - - ins: C. de Kater - name: Corine de Kater - org: SCION Association - - - ins: N. Rustignoli - name: Nicola Rustignoli - org: SCION Association - - - ins: S. Hitz - name: Samuel Hitz - org: Anapaya Systems --- abstract From 512b793e03c31153c7443a3eb0ec561bd100d5c4 Mon Sep 17 00:00:00 2001 From: knmeynell Date: Fri, 14 Jun 2024 13:28:58 +0100 Subject: [PATCH 11/13] Replaced 'allowed' with IETF requirements language --- draft-dekater-scion-pki.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/draft-dekater-scion-pki.md b/draft-dekater-scion-pki.md index 4b42f4a..c622afb 100644 --- a/draft-dekater-scion-pki.md +++ b/draft-dekater-scion-pki.md @@ -207,7 +207,7 @@ As already mentioned previously, the control-plane PKI, SCION's concept of trust ### Updates and Trust Resets {#trust-reset} -There are two types of TRC updates: regular and sensitive. A **regular TRC update** is a periodic re-issuance of the TRC where the entities and policies listed in the TRC remain unchanged, whereas a **sensitive TRC update** is an update that modifies critical aspects of the TRC, such as the set of core ASes. In both cases, the base TRC remains unchanged. If the ISD's TRC has been compromised, it is necessary for an ISD to re-establish the trust root. This is possible with a process called **trust reset** (if allowed by the ISD's trust policy). In this case, a new base TRC is created. +There are two types of TRC updates: regular and sensitive. A **regular TRC update** is a periodic re-issuance of the TRC where the entities and policies listed in the TRC remain unchanged, whereas a **sensitive TRC update** is an update that modifies critical aspects of the TRC, such as the set of core ASes. In both cases, the base TRC remains unchanged. If the ISD's TRC has been compromised, it is necessary for an ISD to re-establish the trust root. This is possible with a process called **trust reset** (if permitted by the ISD's trust policy). In this case, a new base TRC is created. ### Substitutes to Certificate Revocation {#substitutes-to-revocation} @@ -358,19 +358,19 @@ The recommended **maximum validity period** of a CP AS certificate is: 3 days. ### Voting Certificates {#cp-voting-cert} -There are two types of voting certificates: the (1) regular voting certificates and the (2) sensitive voting certificates. They contain the public keys associated with the private keys that are allowed to cast votes in the TRC update process. Voting certificates are X.509-style certificates. +There are two types of voting certificates: the (1) regular voting certificates and the (2) sensitive voting certificates. They contain the public keys associated with the private keys that MAY to cast votes in the TRC update process. Voting certificates are X.509-style certificates. Regular and sensitive voting certificates are used to verify regular and sensitive TRC updates, respectively, and are embedded in the TRC. #### Regular Voting Certificate -Regular voting certificates state which keys are allowed to cast votes in a regular update. In X.509 terms, regular voting certificates are self-signed end-entity certificates. This means that the issuer and subject of a regular voting certificate are the same entity, and the public key within the certificate can be used to verify the certificate's signature. However, a regular voting certificate cannot be used to verify other certificates. +Regular voting certificates state which keys MAY cast votes in a regular update. In X.509 terms, regular voting certificates are self-signed end-entity certificates. This means that the issuer and subject of a regular voting certificate are the same entity, and the public key within the certificate can be used to verify the certificate's signature. However, a regular voting certificate cannot be used to verify other certificates. The recommended **maximum validity period** of a regular voting certificate is: 1 year. #### Sensitive Voting Certificate -Sensitive voting certificates specify which keys are allowed to cast votes in a sensitive update. In X.509 terms, sensitive voting certificates are self-signed end-entity certificates. This means that the issuer and subject of a sensitive voting certificate are the same entity, and the public key within the certificate can be used to verify the certificate's signature. However, a sensitive voting certificate cannot be used to verify other certificates. +Sensitive voting certificates specify which keys MAY cast votes in a sensitive update. In X.509 terms, sensitive voting certificates are self-signed end-entity certificates. This means that the issuer and subject of a sensitive voting certificate are the same entity, and the public key within the certificate can be used to verify the certificate's signature. However, a sensitive voting certificate cannot be used to verify other certificates. The recommended **maximum validity period** of a sensitive voting certificate is: 5 years. @@ -483,7 +483,7 @@ The recommended **maximum validity period** of a sensitive voting certificate is All certificates used in the SCION control-plane PKI are X.509 v3 certificates. However, the SCION specification is in some places more restrictive. This section defines these additional constraints and conditions compared to {{RFC5280}} for each type of SCION control-plane PKI certificate. -**Note**: The settings for the SCION-specific constraints and conditions are based on the SCION open-source implementation [scionproto](https://github.com/scionproto/scion/). Adjusting these settings to the requirements of a customer implementation may be possible and is allowed. +**Note**: The settings for the SCION-specific constraints and conditions are based on the SCION open-source implementation [scionproto](https://github.com/scionproto/scion/). Adjusting these settings to the requirements of a customer implementation SHOULD be allowed. ### Basic Fields: SCION-Specific Constraints and Conditions @@ -493,7 +493,7 @@ This section briefly describes the fields of the SCION control-plane PKI certifi - `version` field: Describes the version of the encoded certificate. - - **SCION constraints**: "v1" and "v2" are not allowed. + - **SCION constraints**: "v1" and "v2" MUST NOT be used. - **Additional conditions and remarks**: MUST be set to "v3" (as extensions are used and mandatory in SCION). - `serialNumber` field: A positive integer assigned by the CA to each certificate. It MUST be unique for each certificate issued by a given CA. @@ -531,11 +531,11 @@ This section briefly describes the fields of the SCION control-plane PKI certifi - `issuerUniqueID` field: If set, it enables reusing the issuer name over time. - - **SCION constraints**: This field is disallowed in SCION and MUST NOT be used. + - **SCION constraints**: This field MUST NOT be used in SCION. - `subjectUniqueID` field: If set, it enables reusing the subject name over time. - - **SCION constraints**: This field is disallowed in SCION and MUST NOT be used. + - **SCION constraints**: This field MUST NOT be used in SCION. - `extensions` sequence: Defines the extensions of the certificate. For a description of all extensions used in SCION, see [](#exts). @@ -713,7 +713,7 @@ The `basicConstraints` extension specifies whether the certificate subject may a The `basicConstraints` extension includes the following attributes relevant for SCION: - `cA` attribute: Specifies whether the certificate subject may act as a CA. If yes, this attribute MUST be set to TRUE. -- `pathLenConstraint` attribute: This attribute is only relevant if the `cA` attribute is set to TRUE. It specifies the maximum number of CA certificates that may follow this CA certificate in the certification chain. Value "0" means that this CA may only issue end-entity certificates, but no CA certificates. If the attribute is not set, there is no limit to the allowed length of the certification path. +- `pathLenConstraint` attribute: This attribute is only relevant if the `cA` attribute is set to TRUE. It specifies the maximum number of CA certificates that may follow this CA certificate in the certification chain. Value "0" means that this CA may only issue end-entity certificates, but no CA certificates. If the attribute is not set, there is no limit to the permitted length of the certification path. The settings of the `basicConstraints` extension differ for each SCION control-plane PKI certificate type. The next table shows the specifications per certificate type. From c0e2e2b350549a86d210247a327beddae3a9b815 Mon Sep 17 00:00:00 2001 From: Nicola Rustignoli Date: Wed, 3 Jul 2024 20:50:44 +0200 Subject: [PATCH 12/13] remove mention of OS implementation parameters --- draft-dekater-scion-pki.md | 1 - 1 file changed, 1 deletion(-) diff --git a/draft-dekater-scion-pki.md b/draft-dekater-scion-pki.md index 912d61b..46a8c71 100644 --- a/draft-dekater-scion-pki.md +++ b/draft-dekater-scion-pki.md @@ -483,7 +483,6 @@ The recommended **maximum validity period** of a sensitive voting certificate is All certificates used in the SCION control-plane PKI are X.509 v3 certificates. However, the SCION specification is in some places more restrictive. This section defines these additional constraints and conditions compared to {{RFC5280}} for each type of SCION control-plane PKI certificate. -**Note**: The settings for the SCION-specific constraints and conditions are based on the SCION open-source implementation [scionproto](https://github.com/scionproto/scion/). Adjusting these settings to the requirements of a customer implementation may be possible and is allowed. ### Basic Fields: SCION-Specific Constraints and Conditions From 4cd0b33cb6a0417700583747b0e0825ffbb58ed1 Mon Sep 17 00:00:00 2001 From: Nicola Rustignoli Date: Wed, 3 Jul 2024 20:54:47 +0200 Subject: [PATCH 13/13] typo --- draft-dekater-scion-pki.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-dekater-scion-pki.md b/draft-dekater-scion-pki.md index 46a8c71..dd7276b 100644 --- a/draft-dekater-scion-pki.md +++ b/draft-dekater-scion-pki.md @@ -358,7 +358,7 @@ The recommended **maximum validity period** of a CP AS certificate is: 3 days. ### Voting Certificates {#cp-voting-cert} -There are two types of voting certificates: the (1) regular voting certificates and the (2) sensitive voting certificates. They contain the public keys associated with the private keys that MAY to cast votes in the TRC update process. Voting certificates are X.509-style certificates. +There are two types of voting certificates: the (1) regular voting certificates and the (2) sensitive voting certificates. They contain the public keys associated with the private keys that MAY cast votes in the TRC update process. Voting certificates are X.509-style certificates. Regular and sensitive voting certificates are used to verify regular and sensitive TRC updates, respectively, and are embedded in the TRC.