| Internet-Draft | SCION CP-PKI | September 2023 |
| de Kater & Rustignoli | Expires 24 March 2024 | [Page] |
This document presents the trust concept and design of the SCION control-plane Public Key Infrastructure (PKI), SCION's public key infrastructure model. SCION (Scalability, Control, and Isolation On Next-generation networks) is a path-aware, inter-domain network architecture. The control-plane PKI, or short CP-PKI, handles cryptographic material and lays the foundation for the authentication procedures in SCION. It is used by SCION's control plane to authenticate and verify path information, and builds the basis for SCION's special trust model based on so-called Isolation Domains.¶
This document first introduces the trust model behind the SCION's control-plane PKI, as well as clarifications to the concepts used in it. This is followed by specifications of the different types of certificates and the Trust Root Configuration. The document then specifies how to deploy the whole infrastructure.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://scionassociation.github.io/scion-cppki_I-D/draft-dekater-scion-pki.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-dekater-scion-pki/.¶
Source for this draft and an issue tracker can be found at https://github.com/scionassociation/scion-cppki_I-D.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any 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 24 March 2024.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
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.¶
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].¶
Control-Plane PKI (CP-PKI): The control-plane PKI is the public-key infrastructure upon which SCION's control plane relies for the authentication of messages. It is a set of policies, roles, and procedures that are used to manage trust root configurations (TRCs) and certificates.¶
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.¶
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").¶
Trust Root Configuration (TRC): A trust root configuration or TRC is a signed collection of certificates pertaining to an isolation domain (ISD). TRCs also contain ISD-specific policies.¶
Authoritative AS: Authoritative ASes are those ASes in an ISD that always have the latest TRCs of the ISD. As a consequence, authoritative ASes also start the announcement of a TRC update.¶
Base TRC: A base TRC is a trust root configuration (TRC) that other parties trust axiomatically. In other words, trust for a base TRC is assumed, not derived from another cryptographic object. Each ISD must create and sign a base TRC when the ISD is established. A base TRC is either the first TRC of the ISD or the result of a trust reset.¶
TRC Signing Ceremony: The ceremony during which the very first base TRC of an ISD, called the initial TRC, is signed. The initial TRC is a special case of the base TRC where the number of the ISD is assigned.¶
TRC Update: A regular TRC update is a periodic re-issuance of the TRC where the entities and policies listed in the TRC remain unchanged. 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.¶
Voting ASes: Those ASes within an ISD that may sign TRC updates. The process of appending a signature to a new TRC is called "casting a vote".¶
Voting Quorum: The voting quorum is a trust root configuration (TRC) field that indicates the number of votes (signatures) needed on a successor TRC for it to be verifiable. A voting quorum greater than one will thus prevent a single entity from creating a malicious TRC update.¶
Grace Period: The grace period is an interval during which the previous version of a trust root configuration (TRC) is still considered active after a new version has been published.¶
Trust Reset: A trust reset is the action of announcing a new base TRC for an existing ISD. A trust reset should only be triggered after a catastrophic event involving the loss or compromise of several important private keys.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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].¶
The monopoly model suffers from two main drawbacks: First, all parties must agree on a single root of trust. Secondly, the single root of trust represents a single point of failure, the misuse of which enables the forging of certificates. Also, its revocation can result in a kill-switch for all the entities it certifies. The oligopoly model relies on several roots of trust, all equally and completely trusted. However, this is not automatically better: Whereas the monopoly model has a single point of failure, the oligopoly model has the drawback of exposing more than one point of failure.¶
Thus, there is a need for a trust architecture that supports meaningful trust roots in a global environment with inherently distrustful parties. This new trust architecture should provide the following properties:¶
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.¶
To fulfill the above requirements, which in fact apply well to inter-domain networking, SCION introduces the concept of Isolation Domains. 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 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. 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.¶
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.¶
The TRC also provides trust agility, 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.¶
As already mentioned previously, the control-plane PKI, SCION's concept of trust, is organized on ISD-level. Each ISD can independently specify its own Trust Root Configuration (TRC) and build its own verification chain. Each TRC consists of a collection of signed root certificates, which are used to sign CA certificates, which are in turn used to sign AS certificates. The TRC also includes ISD-policies that specify, for example, the TRC's usage, validity, and future updates. A TRC is a fundamental component of an ISD's control-plane PKI. The so-called base TRC constitutes the ISD's trust anchor. It is signed during a signing ceremony by the voting ASes and then distributed throughout the ISD.¶
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.¶
The base TRC constitutes the root of trust within an ISD. Figure 1 provides a first impression of the trust chain within an ISD, based on its TRC. For detailed descriptions, please refer to Section 2 and Section 3.¶
TRC 2
+--------------------------------------+
|+------------------------------------+|
||- Version - Core ASes ||
+--------+ ||- ID - Description || +--------+
| TRC 1 | ||- Validity - No Trust Reset || | TRC 3 |
| (Base |---->||- Grace Period - Voting Quorum ||--->| |
| TRC) | ||- ... || | |
+--------+ |+------------------------------------+| +--------+
|+----------------+ +----------------+|
|| Regular Voting | |Sensitive Voting||
|| Certificate | | Certificate ||
|+----------------+ +----------------+|
|+----------------+ +----------------+|
|| Votes | | Signatures ||
|+----------------+ +----------------+|
|+------------------------------------+|
|| CP Root Certificates ||
|+----------+-------------+-----------+|
| | | |
+-----------+-------------+------------+
| |
| |
v v
+-----------+ +-----------+
| CP CA | | CP CA |
|Certificate| |Certificate|
+-+-------+-+ +-----+-----+
| | |
| | |
v v v
+-----------+ +-----------+ +-----------+
| CP AS | | CP AS | | CP AS |
|Certificate| |Certificate| |Certificate|
+-----------+ +-----------+ +-----------+
All certificates used in SCION's control-plane PKI are in X.509 v3 format [RFC5280]. Additionally, the TRC contains self-signed certificates instead of plain public keys. Self-signed certificates have the following advantages over plain public keys: (1) They make the binding between name and public key explicit; and (2) the binding is signed to prove possession of the corresponding private key.¶
All ASes in SCION have the task to sign and verify control-plane messages. However, certain ASes have additional roles:¶
All further details of the SCION control-plane PKI are specified in the following sections.¶
The SCION control-plane PKI can be seen as a function that transforms potential distrust among different parties into a mutually accepted trust contract including a trust update and reset policy as well as certificates used for authentication procedures in SCION's control plane.¶
For the function to work, it is not necessary that the ASes of the ISD all trust each other. However, all ASes MUST trust the ISD's core ASes, authoritative ASes, voting ASes, as well as its CA(s). These trusted parties negotiate the ISD trust contract in a "bootstrapping of trust" ceremony, where cryptographic material is exchanged, and the ISD's trust anchor (the initial Trust Root Configuration) is created and signed.¶
Prior to the ceremony, the trusted parties must decide about the validity period of the TRC as well as the number of votes required to update a TRC. They must also bring the required keys and certificates, the so-called root and voting keys/certificates.¶
During the ceremony, the trusted parties decide about the number of the ISD. This must be an integer in the inclusive range between 64 and 4094. The next table shows the current allocation of ISD numbers in SCION:¶
| ISD | Description |
|---|---|
| 0 | The wildcard ISD. |
| 1 - 15 | Reserved for documentation and sample code (analogous to [RFC5398]. |
| 16 - 63 | Private use (analogous to [RFC6996]). Can be used for testing and private deployments. |
| 64 - 4094 | Public ISDs. Should be allocated in ascending order, without gaps and "vanity" numbers. |
| 4095 - 65535 | Reserved for future use. |
The output of the bootstrapping of trust ceremony, or the trust "function", are the ISD's initial Trust Root Configuration as well as mutually trusted and accepted CA and AS certificates--the latter are used to verify SCION's control-plane messages. Together with the ISD's control-plane root certificates, the CA and AS certificates build the ISD's trust and verification chain.¶
This section provides a detailed specification of all certificates used in SCION's control-plane PKI. It starts with an overview of the main keys and certificates.¶
There are three types of control-plane (CP) certificates: root certificates, CA certificates, and AS certificates. Together, they build a chain of trust that is anchored in the trust root configuration (TRC) file of the respective Isolation Domain (ISD). Additionally, there are regular and sensitive voting certificates, which define the keys to cast votes in a regular and a sensitive TRC update, respectively.¶
All certificates in SCION's control-plane PKI are in X.509 v3 format [RFC5280].¶
The next section shows SCION's trust hierarchy. This is followed by sections that describe the main certificates and corresponding key pairs of SCION's control-plane PKI as well as the voting certificates and keys.¶
The trust is anchored in the Trust Root Configuration (TRC) for each ISD. The trust root is axiomatic: All trust derived from this anchor relies on all parties transitively trusting the TRC.¶
The trust hierarchy looks like this:¶
TRC
── Regular Voting Certificates
└── TRC (next version, regular update)
── Sensitive Voting Certificates
└── TRC (next version, sensitive update)
── CP Root Certificates
└── CP CA Certificates
└── CP AS Certificates
¶
The control-plane root private key is used to sign control-plane CA certificates. Consequently, the control-plane root certificate with the control-plane root public key is used to verify control-plane CA certificates, i.e., root certificates determine which ASes act as CA in an ISD.¶
In X.509 terms, CP root certificates are self-signed CA certificates. That is, issuer and subject of the certificate are the same entity, and the public key in the root certificate can be used to verify the root certificate's signature. The CP root public key and proof of ownership of the private key are embedded in the Trust Root Configuration (TRC) of an Isolation Domain (ISD), via the self-signed CP root certificate. This facilitates the bootstrapping of trust within an ISD, and marks the CP root certificates as the starting point of an ISD's certificate verification path.¶
The recommended maximum validity period of a CP root certificate is: 1 year.¶
Note: The TRC of each ISD contains a trusted set of control-plane root certificates. This set builds the root of each ISD's verification path. For more information on the selection of this trusted set of root certificates, see Section 3.¶
The control-plane CA private key is used to sign control-plane AS certificates. Consequently, control-plane CA certificates holding the control-plane CA public key are used to verify control-plane AS certificates.¶
The public key needed to verify the CA certificate is in a CP root certificate. CA certificates do not bundle the root certificate needed to verify them. In order to verify a CA certificate, a pool of root certificates must first be extracted from one or more active TRCs (as described in Section 4.2).¶
The recommended maximum validity period of a CP CA certificate is: 11 days.¶
SCION ASes sign control-plane messages, such as Path Construction Beacons, with their AS private key. Consequently, control-plane AS certificates holding the corresponding AS public key are required to verify control-plane messages.¶
In X.509 terms, control-plane AS certificates are end-entity certificates. That is, they cannot be used to verify other certificates.¶
The recommended maximum validity period of a CP AS certificate is: 3 days.¶
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.¶
Regular and sensitive voting certificates are used to verify regular and sensitive TRC updates, respectively, and are embedded in the TRC.¶
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.¶
The recommended maximum validity period of a regular voting certificate is: 1 year.¶
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.¶
The recommended maximum validity period of a sensitive voting certificate is: 5 years.¶
Note:¶
Both SCION's control-plane root certificates and control-plane CA certificates are in fact CA certificates. That is, they can both be used to verify other certificates.¶
One important difference between both certificate types lies in their validity period: A SCION control-plane root certificate has a recommended maximum validity period of one year, whereas the recommended maximum validity period of a SCION control-plane CA certificate is 11 days. This is because a root certificate is part of the Trust Root Configuration of an ISD, which itself also has a recommended maximum validity period of one year (see Table 2 below). This ensures that the TRC must not be updated all the time and is thus relatively stable.¶
The SCION root private key and public key/certificate are used to sign and verify the control-plane CA certificates, respectively. The control-plane CA certificates are explicitly NOT part of the TRC, for reasons of security. The control-plane CA certificates are used to verify the control-plane AS certificates, which in turn are used to verify control-plane messages. Routing is made more secure if both the SCION control-plane CA and AS certificates can be renewed on a very regular basis. Would the control-plane CA and AS certificates be part of the TRC, then the TRC would have to be updated constantly, which is undesirable.¶
Table 2 and Table 3 below provide a formal overview of the different types of key pairs and certificates in the control-plane PKI.¶
| Name | Notation (1) | Used to verify/sign |
|---|---|---|
| Sensitive voting key | Ksens | TRC updates (sensitive) |
| Regular voting key | Kreg | TRC updates (regular) |
| CP root key | Kroot | CP CA certificates |
| CP CA key | KCA | CP AS certificates |
| CP AS key | KAS | CP messages, path segments |
(1) Kx = PKx + SKx, where x = certificate type, PKx = public key, and SKx = private key¶
| Name | Notation | Signed with | Contains | Validity (2) |
|---|---|---|---|---|
| TRC (trust root conf.) | TRC | SKsens, SKreg (1) | Croot, Csens, Creg (1) | 1 year |
| Sensitive voting cert. | Csens | SKsens | PKsens | 5 years |
| Regular voting cert. | Creg | SKreg | PKreg | 1 year |
| CP root certificate | Croot | SKroot | PKroot | 1 year |
| CP CA certificate | CCA | SKroot | PKCA | 11 days (3) |
| CP AS certificate | CAS | SKCA | PKAS | 3 days |
(1) Multiple signatures and certificates of each type may be included in a TRC.
(2) Recommended maximum validity period.
(3) A validity of 11 days with 4 days overlap between two CA certificates is recommended to enable the best possible operational procedures when performing a CA certificate rollover.¶
Figure 2 illustrates, at a high level, the relationship between a TRC and the five types of certificates.¶
+--------------------+ +--------------------+ +--------------+ +---------------+
| TRC 1 +---->| TRC 2 -+------>╳ | TRC 3 +---->| TRC 4 |
| (base, initial) | | (regular update) | | (base, trust | | (sensitive |
+--+--------------------+ +--------------------+------+ | reset) | | update) |
| | +--------------+ +---------------+
| |
+--------------------------------------------+ +---+----------------------------------------+
| TRC 1 (base, initial) | | TRC 2 (regular update) |
|+------------------------------------------+| |+------------------------------------------+|
||- Version - Core ASes || ||- Version - Core ASes ||
||- ID - Description || ||- ID - Description ||
||- Validity - No Trust Reset || ||- Validity - No Trust Reset ||
||- Grace Period - Voting Quorum || ||- Grace Period - Voting Quorum ||
||- ... || ||- ... ||
|+------------------------------------------+| |+------------------------------------------+|
|+--------------------++--------------------+| |+--------------------++--------------------+|
||Votes (cert.indices)|| Regular Voting || ||Votes (cert.indices)|| Regular Voting ||
|| || Certificates || || || Certificates ||
|| (empty) || || || (1),(2)... || ||
|| ||+-----+ +-----+ || || ||+-----+ +-----+ ||
|| ||| (1) | | (2) | || || ||| (1) | | (2) | ||
|| |||C | |C | ... || || |||C | |C | ... ||
|| ||| reg | | reg | || || ||| reg | | reg | ||
|+--------------------+|+--+--+ +--+--+ || |+--------------------+|+-----+ +-----+ ||
|+--------------------+| | | || |+--------------------+| ||
|| || | +--------++-----+ || || ||
|| || +----------------++-+ | || || ||
|| Signatures |+--------------------+| | | || Signatures |+--------------------+|
|| |+--------------------+| | | || |+--------------------+|
||+------------------+|| Sensitive Voting || | | ||+------------------+|| Sensitive Voting ||
|||73 A9 4E AO 0D ...||| Certificates || | +--+>|48 AE E4 80 DB ...||| Certificates ||
||+------------------+||+-----+ +-----+ || | ||+------------------+||+-----+ +-----+ ||
||+------------------+||| (3) | | (4) | || | ||+------------------+||| (3) | | (4) | ||
|||53 B7 7C 98 56 ...||||C | |C | || +------+>|7E BC 75 98 25 ...||||C | |C | ||
||+------------------+||| sens| | sens| ... || ||+------------------+||| sens| | sens| ... ||
|| ... ||+-----+ +-----+ || || ... ||+-----+ +-----+ ||
|+--------------------++--------------------+| |+--------------------++--------------------+|
|+------------------------------------------+| |+------------------------------------------+|
|| CP Root Certificates || || CP Root Certificates ||
|| || || ||
|| +-----+ +-----+ +-----+ +-----+ || || +-----+ +-----+ +-----+ +-----+ ||
|| | (5) | | (6) | | (7) | | (8) | || || | (5) | | (6) | | (7) | | (8) | ||
|| |C | |C | |C | |C | || || |C | |C | |C | |C | ||
|| | root| | root| | root| | root| ..... || || | root| | root| | root| | root| ..... ||
|| +-----+ +--+--+ +-----+ +--+--+ || || +-----+ +--+--+ +-----+ +--+--+ ||
|+------------+---------------+-------------+| |+------------+---------------+-------------+|
+-------------+---------------+--------------+ +-------------+---------------+--------------+
| | | |
+---------v-+ +-v---------+ +---------v-+ +-v---------+
| CP CA | | CP CA | | CP CA | | CP CA |
|Certificate| |Certificate| |Certificate| |Certificate|
+-----+-----+ +-----+-----+ +-+-------+-+ +-----+-----+
| | | | |
| | | | |
v v v v v
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+
| CP AS | | CP AS | | CP AS | | CP AS | | CP AS |
|Certificate| |Certificate| |Certificate| |Certificate| |Certificate|
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+
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. Adjusting these settings to the requirements of a customer implementation may be possible and is allowed.¶
This section briefly describes the fields of the SCION control-plane PKI certificates based on X.509. These fields are relevant for each SCION certificate used in the control plane, regardless of the certificate type. For detailed descriptions of the full generic format of X.509 v3 certificates, see [RFC5280] and X509, clause 7.2. Additionally, the section lists the SCION-specific constraints and conditions compared to [RFC5280], per certificate field.¶
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.¶
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.¶
parameters field in the AlgorithmIdentifier sequence MUST NOT be used.¶
issuer field: Contains the distinguished name (DN) of the entity that has issued and signed the certificate (usually a CA).¶
SCION constraints:¶
ISD-AS number. For details, see Section 2.2.1.2 and Section 2.2.1.2.1.¶
validity field: Defines the validity period of the certificate.¶
subject field: Defines the entity that owns the certificate.¶
SCION constraints:¶
subject field is specified in the same way as the issuer field. For details, see Section 2.2.1.2 and Section 2.2.1.2.1.¶
subjectPublicKeyInfo field: Carries the public key of the certificate's subject (the entity that owns the certificate, as defined in the subject field). The subjectPublicKeyInfo field also identifies which algorithm to use with the key.¶
signature field.¶
issuerUniqueID field: If set, it enables reusing the issuer name over time.¶
subjectUniqueID field: If set, it enables reusing the subject name over time.¶
extensions sequence: Defines the extensions of the certificate. For a description of all extensions used in SCION, see Section 2.2.2.¶
signature Field - Additional Information
For security reasons, SCION uses a custom list of acceptable signature algorithms. This list of acceptable signature algorithms is specified in the signature field. The list currently only contains the ECDSA signature algorithm (defined in X962). However, the list might be extended in the future. The Object Identifiers (OIDs) for ECDSA are defined as ecdsa-with-SHA256, ecdsa-with-SHA384, and ecdsa-with-SHA512 in [RFC5758].¶
Important: The accepted cryptographic algorithms listed in this document are the only currently accepted cryptographic algorithms. SCION implementations MUST reject cryptographic algorithms not found in the list.¶
The only accepted curves for ECDSA are:¶
secp256r1 in [RFC5480])¶
secp384r1 in [RFC5480])¶
secp521r1 in [RFC5480])¶
The OIDs for the above curves are specified in section 2.1.1.1 of [RFC5480].¶
The appropriate hash size to use when producing a signature with an ECDSA key is:¶
Important: SCION implementations MUST include support for P-256, P-384, and P-521.¶
issuer Field - Additional Information
The issuer field contains the distinguished name (DN) of the CA that created the certificate. [RFC5280], section 4.1.2.4, describes the field's syntax and attributes. In addition to these attributes, SCION implementations MUST also support the SCION-specific attribute ISD-AS number. This attribute is specified below.¶
ISD-AS number Attribute
The ISD-AS number attribute identifies the SCION ISD and AS. In the SCION open source implementation, the attribute type is id-at-ia, defined as:
id-at-ia AttributeType ::= {id-scion id-cppki(1) id-at(2) 1}¶
where id-scion specifies the root SCION object identifier (OID).¶
Note: The root SCION object identifier (OID) for the SCION open-source implementation is the IANA Private Enterprise Number '55324':
id-scion ::= OBJECT IDENTIFIER {1 3 6 1 4 1 55324}¶
The following points apply when setting the attribute value of the ISD-AS number attribute:¶
1:0:0 to ffff:ffff:ffff.¶
Example: AS ff00:0:110 in ISD 1 is formatted as 1-ff00:0:110.¶
The ISD-AS number attribute MUST be present exactly once in the distinguished name of the certificate issuer or owner, specified in the issuer or subject field, respectively. Implementations MUST NOT create nor successfully verify certificates whose issuer and subject fields do not include the ISD-AS number at all, or include it more than once.¶
Note: Voting certificates are not required to include the ISD-AS number attribute in their distinguished name.¶
[RFC5280], section 4.2.1, defines the syntax of the Extensions sequence in a X.509 certificate. Descriptions of each standard certificate extension can be found in [RFC5280], section 4.2.1. The corresponding clauses in X509 (10/2016) are clause 7.2 and clause 9, respectively.¶
Currently, the following extensions are relevant for SCION:¶
The following sections describe the SCION-specifics in regard to these extensions.¶
subjectKeyIdentifier Extension
The subjectKeyIdentifier extension identifies certificates that contain a particular public key. It can be used, for example, by control-plane messages to identify which certificate to use for verification. The extension allows for overlapping control-plane CA keys, for example during updates.¶
For the syntax and definition of the subjectKeyIdentifier extension, see [RFC5280], section 4.2.1.2, and X509, clause 9.2.2.2.¶
This extension MUST always be non-critical. However, SCION implementations MUST error out if the extension is not present.¶
keyUsage Extension
The keyUsage extension identifies the intended usage of the public key in the corresponding certificate. For the syntax and definition of the keyUsage extension, see [RFC5280], section 4.2.1.3, and X509, clause 9.2.2.3.¶
The attributes of the keyUsage extension define possible ways of using the public key. The attributes have the following meaning in SCION:¶
digitalSignature: The public key can be used to verify the digital signature of a control-plane payload.¶
contentCommitment: Not used.¶
keyEncipherment: Not used.¶
dataEncipherment: Not used.¶
keyAgreement: Not used.¶
keyCertSign: The public key can be used to verify the CA signature on a control-plane certificate.¶
cRLSign: Not used.¶
encipherOnly: Not used.¶
decipherOnly: Not used.¶
Important: If a certificate’s public key is used to verify the signature of a control-plane payload (digitalSignature attribute), it must be possible to trace back the private key used to sign the certificate. This is done by referencing the ISD-AS and the subject key identifier (via the subjectKeyIdentifier extension). For more information about the subjectKeyIdentifier extension, see Section 2.2.2.2.¶
If present, the keyUsage extension should be marked as "critical". That is, the critical Boolean attribute of this extension must be set to TRUE (the default is FALSE).¶
Note: If a certificate extension is marked "critical", the public key in the certificate should only be used for the purpose set in the critical extension.¶
Each control-plane PKI certificate type uses the public key differently, and consequently also specifies the attributes of the keyUsage extension differently. The next table shows the specifications per certificate type.¶
| Certificate Type | Root | CA | AS | Voting (regular and sensitive) |
|---|---|---|---|---|
| Attribute: | ||||
keyUsage extension itself |
MUST be present | MUST be present | MUST be present | MAY be present (but is not required) |
digitalSignature
|
MUST NOT be set (1) | MUST NOT be set (2) | MUST be set | If the extension is present, the digitalSignature attribute MUST NOT be set |
keyCertSign
|
MUST be set | MUST be set | MUST NOT be set | If the extension is present, the keyCertSign attribute MUST NOT be set |
(1) The root certificate should not be used to verify control-plane messages.
(2) The CA certificate should not be used to verify control-plane messages.¶
extKeyUsage Extension
The extKeyUsage extension specifies additional usages of the public key in the certificate. For the syntax and definition of the extKeyUsage extension, see X509, clause 9.2.2.4.¶
SCION uses the following attributes of the Extended Key Usage extension, as defined in Section 4.2.1.12 of [RFC5280]:¶
id-kp-serverAuth: If set, the public key can be used for SCION control-plane server authentication.¶
id-kp-clientAuth: If set, the public key can be used for SCION control-plane client authentication.¶
id-kp-timeStamping: If set, the public key can be used for the verification of timestamps.¶
Additionally, the Extended Key Usage extension sequence may include the SCION-specific attributes id-kp-root, id-kp-regular, and id-kp-sensitive. These attributes are used in the Trust Root Configuration setup, to distinguish root certificates, regular voting certificates, and sensitive voting certificates from each other. For more information, see Section 3.1.2.2.11.¶
The specifications of the extKeyUsage extension differ per SCION control-plane PKI certificate type. The next table provides an overview of the specifications per certificate type.¶
| Certificate Type | Root | CA | AS | Voting (regular and sensitive) |
|---|---|---|---|---|
| Attribute: | ||||
extKeyUsage extension itself |
MUST be present | MAY be present (not required) | MUST be present | MUST be present |
id-kp-serverAuth
|
MUST NOT be included | MUST NOT be included | MUST be included, if the certificate is used on the server-side of a control-plane TLS session. | MUST NOT be included |
id-kp-clientAuth
|
MUST NOT be included | MUST NOT be included | MUST be included, if the certificate is used on the client-side of a control-plane TLS session. | MUST NOT be included |
id-kp-timeStamping
|
MUST be included | MUST be included | MUST be included | |
| SCION-specific |
id-kp-root MUST be included. For details, see Section 2.2.2.4.1
|
Regular voting cert: id-kp-regular MUST be included. For details, see Section 2.2.2.4.1Sensitive voting cert: id-kp-sensitive MUST be included. For details, see Section 2.2.2.4.1
|
The id-kp-root, id-kp-regular, and id-kp-sensitive attributes must be specified as follows:¶
id-kp-root AttributeType ::= {id-scion id-cppki(1) id-kp(3) 3}¶
id-kp-regular AttributeType ::= {id-scion id-cppki(1) id-kp(3) 2}¶
id-kp-sensitive AttributeType ::= {id-scion id-cppki(1) id-kp(3) 1}¶
where id-scion specifies the root SCION object identifier (OID).¶
Note: The root SCION object identifier (OID) for the SCION open-source implementation is the IANA Private Enterprise Number '55324':
id-scion ::= OBJECT IDENTIFIER {1 3 6 1 4 1 55324}¶
basicConstraints Extension
The basicConstraints extension specifies whether the certificate subject may act as a CA. For the syntax and definition of the basicConstraints extension, see X509, clause 9.4.2.1.¶
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.¶
The settings of the basicConstraints extension differ for each SCION control-plane PKI certificate type. The next table shows the specifications per certificate type.¶
| Certificate Type | Root | CA | AS | Voting (regular and sensitive) |
|---|---|---|---|---|
| Attribute: | ||||
basicConstraints extension itself |
MUST be present | MUST be present | SHOULD NOT be present | SHOULD NOT be present |
cA
|
MUST be set to TRUE | MUST be set to TRUE | If the extension is present, this attribute MUST be set to FALSE | If the extension is present, this attribute MUST be set to FALSE |
pathLenConstraint
|
SHOULD be set to "1", MUST be marked as "critical" | SHOULD be set to "0" (1), MUST be marked as "critical" | If the extension is present, this attribute MUST be absent. | If the extension is present, this attribute MUST be absent. |
(1) Control-plane CAs can only issue end-entity certificates.¶
This section provides an in-depth specification of the trust root configuration (TRC) file (see Section 3.1). The TRC contains policy information about an ISD and acts as a distribution mechanism for the trust anchors of that ISD. It enables securing the control-plane interactions, and is thus an integral part of the SCION infrastructure.¶
The initial TRC of an ISD is signed during a signing ceremony and then distributed throughout the ISD. This signing ceremony follows specific rules; Section 3.2 describes these rules.¶
The trust root configuration (TRC) is a signed collection of X.509 v3 certificates. Additionally, the TRC contains ISD-specific policies encoded in a Cryptographic Message Syntax (CMS) [RFC5652] envelope.¶
The TRC's certificates collection consists of a set of control-plane root certificates, which build the root of the certification chain for the AS certificates in an ISD. The other certificates in the TRC are solely used for signing the next TRC, a process called "voting". The verification of a new TRC thus depends on the policies and voting certificates defined in the previous TRC.¶
Note: See Section 2 for the general specifications of SCION's control-plane PKI certificates, as well as Section 2.1.2 and Section 2.1.5, for the specifications of the control-plane root certificates and voting certificates, respectively.¶
This section provides a detailed specification of the TRC. It presents the TRC format definitions and describes the TRC payload fields. The section uses the ITU-T X.680 syntax.¶
The following types of TRCs exist:¶
A TRC can have the following states:¶
validity field (see Section 3.1.2.2.3). A TRC is considered valid if the current time falls within its validity period.¶
gracePeriod field of the new TRC, see Section 3.1.2.2.4). No more than two TRCs can be active at the same time for any ISD.¶
Figure 3 shows the content of both a base/initial TRC and the first regularly-updated TRC based on the base TRC. All elements of the shown TRCs are specified in detail in the following subsections.¶
+--------------------------------------------+ +--------------------------------------------+ | TRC 1 (base, initial) | | TRC 2 (regular update) | |+------------------------------------------+| |+------------------------------------------+| ||- Version - Core ASes || ||- Version - Core ASes || ||- ID - Description || ||- ID - Description || ||- Validity - No Trust Reset || ||- Validity - No Trust Reset || ||- Grace Period - Voting Quorum || ||- Grace Period - Voting Quorum || ||- ... || ||- ... || |+------------------------------------------+| |+------------------------------------------+| |+--------------------++--------------------+| |+--------------------++--------------------+| ||Votes (cert.indices)|| Regular Voting || ||Votes (cert.indices)|| Regular Voting || || || Certificates || || || Certificates || || (empty) || || || (1),(2)... || || || ||+-----+ +-----+ || || ||+-----+ +-----+ || || ||| (1) | | (2) | || || ||| (1) | | (2) | || || |||C | |C | ... || || |||C | |C | ... || || ||| reg | | reg | || || ||| reg | | reg | || |+--------------------+|+--+--+ +--+--+ || |+--------------------+|+-----+ +-----+ || |+--------------------+| | | || |+--------------------+| || || || | +--------++-----+ || || || || || +----------------++-+ | || || || || Signatures |+--------------------+| | | || Signatures |+--------------------+| || |+--------------------+| | | || |+--------------------+| ||+------------------+|| Sensitive Voting || | | ||+------------------+|| Sensitive Voting || |||73 A9 4E AO 0D ...||| Certificates || | +--+>|48 AE E4 80 DB ...||| Certificates || ||+------------------+||+-----+ +-----+ || | ||+------------------+||+-----+ +-----+ || ||+------------------+||| (3) | | (4) | || | ||+------------------+||| (3) | | (4) | || |||53 B7 7C 98 56 ...||||C | |C | || +------+>|7E BC 75 98 25 ...||||C | |C | || ||+------------------+||| sens| | sens| ... || ||+------------------+||| sens| | sens| ... || || ... ||+-----+ +-----+ || || ... ||+-----+ +-----+ || |+--------------------++--------------------+| |+--------------------++--------------------+| |+------------------------------------------+| |+------------------------------------------+| || CP Root Certificates || || CP Root Certificates || || || || || || +-----+ +-----+ +-----+ +-----+ || || +-----+ +-----+ +-----+ +-----+ || || | (5) | | (6) | | (7) | | (8) | || || | (5) | | (6) | | (7) | | (8) | || || |C | |C | |C | |C | || || |C | |C | |C | |C | || || | root| | root| | root| | root| ..... || || | root| | root| | root| | root| ..... || || +-----+ +-----+ +-----+ +-----+ || || +-----+ +-----+ +-----+ +-----+ || |+------------------------------------------+| |+------------------------------------------+| +--------------------------------------------+ +--------------------------------------------+
The trust root configuration (TRC) of an ISD defines the roots of trust of the ISD, and builds the base of the ISD's control-plane PKI. It holds the root and voting certificates of the ISD and defines the ISD's trust policy.¶
The following code block shows the format of a TRC specification file (the payload schema):¶
TRCPayload ::= SEQUENCE {
version TRCFormatVersion,
iD TRCID,
validity Validity,
gracePeriod INTEGER,
noTrustReset BOOLEAN DEFAULT FALSE,
votes SEQUENCE OF INTEGER (SIZE (1..255)),
votingQuorum INTEGER (1..255),
coreASes SEQUENCE OF ASN,
authoritativeASes SEQUENCE OF ASN,
description UTF8String (SIZE (0..1024)),
certificates SEQUENCE OF Certificate }
TRCFormatVersion ::= INTEGER { v1(0) }
TRCID ::= SEQUENCE {
iSD ISD,
serialNumber INTEGER (1..MAX),
baseNumber INTEGER (1..MAX) }
ISD ::= INTEGER (1..65535)
Validity ::= SEQUENCE {
notBefore Time,
notAfter Time }
ASN ::= INTEGER (1..281474976710655)
¶
The TRCPayload sequence contains the identifying information of a TRC as well as policy information for TRC updates. Furthermore, it defines the list of certificates that build the trust anchor of the ISD.¶
For signature calculation, the data that is to be signed is encoded using ASN.1 distinguished encoding rules (DER) X.690. For more details, see Section 3.1.3.¶
This section describes the syntax and semantics of all TRC payload fields.¶
version Field
The version field describes the version of the TRC format specification.¶
Currently, the version MUST always be "v1".¶
iD Field
The iD field specifies the unique identifier of the TRC.¶
The identifier is a unique sequence of¶
iSD attribute),¶
baseNumber attribute), and¶
serialNumber attribute).¶
All numbers MUST be positive integers.¶
A TRC where the base number is equal to the serial number is a base TRC. The initial TRC is a special case of a base TRC. An ISD's initial TRC MUST have a serial number of 1 and a base number of 1. With every TRC update, the serial number MUST be incremented by one. This facilitates uniquely identifying the predecessor and successor TRC in a TRC update chain.¶
If a trust reset is necessary, a new base TRC is announced, in order to start a new and clean TRC update chain. The base number of this new TRC update chain SHOULD be the number following the serial number of the latest TRC that was produced by a non-compromised TRC update for this ISD.¶
Example
The following simple example illustrates how to specify the ID of the TRCs in an TRC update chain for ISD 74. The IDs are given in a human-readable notation, where Bxx is the base number, and Sxx the serial number.¶
| Update | TRC ID | Remarks |
|---|---|---|
| Initial | ISD74-B01-S01 | |
| Regular | ISD74-B01-S02 | Only the serial number is incremented. |
| Regular | ISD74-B01-S03 | Only the serial number is incremented. |
| Sensitive | ISD74-B01-S04 | Only the serial number is incremented. |
| Trust reset | ISD74-B05-S05 | A trust reset includes the creation of a new base TRC. The new base number follows the serial number "04" of the latest TRC resulting from a non-compromised TRC update for this ISD. |
| Regular | ISD74-B05-S06 | Only the serial number is incremented. |
| Regular | ISD74-B05-S07 | Only the serial number is incremented. |
| And so on |
validity Field
The validity field defines the validity period of the TRC. This is the period of time during which the TRC is in the "valid" state. The notBefore and notAfter attributes of the validity field specify the lower and upper bound of the time interval during which a TRC can be active.¶
Note: An active TRC is a valid TRC that can be used for verifying certificate signatures. The time period during which a TRC is active can be shorter than the time period during which the TRC is valid. For more information, see Section 3.1.1.¶
The validity field consists of a sequence of two dates, as defined in section 7.2. of X.509.¶
In addition to this standard definition, the following constraint applies to the validity field of the TRC used in SCION:¶
gracePeriod Field
The gracePeriod field of a TRC specifies the period of time during which the predecessor TRC can still be considered active (the "grace period"). The grace period starts at the beginning of the validity period of the new TRC.¶
The validity period of the predecessor TRC ends when¶
Note: The event that happens first marks the end of the predecessor's validity period.¶
The gracePeriod field defines the grace period as a number of seconds (positive integer).¶
The value of the gracePeriod field in a base TRC MUST be zero. The value of the gracePeriod field in a non-base TRC SHOULD be non-zero. It should be long enough to provide sufficient overlap between the TRCs in order to facilitate interruption-free operations in the ISD. If the grace period is too short, some control-plane AS certificates might expire before the corresponding AS can fetch an updated version from its CA.¶
noTrustReset Boolean
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 field is optional and defaults to FALSE.¶
Important: Note that once the noTrustReset Boolean is set to TRUE and a trust reset is disallowed, this cannot be reversed. Therefore, ISDs SHOULD always set this value to FALSE, unless they have sufficiently assessed the risks and implications of making a trust reset impossible.¶
Note: A trust reset represents a special use case where a new base TRC is created. It therefore differs from a TRC update (regular or sensitive), as the signatures in the new base TRC cannot be verified with the certificates contained in the predecessor TRC. Instead, a trust reset base TRC must be axiomatically trusted, similarly to how the initial TRC is trusted.¶
votes Field
The votes field contains a sequence of indices that refer to the voting certificates in the predecessor TRC. If index i is part of the votes field, then the voting certificate at position i in the certificates sequence of the predecessor TRC casted a vote on the successor TRC. For more information on the certificates sequence, see Section 3.1.2.2.11.¶
Note: In a base TRC, the votes sequence is empty.¶
Every entry in the votes sequence MUST be unique.
Further restrictions on votes are discussed in Section 3.1.5.¶
Note: The votes sequence of indices is mandatory in order to prevent stripping voting signatures from the TRC. Absence of the votes sequence makes it possible to transform a TRC with more voting signatures than the voting quorum into multiple verifiable TRCs with the same payload, but different voting signature sets. This would violate the requirement of uniqueness of a TRC.¶
votingQuorum Field
The votingQuorum field defines the number of necessary votes on a successor TRC to make it verifiable.¶
A voting quorum greater than one will prevent a single entity from creating a malicious TRC update.¶
coreASes Field
The coreASes field contains the AS numbers of the core ASes in this ISD.¶
Each core AS number MUST be unique in the sequence of core AS numbers. That is, each AS number must appear only once in the coreASes field.¶
coreASes field.¶
coreASes field.¶
Important: Revoking or assigning the core status of/to an AS always requires a (sensitive) TRC update.¶
authoritativeASes Field
The authoritativeASes field contains the AS numbers of the authoritative ASes in this ISD.¶
Authoritative ASes are those ASes in an ISD that always have the latest TRCs of the ISD. As a consequence, authoritative ASes also start the announcement of a TRC update.¶
description Field
The description field contains a UTF-8 encoded string that describes the ISD.¶
certificates Field
The voting ASes and the certification authorities (CAs) of an ISD are not specified explicitly in the ISD's TRC. Instead, this information is defined by the list of voting and root certificates in the certificates field of the TRC payload.¶
The certificates field is a sequence of self-signed X.509 certificates. Each certificate in the certificate sequence must be one of the following types:¶
A certificate that is no control-plane root or voting certificate MUST NOT be included in the sequence of certificates in the certificates field.¶
Note: A certificate's type (voting or root) is specified in the extKeyUsage extension of the certificate, by means of the SCION-specific attributes id-kp-regular, id-kp-sensitive, and id-kp-root, respectively. For more information, see Section 2.2.2.4.¶
The following constraints MUST hold for each certificate in the certificates field of the TRC payload:¶
certificates field.¶
issuer / serialNumber pair for each certificate MUST be unique.¶
iD field (see Section 3.1.2.2.2).¶
notBefore date of this TRC's validity period MUST be equal to or later than the certificate's notBefore date, and the notAfter date of this TRC's validity period MUST be before or equal to the certificate's notAfter date.¶
The following must hold for the entire sequence of certificates in the certificates field:¶
votingQuorum <= count (sensitive voting certificates) votingQuorum field (Section 3.1.2.2.7) must be smaller than or equal to the number of sensitive voting certificates specified in the TRC's certificates field.¶
votingQuorum <= count (regular voting certificates) votingQuorum field (Section 3.1.2.2.7) must be smaller than or equal to the number of regular voting certificates specified in the TRC's certificates field.¶
A TRC contains policy information about an ISD and acts as a distribution mechanism for the trust anchors of that ISD. Each TRC (payload) is digitally signed. The syntax used to sign and encapsulate the TRC payload is the Cryptographic Message Syntax (CMS), as defined in [RFC5652]. The signed TRC payload is of the CMS signed-data content type, as defined in Section 5 of [RFC5652], and encapsulated in a CMS ContentInfo element, as defined in Section 3 of [RFC5652]. For detailed information on the general syntax definitions of the Cryptographic Message Syntax, see sections 3 and 5 of [RFC5652].¶
SCION implementations have to fulfil the following additional rules, on top of the general syntax rules from [RFC5652]:¶
EncapsulatedContentInfo sequence:¶
SignedData sequence:¶
certificates field MUST be left empty. The certificate pool used to verify a TRC update is already specified in the certificates field of the predecessor TRC's payload (see also Section 3.1.2.2.11).¶
version field MUST be set to "1". This is because SCION uses the "id-data" content type to encapsulate content info, and does not specify any certificate in the SignedData sequence (see also Section 5.1 of [RFC5652]).¶
SignerIdentifier choice:¶
IssuerAndSerialNumber.¶
SignerInfo sequence:¶
version field MUST be set to "1". This is because SCION uses the IssuerAndSerialNumber type of signer identifier (see also Section 5.3 of [RFC5652]).¶
signatureAlgorithm field MUST be one of the algorithms supported by SCION (for details, see signature Field - Additional Information (Section 2.2.1.1)).¶
digestAlgorithm is determined by the algorithm specified in the signatureAlgorithm field.¶
The signer information in the signed TRC is part of an unordered set, per [RFC5652]. This implies that the signer information can be reordered without affecting verification. Certain operations, however, require TRCs to be equal, according to the following equality definition:¶
Two TRCs are equal, if and only if their payloads are byte equal.¶
Two TRCs with byte equal payloads can be considered as equal, because the TRC payload exactly defines which signatures must be attached in the signed TRC:¶
votes field of the payload: If index "i" is part of the votes field, then the voting certificate at position i in the certificates sequence of the predecessor TRC casted a vote on the successor TRC. See also Section 3.1.2.2.6.¶
The certification path of a control-plane AS certificate starts in a control-plane root certificate. The control-plane root certificates for a given ISD are distributed via the TRC. However, AS certificates and the corresponding signing CA certificates are not part of the TRC, but bundled into certificate chains and distributed separately from the corresponding TRC. This separation makes it possible to extend the validity period of the root certificate, and to update the corresponding TRC, without having to modify the certificate chain. To be able to validate a certification path, each AS must build a collection of root certificates from the latest TRC of the relevant ISD. The following section explains how to build a trust anchor pool.¶
Note: Any entity sending information that is secured by the CP-PKI, such as control-plane messages, MUST be able to provide all the necessary trust material, such as certificates, to verify said information. If any cryptographic material is missing in the process, the relying party MUST query the originator of the message for the missing material. If it cannot be resolved, the verification process fails. For more details, see 4.2 "Signing and Verifying Control-Plane Messages" Section 4.2.¶
The selection of the right set of TRCs to build the trust anchor pool depends on the time of verification. The trust anchor pool is usually used to verify control-plane messages. In this case, the time of verification is the current time. However, if the trust anchor pool will be used for auditing, the time of verification is the point in time for which you want to check whether a given signature was verifiable.¶
The selection algorithm for building the trust anchor pool is described in pseudo-python code below.¶
def select_trust_anchors(trcs: Dict[(int,int), TRC], verification_time: int) -> Set[RootCert]:
"""
Args:
trcs: The dictionary mapping (serial number, base number) to the TRC for a given ISD.
verification_time: The time of verification.
Returns:
The set of CP Root certificates that act as trust anchors.
"""
# Find highest base number that has a TRC with a validity period
# starting before verification time.
base_nr = 1
for trc in trcs.values():
if trc.id.base_nr > base_nr and trc.validity.not_before <= verification_time:
base_nr = trc.id.base_nr
# Find TRC with highest serial number with the given base number and a
# validity period starting before verification time.
serial_nr = 1
for trc in trcs[isd].values():
if trc.id.base_nr != base_nr:
continue
if trc.id.serial_nr > serial_nr and trc.validity.not_before <= verification_time:
serial_nr = trc.id.serial_nr
candidate = trcs[(serial_nr, base_nr)]
# If the verification time is not inside the validity period,
# there is no valid set of trust anchors.
if not candidate.validity.contains(verification_time):
return set()
# If the grace period has passed, only the certificates in that TRCs
# may be used as trust anchors.
if candidate.validity.not_before + candidate.grace_period < verification_time:
return collect_trust_anchors(candidate)
predecessor = trcs.get((serial_nr-1, base_nr))
if not predecessor or predecessor.validity.not_after < verification_time:
return collect_trust_anchors(candidate)
return collect_trust_anchors(candidate) | collect_trust_anchors(predecessor)
def collect_trust_anchors(trc: TRC) -> Set[RootCert]:
"""
Args:
trc: A TRC from which the CP Root Certificates shall be extracted.
Returns:
The set of CP Root certificates that act as trust anchors.
"""
roots = set()
for cert in trc.certificates:
if not cert.basic_constraints.ca:
continue
roots.add(cert)
return roots
¶
All non-base TRCs of an ISD are updates of the ISD's base TRC(s). The TRC update chain consists of regular and sensitive TRC updates. The type of update determines the (payload) information that changes in the updated TRC. This section describes the rules that apply to updating a TRC in regard to the payload information contained in the TRC. Some rules are valid for both update types, some only apply to a regular or a sensitive TRC update, respectively. Based on the type of update, a different set of voters is necessary to create a verifiable TRC update - the section includes a description of the corresponding voting (signing) process. To verify a TRC update, a relying party must perform a couple of checks. These checks are listed at the end of the section.¶
In the context of a TRC update,¶
certificates sequence in the predecessor TRC, but no longer part of the certificates sequence in the updated TRC. Instead, the certificates sequence of the updated TRC holds another certificate of the same type and with the same distinguished name.¶
certificates sequence of the predecessor TRC.¶
Note: Every new sensitive or regular voting certificate in a TRC attaches a signature to the TRC. This is done to ensure that the freshly included voting entity agrees with the contents of the TRC it is now part of.¶
The following table gives an overview of the types of TRC update as well as the rules that must apply in regard to the updated TRC's payload information.
The sections that follow provide more detailed descriptions of each rule.¶
| Type of Update | Payload Updated TRC - Unchanged Elements | Payload Updated TRC - Required Changes | Payload Updated TRC: Other Rules to Hold |
|---|---|---|---|
| Both Regular AND Sensitive Updates | - iD field: iSD and baseNumber - noTrustReset field |
iD field: serialNumber MUST be incremented by 1 |
votes field: Number of votes (indices) => number set in the votingQuorum field of the predecessor TRC |
| Regular TRC Update | - Quorum in the votingQuorum field- Core ASes in the coreASes field- ASes in the authoritativeASes field- Nr. and distinguished names of root & voting certificates in the certificates field- Set of sensitive voting certificates in the certificates field |
votes field:- All votes must only refer to regular voting certificates in the predecessor TRC - Must include votes of each changed regular voting certificate from the predecessor TRC signatures field:- Must include signatures of each changed root certificate from the predecessor TRC |
|
| Sensitive TRC Update | If the update does not qualify as a regular update, it is a sensitive update |
votes field: - All votes must only refer to sensitive voting certificates in the predecessor TRC |
The following rules MUST hold for each updated TRC, independent of the update type:¶
iSD and baseNumber in the iD field MUST NOT change (see also Section 3.1.2.2.2).¶
serialNumber in the iD field MUST be incremented by one.¶
noTrustReset field MUST NOT change (see also Section 3.1.2.2.5).¶
votes sequence of the updated TRC MUST only contain indices that refer to sensitive or regular voting certificates in the predecessor TRC. This guarantees that the updated TRC only contains valid votes authenticated by sensitive or regular voting certificates in the predecessor TRC. For more information, see Section 3.1.2.2.6 and Section 3.1.2.2.11.¶
votingQuorum field of the predecessor TRC (see Section 3.1.2.2.7). The number of votes corresponds to the number of indices in the votes field of the updated TRC.¶
A regular TRC update is a periodic re-issuance of the TRC where the entities and policies listed in the TRC remain unchanged.¶
A TRC update qualifies as a regular update, if the following rules apply in regard to the TRC's payload information.¶
The settings of the following fields in the updated TRC MUST remain the same compared to the predecessor TRC:¶
votingQuorum field.¶
coreASes field.¶
authoritativeASes field.¶
certificates field, and their distinguished names.¶
certificates field.¶
votes field of the updated TRC MUST refer to the changed regular voting certificate in the predecessor TRC.¶
votes field of the regularly updated TRC MUST refer to a regular voting certificate in the certificates field of the predecessor TRC.¶
If a TRC update does not qualify as a regular update, it is considered a sensitive update.¶
votes field of the sensitively updated TRC MUST refer to a sensitive voting certificate in the certificates field of the predecessor TRC.¶
As described above, a set of voters must cast votes on the updated TRC to make it verifiable. The votingQuorum field of the predecessor TRC (see Section 3.1.2.2.7) defines the required number of voters, which will represent regular or sensitive voting certificates, respectively. Furthermore, if one or more new certificates are added to the updated TRC, the corresponding voting representatives must also sign the updated TRC, in order to show that they have access to the private keys listed in these fresh certificates. This is called "showing proof-of-possession", and done by signing the TRC with the respective private key. For the distinction between changed and new certificates in a TRC update, see Section 3.1.5.1.¶
It is up to the ISD members to decide how the "casting a vote" procedure for updated TRCs will take place. Some ISDs will make a distinction between regular and sensitive updates. These ISDs divide the regular and sensitive signing keys in different security classes and act accordingly. For example, they keep the regular key in an online vault while the sensitive key would be stored offline in cold storage. This way, the regular TRC update would lend itself to being automated (since the keys are accessible online) whereas the sensitive one would require manual actions to access the offline key. Other ISDs, however, keep both regular and sensitive keys online and perform both updates automatically.¶
To verify a TRC update, the relying party must perform the following checks:¶
Check whether the update is regular or sensitive.¶
If one or more of the above checks gives a negative result, the updated TRC should be rejected.¶
The very first base TRC of an ISD, called the initial TRC, is a special case of the base TRC where the number of the ISD is chosen. The initial TRC must be signed during a special signing ceremony--all voting representatives of the initial TRC need to take part in this signing ceremony to sign the agreed-upon TRC. As part of the ceremony, the public keys of all voters are exchanged. The TRC is then distributed throughout the ISD. All entities within an ISD can initially obtain an authentic TRC, by means of a secure off- or online mechanism.¶
Appendix "Appendix A. Signing Ceremony Initial TRC" describes a possible procedure for the signing ceremony of an ISD's initial TRC. It is in principle up to the initial members of an ISD how to shape the signing ceremony. However, it is recommended having a process in line with the ceremony described in the Appendix.¶
This section provides several specifications regarding the deployment of the control-plane PKI.¶
Base TRCs are trust anchors and thus axiomatically trusted. All ASes within an ISD must be pre-loaded with the currently valid base-version TRC of their own ISD. For all specifications regarding the creation and distribution of initial/base TRCs, see Section 3.2.¶
All non-base TRCs of an ISD are updates of the ISD's base TRC(s). The TRC update chain consists of regular and sensitive TRC updates. The specifications and rules that apply to updating a TRC are described in Section 3.1.5.¶
Relying parties MUST have at least one valid TRC available. Relying parties MUST discover TRC updates within the grace period defined in the updated TRC. They SHOULD discover TRC updates in a matter of minutes to hours. Additionally, the following requirement must be satisfied:¶
Requirement
Any entity sending information that is secured by the CP-PKI MUST be able to provide all the necessary trust material to verify said information.¶
SCION provides the following mechanisms for discovering TRC updates and fulfilling the above requirement:¶
SCION requires that control-plane messages are signed. The main purpose of the SCION control-plane PKI is providing a mechanism to distribute and authenticate public keys that are used to verify control-plane messages and information. For example, each hop information in a path segment is signed by the respective AS. Consequently, all relying parties must be able to verify signatures with the help of the CP-PKI.¶
The following sections specify the requirements that apply to the signing and verification of control-plane messages.¶
An AS signs control-plane messages with the private key that corresponds to the (valid) AS' certificate.¶
The AS MUST attach the following information as signature metadata. It is the minimum information a relying party requires to identify which certificate to use to verify the signed message.¶
Additionally, the signer SHOULD include the following information:¶
When the relying party receives a control-plane message they want to verify, the relying party first needs to identify the certificate needed to validate the corresponding signature on the message.¶
AS certificates are bundled together with the corresponding signing CA certificate into certificate chains. For efficiency, SCION distributes these certificate chains separately from the signed messages. A certificate chain is verified against the CP root certificate. However, the root certificate is not bundled in the chain, but with the TRC. This makes it possible to extend the validity period of the root certificate, and to update the corresponding TRC, without having to modify the certificate chain.¶
To verify a control-plane message, the relying party must perform the following steps:¶
After constructing the pool of root certificates, the relying party must select the certificate chain used to verify the message. The AS certificate included in this certificate chain MUST have the following properties:¶
After selecting a certificate chain to verify the control-plane messages, the relying party must verify the certificate chain, by:¶
Checking that¶
If any cryptographic material is missing in the process, the relying party must query the originator of the message for the missing material. If it cannot be resolved, the verification process fails.¶
Important: An implication of the above procedure is that path segments should be verifiable at time of use. It is not enough to rely on path segments being verified on insert, since TRC updates that change the root key can invalidate a certificate chain.¶
The steps required to create a new AS certificate are the following:¶
The entire document is about security considerations. More details will follow in future versions of this draft.¶
Future iterations of this draft will comprise more detailed IANA considerations.¶
Many thanks go to Samuel Hitz (Anapaya), Fritz Steinmann (SIX Group AG), Juan A. Garcia Prado (ETH Zurich) and Russ Housley (IETF) for reviewing this document. We are also very grateful to Adrian Perrig (ETH Zurich), for providing guidance and feedback about each aspect of SCION. Finally, we are indebted to the SCION development teams of Anapaya and ETH Zurich, for their practical knowledge and for the documentation about the CP PKI, as well as to the authors of [CHUAT22] - the book is an important source of input and inspiration for this draft.¶
The following sections describe a possible signing ceremony for the first (initial) base TRC of an ISD. Although each ISD is free to decide how to shape this signing ceremony, it is recommended establishing a procedure similar to the one below.¶
A signing ceremony includes participants from member organizations of the respective Isolation Domain. The participants of the signing ceremony fulfill different roles:¶
Note: It is assumed that the member organizations of the ISD have decided in advance, before the signing ceremony, on the roles of the ceremony participants. That is, they have reached agreement about the Certificate Authority (CA) ASes (that will also issue the root certificates), the voting ASes, the representatives of the voting ASes, the ceremony administrator and the witnesses.¶
Note: For the signing ceremony, it is assumed that all parties are trustworthy. Issues encountered during the ceremony are assumed to be caused by honest mistakes, and not by malicious intent. Hash comparison checks are included to counter mistakes, such that every participant is sure that they operate on the same data. Furthermore, the private keys of each participant never leave their machine. The ceremony administrator does not have to be entrusted with private keys.¶
Prior to the ceremony, participants decide on the physical location of the ceremony, the devices that will be used during the ceremony and the policy of the ISD. Specifically, the voting entities agree on the following parameters:¶
When these values are agreed upon, a number of voters, equal to or larger than the specified voting quorum, needs to execute the signing ceremony. For the base TRC, all voting entities need to be present with both their sensitive and regular voting keys. The ceremony process is structured in multiple rounds of data sharing. The ceremony administrator leads the interaction and gives instructions to each participant.¶
The location must provide electricity and enough power sockets for each participant. Furthermore, it should provide a monitor (or projector) that allows the ceremony administrator to screencast.¶
Each party brings their own device that is provisioned with the required material, as described below.¶
Important: It is very important that all devices, especially the data exchange device, are not compromised. Therefore, the ceremony should ideally include a procedure to verify that the devices are secure.¶
Each party involved in a TRC signing ceremony must go through a few steps in preparation for the ceremony. This section outlines these steps.¶
In the preparation phase of the TRC Signing Ceremony, the ceremony administrator has the following tasks:¶
The preparatory task of the representatives of the voting ASes (short: the voters) is to generate the necessary certificates.¶
Important: Before generating the certificates, all voters need to agree on a preliminary TRC policy, in particular on the validity period of the TRC. This is necessary because all the certificates that are generated in advance must cover the full TRC validity period. The other policy values could be amended during the ceremony itself.¶
Each representative of a voting AS must create the following keys and certificates:¶
The ceremony process for the initial base TRC is structured in multiple rounds of data sharing. The ceremony administrator leads the interaction and instructs each participant with what to do.¶
The ceremony process contains the following phases:¶
A detailed description of each phase follows below.¶
In Phase 1 of the signing ceremony, all parties share the certificates that must be part of the TRC with the ceremony administrator. For the representatives of the voting ASes, these are the sensitive and the regular voting certificates. For the representatives of the CA ASes, these are the CP root certificates. If a CA AS does not attend the signing ceremony in person, it must ensure that the corresponding root certificate is available at the ceremony to be shared.¶
The actual sharing happens over the data exchange device, which goes from one voting representative to the next. Each representative copies the requested certificates from their own machine onto the data exchange device, before forwarding the device to the next voter. The last representative returns the device to the ceremony administrator.¶
Important: Note that only the certificates must be shared during this step, not the private keys. Copying a private key by mistake invalidates the security of the ceremony.¶
For each provided certificate, the ceremony administrator checks that its validity period covers the previously agreed-upon TRC validity, that the signature algorithms are correct, and that the certificate is of the valid type (root, sensitive voting or regular voting certificate). If the results of these checks are as expected, the ceremony administrator computes the SHA256 sum for each certificate.¶
The ceremony administrator then aggregates and bundles the provided certificates, and calculates the hash value (SHA-512 digest) over the entire bundle. Additionally, the ceremony administrator displays all hash values on the monitor.¶
The ceremony administrator now shares the bundle with the representatives of the voting and CA ASes. This could happen again via the data exchange device, which goes from one representative to the next. Each representative verifies that the certificates they contributed have the same hash value as the displayed value on the monitor. Furthermore, all representatives must confirm that the hash value of the bundled certificates on their machine is equal to the value on the monitor.¶
Phase 1 is concluded when every representative has confirmed that the SHA256 sums are correct.¶
Note: If there is a mismatch in any of the SHA256 sums, Phase 1 needs to be repeated.¶
In Phase 2 of the ceremony, the ceremony administrator generates the TRC payload based on the bundled certificates and the agreed-upon ISD policy. The result is displayed on the monitor along with a hash value (SHA-512 digest).¶
To be able to generate the payload, the ceremony administrator must ask the voting representatives for¶
iD is part of the TRC payload. For more information, see Section 3.1.2.2.2.¶
Note: It is assumed that the voting ASes have agreed on the answers to the above questions in advance, before the signing ceremony.¶
The ceremony administrator can now specify the TRC payload variables in the payload template file, and show the filled-in template on the monitor. When the voters have verified the data, the ceremony administrator can compute the DER encoding of the TRC data as well as the SHA256 sum of the TRC payload file. The ceremony administrator then distributes the TRC payload (via the data exchange device) to all voting representatives, who verify the payload's hash value. The voters do this by computing the hash value of the TRC payload on their machine and checking whether their value matches the one on the monitor.¶
Phase 2 successfully concludes once every voting representative confirms that the contents of the TRC payload are correct.¶
In Phase 3, each voting representative attaches a signature created with each one of their private voting keys to the TRC (payload file). They do this on their own machine. The purpose of signing a TRC that contains newly introduced public keys with the corresponding private keys is to prove the possession of the private keys.¶
Phase 3 concludes after all voting representatives have cast their votes.¶
In Phase 4, all voting representatives share the signed TRC with the ceremony administrator. This happens again over the data exchange device, which goes from one voter to the next. Each voting representative copies the TRC payload signed with the voter's private keys from their own machine onto the data exchange device. The last voter returns the device to the ceremony administrator, who assembles the final TRC by aggregating the payload data with the votes (signatures) cast by the voting representatives.¶
The signed TRC is validated by inspecting its contents on the monitor and verifying the signatures based on the exchanged certificates in Phase 1. The ceremony administrator then shares the signed TRC with all participants. Each of them must then inspect it once more, and verify it based on the certificates exchanged in Phase 1. At this point, the ceremony is completed. All participants have the signed TRC, and can use it to distribute the trust anchors for their ISD.¶