SCION Control Plane PKI
draft-dekater-scion-pki-12
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Corine de Kater , Nicola Rustignoli , Samuel Hitz | ||
| Last updated | 2026-04-20 | ||
| RFC stream | Independent Submission | ||
| Intended RFC status | Informational | ||
| Formats | |||
| IETF conflict review | conflict-review-dekater-scion-pki | ||
| Additional resources |
Related Implementations
Related Implementations |
||
| Stream | ISE state | In ISE Review | |
| Consensus boilerplate | Unknown | ||
| Document shepherd | (None) | ||
| Shepherd write-up | Show Last changed 2025-11-14 | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) | ||
| IANA | IANA review state | Version Changed - Review Needed |
draft-dekater-scion-pki-12
Network Working Group C. de Kater
Internet-Draft N. Rustignoli
Intended status: Informational SCION Association
Expires: 22 October 2026 S. Hitz
Anapaya Systems
20 April 2026
SCION Control Plane PKI
draft-dekater-scion-pki-12
Abstract
This document presents the trust concept and design of the SCION
_Control Plane Public Key Infrastructure (CP-PKI)_. SCION
(Scalability, Control, and Isolation On Next-generation networks) is
a path-aware, inter-domain network architecture that relies on the
CP-PKI to handle cryptographic material, authenticate control plane
messages used to securely disseminate path information.
This specification introduces its localized trust model, anchored in
Isolation Domains (ISDs). It defines the distinct certificate types,
and specifies the structure, format and lifecycle of the Trust Root
Configuration (TRC). Furthermore, it provides practical guidelines
for deploying and maintaining the CP-PKI infrastructure.
This document contains new approaches to secure path aware
networking. It is not an Internet Standard, has not received any
formal review of the IETF, nor was the work developed through the
rough consensus process. The approaches offered in this work are
offered to the community for its consideration in the further
evolution of the Internet.
About This Document
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.
de Kater, et al. Expires 22 October 2026 [Page 1]
Internet-Draft SCION CP-PKI April 2026
Status of This Memo
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 22 October 2026.
Copyright Notice
Copyright (c) 2026 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Conventions and Definitions . . . . . . . . . . . . . . . 6
1.3. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 7
1.4. Trust Relations within an Isolation Domain . . . . . . . 9
1.4.1. Updates and Trust Resets . . . . . . . . . . . . . . 9
1.4.2. Substitutes to Certificate Revocation . . . . . . . . 9
1.5. Overview of Certificates, Keys, and Roles . . . . . . . . 10
1.6. Trust as a Function . . . . . . . . . . . . . . . . . . . 12
1.6.1. Input . . . . . . . . . . . . . . . . . . . . . . . . 13
1.6.2. Output . . . . . . . . . . . . . . . . . . . . . . . 13
2. Certificate Specification . . . . . . . . . . . . . . . . . . 13
2.1. Trust Hierarchy . . . . . . . . . . . . . . . . . . . . . 13
2.2. Control Plane Root Certificate . . . . . . . . . . . . . 14
2.3. Control Plane Issuing CA Certificate . . . . . . . . . . 14
2.4. Control Plane AS Certificate . . . . . . . . . . . . . . 15
2.5. Voting Certificates . . . . . . . . . . . . . . . . . . . 15
2.5.1. Regular Voting Certificate . . . . . . . . . . . . . 15
de Kater, et al. Expires 22 October 2026 [Page 2]
Internet-Draft SCION CP-PKI April 2026
2.5.2. Sensitive Voting Certificate . . . . . . . . . . . . 16
2.6. Key Pairs Overview and Notations . . . . . . . . . . . . 16
2.7. X.509 Certificate Profiles and Constraints . . . . . . . 19
2.7.1. version . . . . . . . . . . . . . . . . . . . . . . . 19
2.7.2. serialNumber . . . . . . . . . . . . . . . . . . . . 19
2.7.3. signature . . . . . . . . . . . . . . . . . . . . . . 19
2.7.4. issuer . . . . . . . . . . . . . . . . . . . . . . . 20
2.7.5. validity . . . . . . . . . . . . . . . . . . . . . . 21
2.7.6. subject . . . . . . . . . . . . . . . . . . . . . . . 21
2.7.7. subjectPublicKeyInfo . . . . . . . . . . . . . . . . 21
2.7.8. issuerUniqueID . . . . . . . . . . . . . . . . . . . 21
2.7.9. subjectUniqueID . . . . . . . . . . . . . . . . . . . 21
2.8. Extensions . . . . . . . . . . . . . . . . . . . . . . . 21
2.8.1. authorityKeyIdentifier Extension . . . . . . . . . . 22
2.8.2. subjectKeyIdentifier Extension . . . . . . . . . . . 22
2.8.3. keyUsage Extension . . . . . . . . . . . . . . . . . 23
2.8.4. extKeyUsage Extension . . . . . . . . . . . . . . . . 24
2.8.5. basicConstraints Extension . . . . . . . . . . . . . 27
3. Trust Root Configuration Specification . . . . . . . . . . . 28
3.1. TRC Types and States . . . . . . . . . . . . . . . . . . 29
3.2. TRC Fields . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.1. version . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.2. iD . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.3. validity . . . . . . . . . . . . . . . . . . . . . . 31
3.2.4. gracePeriod . . . . . . . . . . . . . . . . . . . . . 32
3.2.5. noTrustReset . . . . . . . . . . . . . . . . . . . . 32
3.2.6. votes . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2.7. votingQuorum . . . . . . . . . . . . . . . . . . . . 33
3.2.8. coreASes . . . . . . . . . . . . . . . . . . . . . . 33
3.2.9. authoritativeASes . . . . . . . . . . . . . . . . . . 33
3.2.10. description . . . . . . . . . . . . . . . . . . . . . 34
3.2.11. certificates . . . . . . . . . . . . . . . . . . . . 34
3.3. TRC Signature Syntax . . . . . . . . . . . . . . . . . . 35
3.3.1. SCION-specific rules . . . . . . . . . . . . . . . . 35
3.3.2. TRC Equality . . . . . . . . . . . . . . . . . . . . 36
3.4. Certification Path - Trust Anchor Pool . . . . . . . . . 37
3.4.1. TRC Selection For Trust Anchor Pool . . . . . . . . . 38
3.5. TRC Updates . . . . . . . . . . . . . . . . . . . . . . . 39
3.5.1. Changed or New Certificates . . . . . . . . . . . . . 40
3.5.2. Update Rules - Overview . . . . . . . . . . . . . . . 40
3.5.3. General Update Rules . . . . . . . . . . . . . . . . 42
3.5.4. Regular TRC Update . . . . . . . . . . . . . . . . . 42
3.5.5. Sensitive TRC Update . . . . . . . . . . . . . . . . 43
3.5.6. Signing a TRC Update . . . . . . . . . . . . . . . . 43
3.5.7. TRC Update Verification . . . . . . . . . . . . . . . 44
3.6. Initial TRC Signing Ceremony . . . . . . . . . . . . . . 44
4. CP-PKI Operations . . . . . . . . . . . . . . . . . . . . . . 45
4.1. Distribution of TRCs . . . . . . . . . . . . . . . . . . 45
de Kater, et al. Expires 22 October 2026 [Page 3]
Internet-Draft SCION CP-PKI April 2026
4.1.1. Base TRC . . . . . . . . . . . . . . . . . . . . . . 45
4.1.2. TRC Update Discovery . . . . . . . . . . . . . . . . 45
4.2. Signing and Verifying Control Plane Messages . . . . . . 46
4.2.1. Signing a Control Plane Message . . . . . . . . . . . 46
4.2.2. Verifying a Control Plane Message . . . . . . . . . . 47
4.3. Issuing Control Plane AS Certificates . . . . . . . . . . 48
5. Deployment Considerations . . . . . . . . . . . . . . . . . . 49
5.1. PKI Availability . . . . . . . . . . . . . . . . . . . . 49
5.2. Operational Processes for ISD Governance . . . . . . . . 49
6. Security Considerations . . . . . . . . . . . . . . . . . . . 50
6.1. Compromise of an ISD . . . . . . . . . . . . . . . . . . 50
6.1.1. Recovery from Compromise . . . . . . . . . . . . . . 51
6.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 51
6.3. TRC Distribution and Trust on First Use . . . . . . . . . 52
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
8.1. Normative References . . . . . . . . . . . . . . . . . . 52
8.2. Informative References . . . . . . . . . . . . . . . . . 54
Appendix A. Certificate Extensions in ASN.1 Syntax . . . . . . . 54
Appendix B. TRC in ASN.1 Syntax . . . . . . . . . . . . . . . . 55
Appendix C. Signing Ceremony Initial TRC . . . . . . . . . . . . 56
C.1. Ceremony Participants . . . . . . . . . . . . . . . . . 56
C.2. Ceremony Preparations . . . . . . . . . . . . . . . . . . 57
C.3. Ceremony Phases . . . . . . . . . . . . . . . . . . . . 58
C.3.1. Certificate Exchange . . . . . . . . . . . . . . . . 59
C.3.2. Generation of the TRC Payload . . . . . . . . . . . . 59
C.3.3. TRC Signing . . . . . . . . . . . . . . . . . . . . . 60
C.3.4. TRC Validation . . . . . . . . . . . . . . . . . . . 60
Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
draft-dekater-scion-pki-12 . . . . . . . . . . . . . . . . . . 60
draft-dekater-scion-pki-11 . . . . . . . . . . . . . . . . . . 61
draft-dekater-scion-pki-10 . . . . . . . . . . . . . . . . . . 61
draft-dekater-scion-pki-09 . . . . . . . . . . . . . . . . . . 62
draft-dekater-scion-pki-08 . . . . . . . . . . . . . . . . . . 62
draft-dekater-scion-pki-07 . . . . . . . . . . . . . . . . . . 62
draft-dekater-scion-pki-06 . . . . . . . . . . . . . . . . . . 62
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 63
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63
1. Introduction
SCION is a path-aware internetworking routing architecture as
described in [RFC9217]. A more detailed introduction, motivation,
and problem statement are provided in
[I-D.dekater-scion-controlplane]. Readers are encouraged to read the
introduction in that document first.
SCION relies on three main components:
de Kater, et al. Expires 22 October 2026 [Page 4]
Internet-Draft SCION CP-PKI April 2026
_PKI_ - providing cryptographic material within an unique trust
model. It is described in this document.
_Control Plane_ - performing inter-domain routing by discovering and
securely disseminating path information. It is described in
[I-D.dekater-scion-controlplane].
_Data Plane_ - carrying out secure packet forwarding between SCION-
enabled ASes over paths selected by endpoints. It is described in
[I-D.dekater-scion-dataplane].
1.1. Terminology
*Control Plane PKI (CP-PKI)*: It 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.
*SCION Autonomous System (AS)*: A SCION Autonomous System is a
network under a common administrative control. For example, the
network of a SCION service provider, company, or university can
constitute an AS. While functionally similar to a BGP AS, a SCION AS
operates within an Isolation Domain (ISD), utilizes a different
address scheme, and serves as a locator in the addressing of end
hosts. References to ASes throughout this document refer to SCION
ASes.
*Isolation Domain (ISD)*: SCION 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 (e.g. a common
jurisdiction).
*Core AS*: Each Isolation Domain (ISD) is administered by a set of
distinguished SCION autonomous systems (ASes) called core ASes, which
are responsible for initiating the path discovery and path
construction process (called "beaconing" in SCION). Each ISD MUST
have at least one Core AS.
*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.
de Kater, et al. Expires 22 October 2026 [Page 5]
Internet-Draft SCION CP-PKI April 2026
*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, to mitigate a compromised TRC.
1.2. Conventions and Definitions
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.
de Kater, et al. Expires 22 October 2026 [Page 6]
Internet-Draft SCION CP-PKI April 2026
1.3. 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].
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. Its revocation can also
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:
* Trust agility (see further below);
* Resilience to single root of trust compromise;
* Multi-party governance; and
* Support for policy versioning and updates.
Ideally, the trust architecture allows parties that mutually trust
each other to form their own trust domain, and to freely decide
whether to trust other trust domains.
de Kater, et al. Expires 22 October 2026 [Page 7]
Internet-Draft SCION CP-PKI April 2026
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 to support
heterogeneous trust while achieving high availability and scalability
in its control plane ([I-D.dekater-scion-controlplane]). It consists
of a logical grouping of SCION ASes that share a uniform trust
environment (i.e. a common jurisdiction).
An ISD is governed by one or multiple ASes, known as the *voting
ASes*. Furthermore, each ISD has a set of ASes that form the ISD
core, known as the *core ASes*. The set of core and voting ASes may
be, but do not necessarily have to be the same ASes. Governance is
implemented by a policy called the *Trust Root Configuration* (TRC),
which is negotiated by the voting ASes, and which defines the locally
scoped roots of trust used to validate bindings between names and
public keys.
Authentication in SCION is based on X.509 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 a voting
quorum governing the number of signatures required to update TRCs.
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_ - enabling 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
uncompromised 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.
The need for trust agility also means that SCION does not by design
provide IP prefix origin validation as provided by RPKI [RFC8210].
RPKI's trust model is currently reliant on the trust roots provided
by the five Regional Internet Registries, and therefore outside of
the governance of an ISD.
de Kater, et al. Expires 22 October 2026 [Page 8]
Internet-Draft SCION CP-PKI April 2026
1.4. Trust Relations within an Isolation Domain
The Control Plane PKI is organized at an ISD level whereby 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 issuing 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. The so-called *base TRC*
constitutes the ISD's trust anchor which is signed during a signing
ceremony by the voting ASes and then distributed throughout the ISD.
1.4.1. Updates and Trust Resets
There are two types of TRC updates: regular and sensitive (see
Section 3.5). 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.
1.4.2. Substitutes to Certificate Revocation
The Control Plane PKI does not explicitly support certificate
revocation. Instead it relies on the two mechanisms described above
and on short-lived certificates. This approach constitutes an
attractive alternative to a revocation system for the following
reasons:
* Both short-lived certificates and revocation lists must be signed
by a CA. Instead of periodically signing a new revocation list,
the CA can re-issue all the non-revoked certificates. Although
the overhead of signing multiple certificates is greater than that
of signing a single revocation list, the overall complexity of the
system is reduced. In the Control Plane PKI the number of
certificates that each CA must renew is manageable as it is
limited to at most the number of ASes within an ISD. The absence
of CRL/OCSP checks improves performance by removing additional
network lookups during PKI processing.
* Even with a revocation system, a compromised key cannot be
instantaneously revoked. Through their validity period, both
short-lived certificates and revocation lists implicitly define an
de Kater, et al. Expires 22 October 2026 [Page 9]
Internet-Draft SCION CP-PKI April 2026
attack window (i.e. a period during which an attacker who managed
to compromise a key could use it before it becomes invalid). In
both cases, the CA must consider a tradeoff between efficiency and
security when picking this validity period.
1.5. Overview of Certificates, Keys, and Roles
The base TRC constitutes the root of trust within an ISD. Figure 1
provides a view of the trust chain within an ISD, based on its TRC.
For detailed descriptions, please refer to Section 2 and Section 3.
de Kater, et al. Expires 22 October 2026 [Page 10]
Internet-Draft SCION CP-PKI April 2026
+----------------------------------------+
| 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 Issuing CA| |CP Issuing CA|
| Certificate | | Certificate |
+---+-------+-+ +------+------+
| | |
| | |
v v v
+-----------+ +-----------+ +-----------+
| CP AS | | CP AS | | CP AS |
|Certificate| |Certificate| |Certificate|
+-----------+ +-----------+ +-----------+
Figure 1: Chain of trust within an ISD
de Kater, et al. Expires 22 October 2026 [Page 11]
Internet-Draft SCION CP-PKI April 2026
All certificates used in the Control Plane PKI are in X.509 v3 format
[RFC5280] and 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. The
public keys of Voting AS certificates must therefore be explicitly
verified during the Signing Ceremony (Appendix C).
SCION ASes sign and verify control plane messages. Certain ASes have
additional roles:
* *Core ASes*: They are a distinct set of ASes in the SCION Control
Plane. For each ISD, the core ASes are listed in the TRC and each
core AS has links to the other core ASes (in the same or in
different ISDs).
* *Certification authorities (CAs)*: CAs are responsible for issuing
AS certificates to other ASes and/or themselves.
* *Voting ASes*: They may sign TRC updates. The process of
appending a signature to a new TRC is called "casting a vote", and
the designated ASes that hold the private keys to sign a TRC
update are "voting ASes".
* *Authoritative ASes*: They always have the latest TRCs of the ISD.
They start the announcement of a TRC update.
1.6. Trust as a Function
The Control Plane PKI can be seen as a function that transforms
potential distrust among different parties into a mutually accepted
trust contract. This includes a trust update and reset policy as
well as certificates used for authentication procedures in SCION's
Control Plane.
For this to work, it is not necessary that all the ASes of the ISD
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.
de Kater, et al. Expires 22 October 2026 [Page 12]
Internet-Draft SCION CP-PKI April 2026
1.6.1. Input
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.
The trusted parties require an ISD number whose numbering scheme is
described in [I-D.dekater-scion-controlplane] section ISD Numbers,
and allocation in [ISD-AS-assignments].
1.6.2. Output
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
being used to verify control plane messages. Together with the ISD's
control plane root certificates, the issuing CA and AS certificates
build the ISD's trust and verification chain.
2. Certificate Specification
There are three types of Control Plane (CP) certificates: root
certificates, issuing 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 or
sensitive TRC update.
All certificates in the Control Plane PKI are in X.509 v3 format
[RFC5280].
2.1. Trust Hierarchy
The trust is anchored in the 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:
de Kater, et al. Expires 22 October 2026 [Page 13]
Internet-Draft SCION CP-PKI April 2026
TRC
── Regular Voting Certificates
└── TRC (next version, regular update)
── Sensitive Voting Certificates
└── TRC (next version, sensitive update)
── CP Root Certificates
└── CP Issuing CA Certificates
└── CP AS Certificates
2.2. Control Plane Root Certificate
The private key of the Control Plane root certificate is used to sign
Control Plane issuing CA certificates. Consequently, the public key
of the Control Plane Root certificate is used to verify Control Plane
issuing CA certificates, i.e. root certificates determine which ASes
act as a CA in an ISD.
In X.509 terms, Control Plane root certificates are CA certificates.
For simplicity, this document calls them 'root certificates',
distinguishing them from the subordinate 'issuing CA certificates'.
Root certificates are self-signed; the issuer and subject are the
same entity, and the public key within the certificate is used to
verify its own signature. The public key of the Control Plane root
certificate and proof of ownership of the private key are embedded in
the TRC of an ISD, via the self-signed Control Plane root
certificate. This facilitates the bootstrapping of trust within an
ISD, and marks the Control Plane root certificates as the starting
point of an ISD's certificate verification path.
The RECOMMENDED maximum validity period of a Control Plane root
certificate is 1 year.
*Note*: The TRC of each ISD contains a trusted set of Control Plane
root certificates, and 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.
2.3. Control Plane Issuing CA Certificate
The private key of the Control Plane issuing CA certificate is used
to sign Control Plane AS certificates. Consequently, Control Plane
issuing CA certificates holding the public key of the Control Plane
CA are used to verify Control Plane AS certificates.
de Kater, et al. Expires 22 October 2026 [Page 14]
Internet-Draft SCION CP-PKI April 2026
The public key needed to verify the issuing CA certificate is in a
Control Plane root certificate. Issuing CA certificates do not
bundle the root certificate needed to verify them. In order to
verify an issuing 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 Control Plane issuing CA
certificate is 11 days. This is much shorter than root certificates,
which have a longer recommended maximum validity period, because they
are part of the TRC of an ISD, which itself also has a longer
recommended maximum validity (see Table 1). This ensures that the
TRC need not be updated all the time and is thus relatively stable.
2.4. Control Plane AS Certificate
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.
2.5. Voting 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.
Regular and sensitive voting certificates are used to verify regular
and sensitive TRC updates respectively, and are embedded in the TRC.
2.5.1. Regular Voting Certificate
Regular voting certificates may be used to cast a vote 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.
de Kater, et al. Expires 22 October 2026 [Page 15]
Internet-Draft SCION CP-PKI April 2026
The RECOMMENDED maximum validity period of a regular voting
certificate is 1 year.
2.5.2. Sensitive Voting Certificate
Sensitive voting certificates may be used to cast a vote 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.
2.6. Key Pairs Overview and Notations
Table 1 and Table 2 below provide an overview of certificates and
corresponding key pairs.
+======================+==============+============================+
| Name | Notation (1) | Used to verify/sign |
+======================+==============+============================+
| Sensitive voting key | K_sens | TRC updates (sensitive) |
+----------------------+--------------+----------------------------+
| Regular voting key | K_reg | TRC updates (regular) |
+----------------------+--------------+----------------------------+
| CP root key | K_root | CP issuing CA certificates |
+----------------------+--------------+----------------------------+
| CP CA key | K_CA | CP AS certificates |
+----------------------+--------------+----------------------------+
| CP AS key | K_AS | CP messages, path segments |
+----------------------+--------------+----------------------------+
Table 1: Key chain
(1) K_x = PK_x + SK_x, where x = certificate type, PK_x = public key,
and SK_x = private key
de Kater, et al. Expires 22 October 2026 [Page 16]
Internet-Draft SCION CP-PKI April 2026
+==============+==========+============+=================+==========+
| Name | Notation | Signed | Contains | Validity |
| | | with | | (2) |
+==============+==========+============+=================+==========+
| TRC (trust | TRC | SK_sens, | C_root, C_sens, | 1 year |
| root conf.) | | SK_reg (1) | C_reg (1) | |
+--------------+----------+------------+-----------------+----------+
| Sensitive | C_sens | SK_sens | PK_sens | 5 years |
| voting | | | | |
| cert. | | | | |
+--------------+----------+------------+-----------------+----------+
| Regular | C_reg | SK_reg | PK_reg | 1 year |
| voting | | | | |
| cert. | | | | |
+--------------+----------+------------+-----------------+----------+
| CP root | C_root | SK_root | PK_root | 1 year |
| certificate | | | | |
+--------------+----------+------------+-----------------+----------+
| CP issuing | C_CA | SK_root | PK_CA | 11 days |
| CA | | | | (3) |
| certificate | | | | |
+--------------+----------+------------+-----------------+----------+
| CP AS | C_AS | SK_CA | PK_AS | 3 days |
| certificate | | | | |
+--------------+----------+------------+-----------------+----------+
Table 2: Certificates
(1) Multiple signatures and certificates of each type MAY be included
in a TRC.
(2) Recommended maximum validity period. Note that initial AS
certificates may have a longer validity (e.g. 10-30 days) to allow
for enough time for deployment.
(3) A validity of 11 days with 4 days overlap between two issuing CA
certificates is RECOMMENDED to enable the best possible operational
procedures when performing a issuing CA certificate rollover.
Figure 2 shows the content of a base/initial TRC, and the
relationship between a TRC and the five types of certificates. The
initial signatures are replaced by those of the Regular Voting
Certificates with the first regular update to the base TRC.
+----------------------------------------------+
| TRC 1 |
| (base/initial) |
| +------------------------------------------+ |
| | - Version - Core ASes | |
| | - ID - Description | |
de Kater, et al. Expires 22 October 2026 [Page 17]
Internet-Draft SCION CP-PKI April 2026
| | - Validity - No Trust Reset | |
| | - Grace Period - Voting Quorum | |
| | - ... | |
| +------------------------------------------+ |
| |
| +-------------------+ +--------------------+ |
| | Votes | | Regular Voting | |
| | (cert. indices) | | Certificates | |
| | | | +-----+ +-----+ | |
| | (empty) | | | (1) | | (2) | | |
| | | | | C | | C | | |
| | | | | reg | | reg | | |
| | | | +-----+ +-----+ | |
| +-------------------+ +--------------------+ |
| |
| +--------------------+ +-------------------+ |
| | Signatures | | Sensitive Voting | |
| | +----------------+ | | Certificates | |
| | | 73 A9 4E AO ...| | | | |
| | +----------------+ | | +-----+ +-----+ | |
| | ... | | | (3) | | (4) | | |
| | +----------------+ | | | C | | C | | |
| | | 53 B7 7C 98 ...| | | | sens| | sens| | |
| | +----------------+ | | +-----+ +-----+ | |
| +--------------------+ +-------------------+ |
| |
| +------------------------------------------+ |
| | CP Root Certificates | |
| | | |
| | +-----+ +-----+ +-----+ +-----+ | |
| | | (5) | | (6) | | (7) | | (8) | | |
| | | C | | C | | C | | C | | |
| | | root| | root| | root| | root| ... | |
| | +-----+ +--+--+ +-----+ +--+--+ | |
| +------------+---------------+-------------+ |
+--------------+---------------+---------------+
| |
v v
+-------------+ +-------------+
|CP Issuing CA| |CP Issuing CA|
| Certificate | | Certificate |
+------+------+ +------+------+
| |
v v
+-----------+ +-----------+
| CP AS | | CP AS |
|Certificate| |Certificate|
+-----------+ +-----------+
de Kater, et al. Expires 22 October 2026 [Page 18]
Internet-Draft SCION CP-PKI April 2026
Figure 2: TRC and the different types of associated certificates.
Arrows indicate the certificate hierarchy.
2.7. X.509 Certificate Profiles and Constraints
Whilst the certificates used in the Control Plane PKI are X.509 v3
certificates, this specification is more restrictive. This section
defines these additional constraints and conditions in comparison to
[RFC5280], which apply to all SCION certificate types. For the
baseline X.509 v3 format, refer to [RFC5280] and [X.509] Clause 7.2.
The following subsections define the specific constraints for the
fields contained in the TBSCertificate sequence.
2.7.1. version
The version field describes the version of the encoded certificate.
It MUST be set to "v3" because extensions are required.
2.7.2. serialNumber
The serialNumber field contains a positive integer assigned by the CA
to each certificate. It MUST be unique for each certificate issued
by a given CA.
2.7.3. signature
The signature field contains the identifier for the signature
algorithm used by the CA to sign the certificate. Current
implementations use the ECDSA signature algorithm defined in [X9.62].
As a consequence, the parameters field in the AlgorithmIdentifier
sequence MUST NOT be used.
The Object Identifiers (OIDs) for ECDSA are defined as ecdsa-with-
SHA256, ecdsa-with-SHA384, and ecdsa-with-SHA512 in [RFC5758].
SCION implementations MUST include support for the ECDSA curves
below.
* NIST P-256 (NISTFIPS186-4, section D.1.2.3) (named secp256r1 in
[RFC5480])
* NIST P-384 (NISTFIPS186-4, section D.1.2.4) (named secp384r1 in
[RFC5480])
* NIST P-521 (NISTFIPS186-4, section D.1.2.5) (named secp521r1 in
[RFC5480])
de Kater, et al. Expires 22 October 2026 [Page 19]
Internet-Draft SCION CP-PKI April 2026
The OIDs for the above curves are specified in section 2.1.1.1 of
[RFC5480].
Other algorithms or curves MAY be employed. Implementations
deviating from the mandatory set generally lose the guarantee of
global interoperability and are suitable primarily for isolated ISDs
that do not require external interconnection. Future protocol
versions may update the set of mandatory algorithms.
The appropriate hash size to use when producing a signature with an
ECDSA key is:
* ECDSA with SHA-256, for a P-256 signing key
* ECDSA with SHA-384, for a P-384 signing key
* ECDSA with SHA-512, for a P-521 signing key
2.7.4. issuer
The issuer field contains the distinguished name (DN) of the entity
that has issued and signed the certificate (usually a CA). This
field MUST be non-empty. In addition to the attributes described in
[RFC5280] section 4.1.2.4, SCION implementations MUST also support
the SCION-specific id-at-ia attribute identifying the SCION ISD and
AS numbers.
2.7.4.1. id-at-ia Attribute
The id-at-ia attribute identifies the SCION ISD and AS numbers. Its
object identifier is defined in Appendix A.
The string representation of the ISD-AS number attribute MUST follow
the formatting defined in [I-D.dekater-scion-controlplane], section
"Text Representation" where AS numbers in the lower 32-bit range are
represented in decimal notation, and others in hexadecimal notation.
Voting AS and issuing CA certificates MUST include the ISD-AS number
attribute 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.
For issuing CA certificates, the inclusion of the ISD-AS number
ensures the Control Plane knows from which AS to retrieve the
certificate, thereby avoiding circular dependencies.
de Kater, et al. Expires 22 October 2026 [Page 20]
Internet-Draft SCION CP-PKI April 2026
Voting-only certificates are not required to include the ISD-AS
number attribute in their distinguished name.
2.7.5. validity
The validity field defines the validity period of the certificate.
All certificates MUST have a well-defined expiration date.
GeneralizedTime value "99991231235959Z" MUST NOT be used. The
recommended maximum validity period for each type of certificate is
described in Section 2.6. SCION implementations SHOULD adopt these
values.
2.7.6. subject
The subject field defines the entity that owns the certificate. It
MUST NOT be empty. The same constraints as the issuer field apply.
For details, see Section 2.7.4 and Section 2.7.4.1.
2.7.7. subjectPublicKeyInfo
The 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.
* *SCION constraints*: For constraints regarding the algorithm, see
the signature field.
2.7.8. issuerUniqueID
The issuerUniqueID field MUST NOT be used.
2.7.9. subjectUniqueID
The subjectUniqueID field MUST NOT be used.
2.8. Extensions
[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 [X.509] are clause 7.2 and clause 9,
respectively.
The following extensions are relevant for the SCION PKI:
* authorityKeyIdentifier
de Kater, et al. Expires 22 October 2026 [Page 21]
Internet-Draft SCION CP-PKI April 2026
* subjectKeyIdentifier
* keyUsage
* extKeyUsage
* basicConstraints
The following sections describe the SCION-specifics in regard to
these extensions.
2.8.1. authorityKeyIdentifier Extension
The authorityKeyIdentifier extension identifies the public key
corresponding to the private key used to sign a certificate.
For the syntax and definition of the authorityKeyIdentifier
extension, see [RFC5280], section 4.2.1.1, and [X.509], clause
9.2.2.1.
The authorityKeyIdentifier extension provides three attributes to
specify the public key:
* keyIdentifier
* authorityCertIssuer
* authorityCertSerialNumber
In SCION, using the keyIdentifier attribute is the preferred way to
specify the authorityKeyIdentifier extension.
SCION implementations MAY also support the use of the
authorityCertIssuer and authorityCertSerialNumber attributes.
However, if these attributes are set and support for them is missing,
implementations SHOULD error out.
This extension MUST be marked as non-critical. Implementations MUST
return an error if the extension is not present AND the certificate
is not self-signed.
2.8.2. 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.
de Kater, et al. Expires 22 October 2026 [Page 22]
Internet-Draft SCION CP-PKI April 2026
For the syntax and definition of the subjectKeyIdentifier extension,
see [RFC5280], section 4.2.1.2, and [X.509], clause 9.2.2.2.
This extension MUST be marked as non-critical. Implementations MUST
return an error if the extension is not present.
2.8.3. 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
[X.509], 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.
* keyCertSign: The public key can be used to verify the CA signature
on a control plane AS certificate.
Other attributes are not used.
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.8.2).
When present, this extension SHOULD be marked as critical.
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.
de Kater, et al. Expires 22 October 2026 [Page 23]
Internet-Draft SCION CP-PKI April 2026
+==================+=============+==========+==========+==========+
| Certificate Type | Root | Issuing | AS | Voting |
| | | CA | | |
+==================+=============+==========+==========+==========+
| _Attribute:_ | | | | |
+------------------+-------------+----------+----------+----------+
| keyUsage | REQUIRED | REQUIRED | REQUIRED | OPTIONAL |
| extension itself | | | | |
+------------------+-------------+----------+----------+----------+
| digitalSignature | MUST NOT be | MUST NOT | MUST be | MUST NOT |
| bit | asserted | be | asserted | be |
| | (1) | asserted | | asserted |
| | | (2) | | |
+------------------+-------------+----------+----------+----------+
| keyCertSign bit | MUST be | MUST be | MUST NOT | MUST NOT |
| | asserted | asserted | be | be |
| | | | asserted | asserted |
+------------------+-------------+----------+----------+----------+
Table 3: keyUsage extension - Specifications per certificate type
(1) Root certificates SHOULD NOT be used to verify control plane
messages.
(2) Issuing CA certificates SHOULD NOT be used to verify control
plane messages.
2.8.4. 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 [X.509], 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.
de Kater, et al. Expires 22 October 2026 [Page 24]
Internet-Draft SCION CP-PKI April 2026
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 TRC setup to distinguish
root certificates, regular voting certificates, and sensitive voting
certificates from each other. For more information, see
Section 3.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.
de Kater, et al. Expires 22 October 2026 [Page 25]
Internet-Draft SCION CP-PKI April 2026
+==================+==========+========+===========+===============+
|Certificate Type |Root |Issuing |AS |Voting |
| | |CA | | |
+==================+==========+========+===========+===============+
|_Attribute:_ | | | | |
+------------------+----------+--------+-----------+---------------+
|extKeyUsage |REQUIRED |OPTIONAL|REQUIRED |REQUIRED |
|extension itself | | | | |
+------------------+----------+--------+-----------+---------------+
|id-kp-serverAuth |MUST NOT |MUST NOT|MUST be |MUST NOT be |
| |be |be |included, |included |
| |included |included|if the | |
| | | |certificate| |
| | | |is used on | |
| | | |the server-| |
| | | |side of a | |
| | | |control | |
| | | |plane TLS | |
| | | |session. | |
+------------------+----------+--------+-----------+---------------+
|id-kp-clientAuth |MUST NOT |MUST NOT|MUST be |MUST NOT be |
| |be |be |included, |included |
| |included |included|if the | |
| | | |certificate| |
| | | |is used on | |
| | | |the client-| |
| | | |side of a | |
| | | |control | |
| | | |plane TLS | |
| | | |session. | |
+------------------+----------+--------+-----------+---------------+
|id-kp-timeStamping|MUST be | |MUST be |MUST be |
| |included | |included |included |
+------------------+----------+--------+-----------+---------------+
|SCION-specific |id-kp-root| | |Regular voting |
|attributes (see |MUST be | | |cert: id-kp- |
|Section 2.8.4.1) |included | | |regular MUST be|
| | | | |included. |
| | | | |Sensitive |
| | | | |voting cert: |
| | | | |id-kp-sensitive|
| | | | |MUST be |
| | | | |included |
+------------------+----------+--------+-----------+---------------+
Table 4: extKeyUsage extension - Specifications per certificate type
de Kater, et al. Expires 22 October 2026 [Page 26]
Internet-Draft SCION CP-PKI April 2026
*Note*: the use of extKeyUsage in Root certificates renders them
incompatible with standard TLS handshakes according to [RFC5280],
because the id-kp-serverAuth attribute is not set. While current
implementations follow what described in this document, the use of
extKeyUsage should be revised in future protocol iterations.
2.8.4.1. SCION-Specific Key Purposes
Three additional key purpose attributes differentiate certificate
roles within the CP-PKI:
* id-kp-sensitive (OID 1.3.6.1.4.1.55324.1.3.1): identifies
sensitive voting certificate
* id-kp-regular (OID 1.3.6.1.4.1.55324.1.3.2): identifies a regular
voting certificate
* id-kp-root (OID 1.3.6.1.4.1.55324.1.3.3): identifies a root
certificate
The formal ASN.1 definitions for these attributes are provided in
Appendix A.
2.8.5. 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 [X.509], 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 asserted and the extension
MUST be marked as critical.
* pathLenConstraint attribute: This attribute is only relevant if
the cA attribute is set to TRUE and 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.
de Kater, et al. Expires 22 October 2026 [Page 27]
Internet-Draft SCION CP-PKI April 2026
+===================+==========+==========+===========+============+
| Certificate Type | Root | Issuing | AS | Voting |
| | | CA | | (regular |
| | | | | and |
| | | | | sensitive) |
+===================+==========+==========+===========+============+
| _Attribute:_ | | | | |
+-------------------+----------+----------+-----------+------------+
| basicConstraints | REQUIRED | REQUIRED | SHOULD | SHOULD NOT |
| extension itself | | | NOT be | be present |
| | | | present | |
+-------------------+----------+----------+-----------+------------+
| cA | MUST be | MUST be | If the | If the |
| | asserted | asserted | extension | extension |
| | | | is | is |
| | | | present, | present, |
| | | | this | this |
| | | | attribute | attribute |
| | | | MUST NOT | MUST NOT |
| | | | be | be |
| | | | asserted | asserted |
+-------------------+----------+----------+-----------+------------+
| pathLenConstraint | SHOULD | SHOULD | MUST NOT | MUST NOT |
| | be set | be set | be | be |
| | to "1" | to "0" | included | included |
| | | (1) | | |
+-------------------+----------+----------+-----------+------------+
Table 5: basicConstraints extension - Specifications per
certificate type
(1) Control Plane CAs can only issue end-entity certificates.
3. Trust Root Configuration Specification
The Trust Root Configuration (TRC) contains policy information about
an ISD and acts as a distribution mechanism for the trust anchors of
that ISD. It enables the securing of 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 which are described in Section 3.6.
The TRC is a signed collection of [X.509] v3 certificates.
Additionally, the TRC contains ISD-specific policies encoded in CMS
signed-data ([RFC5652] section 5).
de Kater, et al. Expires 22 October 2026 [Page 28]
Internet-Draft SCION CP-PKI April 2026
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.
This section specifies the TRC including format definitions and
payload fields. The section uses the ITU-T [X.680] syntax.
3.1. TRC Types and States
The following types of TRCs exist:
* Initial: The very first TRC of an ISD is the initial TRC of that
ISD. It is a special case of the base TRC, where the number of
the ISD is specified.
* Base: A base TRC is either the initial TRC, or the first TRC after
a trust reset (see Section 1.4.1). Trust for a base TRC cannot be
inferred by verifying a TRC update; base TRCs are trusted
axiomatically, similarly to how root certificates are trusted by
clients in the Web PKI.
* Update: All non-base TRCs are updated TRCs. They are the product
of either a regular or a sensitive update.
A TRC can have the following states:
* Valid: The validity period of a TRC is defined in the TRC itself,
in the validity field (see Section 3.2.3). A TRC is considered
valid if the current time falls within its validity period.
* Active: An active TRC is a valid TRC that can be used for
verifying certificate signatures. This is either the latest TRC
or the predecessor TRC if it is still in its grace period (as
defined in the gracePeriod field of the new TRC, see
Section 3.2.4). No more than two TRCs can be active at the same
time for any ISD.
Figure 2 shows the content of both a base/initial TRC, the changes
made with the first regular update to the base TRC. All elements of
the TRC is detailed in the following subsections.
de Kater, et al. Expires 22 October 2026 [Page 29]
Internet-Draft SCION CP-PKI April 2026
3.2. TRC Fields
The TRC holds the root and voting certificates of the ISD, defining
the ISD's trust policy. Its ASN.1 module is described in Appendix B.
Its fields are contained in a TRCPayload sequence. This section
describes their syntax and semantics.
3.2.1. version
The version field describes the version of the TRC format
specification. It MUST be "v1".
3.2.2. iD
The iD field contains an unique identifier for the TRC, constituted
by a sequence of:
* ISD number (iSD attribute),
* base number (baseNumber attribute). It indicates the starting
point of the current TRC update chain. This starting point is
either the ISD's initial TRC or the currently valid base TRC, if
the valid base TRC differs from the initial TRC. The latter is
the case after a trust reset.
* TRC serial number (serialNumber attribute). It represents the
current update cycle, counting from the initial TRC of a specific
ISD.
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 and 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 which facilitates the
unique identification of the predecessor and successor TRC in an
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.
The following example illustrates how to specify the ID of the TRCs
in an TRC update chain for _ISD 15_. The IDs are given in a human-
readable notation, where Bxx is the base number, and Sxx the serial
number.
de Kater, et al. Expires 22 October 2026 [Page 30]
Internet-Draft SCION CP-PKI April 2026
+===========+=================+====================================+
| Update | TRC ID | Remarks |
+===========+=================+====================================+
| Initial | ISD15-B01-S01 | |
+-----------+-----------------+------------------------------------+
| Regular | ISD15-B01-S02 | Only the serial number is |
| | | incremented. |
+-----------+-----------------+------------------------------------+
| Regular | ISD15-B01-S03 | Only the serial number is |
| | | incremented. |
+-----------+-----------------+------------------------------------+
| Sensitive | ISD15-B01-S04 | Only the serial number is |
| | | incremented. |
+-----------+-----------------+------------------------------------+
| Trust | ISD15-*B05*-S05 | A trust reset includes the |
| reset | | 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 | ISD15-B05-S06 | Only the serial number is |
| | | incremented. |
+-----------+-----------------+------------------------------------+
| And so on | | |
+-----------+-----------------+------------------------------------+
Table 6: ID of TRCs in TRC update chain
3.2.3. validity
The validity field defines the TRC validity period. 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.
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.
The validity field consists of a sequence of a notBefore and a
notAfter date, both encoded as GeneralizedTime. All TRCs MUST have a
well-defined expiration date. SCION implementations MUST NOT create
TRCs that use GeneralizedTime value "99991231235959Z", and verifiers
MUST error out when encountering such a TRC.
de Kater, et al. Expires 22 October 2026 [Page 31]
Internet-Draft SCION CP-PKI April 2026
3.2.4. gracePeriod
The gracePeriod field specifies the duration, in seconds, during
which the predecessor TRC remains active after a new TRC is issued.
This grace period starts at the beginning of the validity period of
the new TRC.
A predecessor TRC ceases to be active when the earliest of the
following events occurs:
* the grace period expires;
* the predecessor TRC reaches its expiration time (notAfter); or
* a subsequent TRC update (i.e., the successor to the new TRC) is
announced.
In a base TRC, gracePeriod value MUST be zero. In a non-base TRC,
gracePeriod SHOULD be greater than zero. The defined duration SHOULD
provide sufficient overlap between the two TRCs to ensure
uninterrupted operations within the ISD. If the grace period is too
short, some Control Plane AS certificates may expire before the
corresponding ASes can fetch an updated version from their CA.
3.2.5. noTrustReset
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.
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 that 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.
de Kater, et al. Expires 22 October 2026 [Page 32]
Internet-Draft SCION CP-PKI April 2026
3.2.6. votes
The votes field contains a sequence of indices referencing 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.2.11.
In a base TRC, the votes sequence MUST be empty. Every entry in the
votes sequence MUST be unique. Further restrictions on votes are
discussed in Section 3.5.
The votes sequence MUST be present to prevent the stripping of voting
signatures from the TRC. Without this sequence, an attacker could
transform a TRC with more voting signatures than the voting quorum
into multiple verifiable TRCs with the same payload, but different
voting signature sets, which directly violates the uniqueness
requirement of a TRC.
3.2.7. votingQuorum
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.
3.2.8. coreASes
The coreASes field contains a sequence listing the core AS numbers
within the ISD.
Each AS number MUST be unique and encoded as a PrintableString using
the formatting defined in [I-D.dekater-scion-controlplane], section
"Text Representation".
To assign or revoke core status, the target AS number is added to or
removed from this sequence. For such modification, a sensitive TRC
update is REQUIRED.
3.2.9. authoritativeASes
The authoritativeASes field contains a sequence listing the
authoritative AS numbers in the ISD. Authoritative ASes are those
ASes in an ISD that always possess the latest TRCs for the ISD and
initiate TRC update announcements.
de Kater, et al. Expires 22 October 2026 [Page 33]
Internet-Draft SCION CP-PKI April 2026
Every authoritative AS MUST be a core AS (i.e., be listed in the
coreASes field). The encoding and uniqueness requirements for this
sequence are identical to those of the coreASes field.
As with core ASes, assigning or revoking authoritative status is
performed by adding or removing the target AS number from this
sequence. For such modification, a sensitive TRC update is REQUIRED.
3.2.10. description
The description field contains a UTF-8 encoded string that describes
the ISD. It SHOULD NOT be empty. The description MUST be in English
and MAY additionally contain information in other languages.
3.2.11. certificates
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 sensitive voting certificate,
* a regular voting certificate, or
* a CP root certificate.
A certificate that is no control plane root or voting certificate
MUST NOT be included in the sequence of certificates in the
certificates field.
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.8.4.
The following constraints MUST hold for each certificate in the
certificates field of the TRC payload:
* Each certificate MUST be unique in the sequence of certificates.
* The issuer / serialNumber pair for each certificate MUST be
unique.
de Kater, et al. Expires 22 October 2026 [Page 34]
Internet-Draft SCION CP-PKI April 2026
* If an ISD-AS number is present in the distinguished name of the
certificate, this ISD number MUST be equal to the ISD number of
the TRC (which is defined in the iD field (see Section 3.2.2).
* Every certificate MUST have a validity period that fully contains
the validity period of this TRC. That is, the 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.
* Per certificate type, every certificate distinguished name MUST be
unique.
The following must hold for the entire sequence of certificates in
the certificates field:
* votingQuorum <= count (sensitive voting certificates)
That is, the quorum defined in the TRC's votingQuorum field
(Section 3.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)
That is, the quorum defined in the TRC's votingQuorum field
(Section 3.2.7) MUST be smaller than or equal to the number of
regular voting certificates specified in the TRC's certificates
field.
3.3. TRC Signature Syntax
To guarantee the integrity and authenticity of the distributed trust
anchors, each TRC is digitally signed using the Cryptographic Message
Syntax (CMS). The signed TRC payload uses the CMS signed-data
content type as specified in Section 5 of [RFC5652], and is
encapsulated in a CMS ContentInfo element, as defined in Section 3 of
[RFC5652].
For signature calculation, the data that is to be signed MUST be
encoded using ASN.1 distinguished encoding rules (DER) [X.690].
3.3.1. SCION-specific rules
SCION implementations MUST fulfill the following additional rules, as
well as the general syntax rules specified in [RFC5652]:
* EncapsulatedContentInfo sequence:
de Kater, et al. Expires 22 October 2026 [Page 35]
Internet-Draft SCION CP-PKI April 2026
- The eContentType field MUST be set to "id-data".
- The content of the eContent field MUST be the DER-encoded TRC
payload. This has the benefit that the format is backwards
compatible with PKCS #7, as described in Section 5.2.1 of
[RFC5652].
* SignedData sequence:
- The 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.2.11).
- The 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:
- The type of signer identifier chosen here MUST be
IssuerAndSerialNumber.
* SignerInfo sequence:
- The 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]).
- The algorithm specified in the signatureAlgorithm field MUST be
one of the algorithms supported by SCION . For details, see
signature Field - Additional Information (Section 2.7.3).
- The digestAlgorithm is determined by the algorithm specified in
the signatureAlgorithm field.
3.3.2. TRC Equality
The signer information in the signed TRC is part of an unordered set,
as per [RFC5652]. This implies that the signer information can be
reordered without affecting verification, although certain operations
require TRCs to be equal in accordance with the following definition:
*Two TRCs are equal, if and only if their payloads are byte equal.*
de Kater, et al. Expires 22 October 2026 [Page 36]
Internet-Draft SCION CP-PKI April 2026
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:
* The REQUIRED signatures from voting certificates are explicitly
mentioned in the 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.2.6.
* The REQUIRED signatures for new certificates are implied by the
currently valid TRC payload, and, in case of a TRC update, the
predecessor payload.
3.4. Certification Path - Trust Anchor Pool
The certification path of a Control Plane AS certificate starts in a
Control Plane root certificate. The Control Plane root certificate
for a given ISD is distributed via the TRC.
However, AS certificates and the corresponding issuing CA
certificates are not part of the TRC, but are 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 builds a collection of root certificates
from the latest TRC of the relevant ISD.
Note that any entity sending information that is secured by the
Control Plane PKI, such as control plane messages, MUST be able to
provide all the necessary trust material including 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 through the control plane API
described in [I-D.dekater-scion-controlplane], section "Distribution
of Cryptographic 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 following section explains how to build a trust anchor pool.
de Kater, et al. Expires 22 October 2026 [Page 37]
Internet-Draft SCION CP-PKI April 2026
3.4.1. TRC Selection For Trust Anchor Pool
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 and 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 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 acting as trust anchors.
"""
# Find highest base number that has a TRC with 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 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()
de Kater, et al. Expires 22 October 2026 [Page 38]
Internet-Draft SCION CP-PKI April 2026
# If the grace period has passed, only the certificates in
# that TRC 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 acting as trust anchors.
"""
roots = set()
for cert in trc.certificates:
if not cert.basic_constraints.ca:
continue
roots.add(cert)
return roots
3.5. TRC Updates
All non-base TRCs of an ISD are updates of the ISD's base TRC(s) and
constitute a chain. Updates are categorized as regular or sensitive,
depending on which payload fields are being modified.
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 whilst some only apply to a regular
or a sensitive TRC update. Based on the type of update, different
sets of voters are needed to create a verifiable TRC update and the
corresponding voting (signing) process is also described. Finally,
this section describes checks to verify a newly issued TRC.
de Kater, et al. Expires 22 October 2026 [Page 39]
Internet-Draft SCION CP-PKI April 2026
3.5.1. Changed or New Certificates
In the context of a TRC update,
* A certificate is _changing_ if the certificate is part of the
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_.
* A certificate is _new_ if there is *no* certificate of the same
type and distinguished name at all in the certificates sequence of
the predecessor TRC.
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.
3.5.2. Update Rules - Overview
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.
de Kater, et al. Expires 22 October 2026 [Page 40]
Internet-Draft SCION CP-PKI April 2026
+===========+====================+==============+===================+
| Type of | Unchanged | Changed | Other Rules to |
| TRC | Elements | Elements | Hold |
| Update | | | |
+===========+====================+==============+===================+
| Both | - iD field: iSD | iD field: | votes field: |
| Regular | and baseNumber | serialNumber | Number of votes |
| AND | - noTrustReset | MUST be | (indices) => |
| Sensitive | field | incremented | number set in the |
| | | by 1 | votingQuorum |
| | | | field of the |
| | | | predecessor TRC |
+-----------+--------------------+--------------+-------------------+
| Regular | - Quorum in the | | votes field: |
| | votingQuorum | | - All votes MUST |
| | field | | only refer to |
| | - Core ASes in | | _regular_ voting |
| | the coreASes | | certificates in |
| | field | | the predecessor |
| | - ASes in the | | TRC |
| | authoritativeASes | | - MUST include |
| | field | | votes of each |
| | - Nr. and | | changed regular |
| | distinguished | | voting |
| | names of root & | | certificate from |
| | voting | | the predecessor |
| | certificates in | | TRC |
| | the certificates | | signatures field: |
| | field | | - MUST include |
| | - Set of | | signatures of |
| | sensitive voting | | each changed root |
| | certificates in | | certificate from |
| | the certificates | | the predecessor |
| | field | | TRC |
+-----------+--------------------+--------------+-------------------+
| Sensitive | If the update | | votes field: |
| | does not qualify | | - All votes MUST |
| | as a regular | | only refer to |
| | update, it is a | | _sensitive_ |
| | sensitive update | | voting |
| | | | certificates in |
| | | | the predecessor |
| | | | TRC |
+-----------+--------------------+--------------+-------------------+
Table 7: Overview of the update types and corresponding rules
de Kater, et al. Expires 22 October 2026 [Page 41]
Internet-Draft SCION CP-PKI April 2026
3.5.3. General Update Rules
The following rules MUST hold for each updated TRC, independent of
the update type:
* The iSD and baseNumber in the iD field MUST NOT change (see also
Section 3.2.2).
* The serialNumber in the iD field MUST be incremented by one.
* The noTrustReset field MUST NOT change (see also Section 3.2.5).
* The 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.2.6 and Section 3.2.11.
* The number of votes in the updated TRC MUST be greater than or
equal to the number set in the votingQuorum field of the
predecessor TRC (see Section 3.2.7). The number of votes
corresponds to the number of indices in the votes field of the
updated TRC.
3.5.4. Regular 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 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:
- The voting quorum set in the votingQuorum field.
- The core ASes specified in the coreASes field.
- The authoritative ASes specified in the authoritativeASes
field.
- The number of sensitive and regular voting certificates as well
as Control Plane root certificates included in the certificates
field and their distinguished names.
de Kater, et al. Expires 22 October 2026 [Page 42]
Internet-Draft SCION CP-PKI April 2026
- The set of sensitive voting certificates specified in the
certificates field.
* For every regular voting certificate that changes, the regular
voting certificate in the predecessor TRC is part of the voters on
the updated TRC. That is, for each changed regular voting
certificate, an index in the votes field of the updated TRC MUST
refer to the changed regular voting certificate in the predecessor
TRC.
* For every Control Plane root certificate that changes, the updated
TRC MUST include a signature created with the private key
belonging to the changed Control Plane root certificate (which is
part of the predecessor TRC).
* In order for a regular TRC update to be verifiable, all votes MUST
be cast by _regular_ voting certificates. That is, each index in
the votes field of the regularly updated TRC MUST refer to a
_regular_ voting certificate in the certificates field of the
predecessor TRC.
3.5.5. Sensitive TRC Update
If a TRC update does not qualify as a regular update, it is
considered a sensitive update.
* In order for a sensitive update to be verifiable, all votes MUST
be cast by _sensitive_ voting certificates. That is, each index
in the votes field of the sensitively updated TRC MUST refer to a
_sensitive_ voting certificate in the certificates field of the
predecessor TRC.
3.5.6. Signing a TRC Update
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.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 is 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.5.1.
de Kater, et al. Expires 22 October 2026 [Page 43]
Internet-Draft SCION CP-PKI April 2026
It is up to the ISD members to decide how the "casting a vote"
procedure for updated TRCs will take place. Some ISDs make a
distinction between regular and sensitive updates by dividing the
regular and sensitive signing keys in different security classes,
e.g. they keep the regular key in an online vault while the sensitive
key would be stored offline. 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 keep both regular and sensitive keys online
and perform both updates automatically.
3.5.7. TRC Update Verification
To verify a TRC update, the relying party MUST perform the following
checks:
* Check that the specified update rules as described above are
respected.
* Check that all signatures are verifiable and no superfluous
signatures are attached.
* In case of a regular update:
- check that the signatures for the changing certificates are
present and verifiable, and
- check that all votes are cast by a regular voting certificate.
* In case of a sensitive update:
- check that all votes are cast by a sensitive voting
certificate.
If one or more of the above checks gives a negative result, the
updated TRC SHOULD be rejected.
3.6. Initial TRC Signing Ceremony
The very first base TRC of an ISD - called the initial TRC - is a
special case of the base TRC. The initial TRC MUST be signed during
a signing ceremony where all voting representatives of the initial
TRC take part to sign the TRC and exchange their public keys.
Following this, all entities within an ISD can obtain the TRC by
means of a secure offline or online mechanism.
de Kater, et al. Expires 22 October 2026 [Page 44]
Internet-Draft SCION CP-PKI April 2026
Appendix C describes a possible procedure for the signing ceremony of
an ISD's initial TRC. Whilst it is up to the initial members of an
ISD how to organize the signing ceremony, it recommended to implement
a process in line with the ceremony described in the Appendix.
4. CP-PKI Operations
This section details the procedures for deploying the CP-PKI and
securing control plane communications.
4.1. Distribution of TRCs
4.1.1. Base TRC
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.6.
4.1.2. TRC Update Discovery
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.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, and SHOULD discover TRC updates in a matter of
minutes to hours. Additionally, any entity sending information that
is secured by the Control Plane 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:
* _Beaconing Process_
The TRC version is announced in the beaconing process. Each AS
MUST announce what it considers to be the latest TRC, and MUST
include the hash value of the TRC contents to facilitate the
discovery of discrepancies. Therefore, relying parties that are
part of the beaconing process discover TRC updates passively, i.e.
a core AS notices TRC updates for remote ISDs that are on the
beaconing path. A non-core AS only notices TRC updates for the
local ISD through the beaconing process. The creation of a new
TRC SHOULD trigger the generation of new control plane messages,
as the propagation of control plane messages will help other ASes
rapidly discover the new TRC.
de Kater, et al. Expires 22 October 2026 [Page 45]
Internet-Draft SCION CP-PKI April 2026
* _Path Lookup_
In every path segment, all ASes MUST reference the latest TRC of
their ISD. Therefore, when resolving paths, every relying party
will notice TRC updates, even remote ones.
* _Active Discovery_
Any TRC can be obtained at any time from the sender of the
information it secures; either in a specific version or in its
latest available version. The necessary query and response is
described in [I-D.dekater-scion-controlplane], section
"Distribution of Cryptographic Material".
*Note:* The first two mechanisms above only work when there is active
communication between the relying party and the ISD in question.
4.2. Signing and Verifying Control Plane Messages
The main purpose of the Control Plane PKI is providing a mechanism to
distribute and authenticate public keys that are used to verify
control plane messages and information, e.g. 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 Control Plane PKI.
The following sections specify the requirements that apply to the
signing and verification of control plane messages.
4.2.1. Signing a Control Plane Message
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 to
ensure that a relying party can identify which certificate to use to
verify the signed message:
* ISD-AS number: The ISD-AS number of the signing entity. For
specification details, see Section 2.7.4.1.
* Subject key identifier: The identifier of the public key to be
used to verify the message. For specification details, see
Section 2.8.2.
Additionally, the signer SHOULD include the following information:
* Serial and base number of the latest TRC: Including this
information allows relying parties to discover TRC updates and
trust resets. For specification details, see Section 3.2.2.
de Kater, et al. Expires 22 October 2026 [Page 46]
Internet-Draft SCION CP-PKI April 2026
* Timestamp: For many messages, the time at which it was signed is
useful information to ensure freshness.
4.2.2. Verifying a Control Plane Message
To verify a received control plane message, 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 issuing
CA certificate into certificate chains. For efficiency, SCION
distributes these certificate chains separately from the signed
messages.
A certificate chain is verified against the Control Plane root
certificate, although the root certificate is bundled with the TRC
and *not* in the chain. This makes it possible to extend the
validity period of the root certificate and 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:
1. Build a collection of root certificates from the latest TRC of
the relevant ISD (that is, the ISD referenced in the signature
metadata of the message). If the grace period (see
Section 3.2.4) introduced by the latest TRC is still on-going,
the root certificates in the second-to-latest TRC MUST also be
included. For a description on how to build the correct
collection of certificates, see Section 3.4.1.
2. If the signature metadata of the message contains the serial and
base number of the latest TRC, the relying party MUST check that
they have this latest TRC. If not, the relying party MUST
request the latest TRC.
3. 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:
* The ISD-AS number in the subject of the AS certificate MUST
match the ISD-AS number in the signature metadata. See also
Section 2.7.4.1.
* The subject key identifier of the AS certificate MUST match
the subject key identifier in the signature metadata. See
also Section 2.8.2.
de Kater, et al. Expires 22 October 2026 [Page 47]
Internet-Draft SCION CP-PKI April 2026
* The AS certificate MUST be valid at verification time, which
will normally be the current time. In special cases, e.g.
auditing, the time can be set to the past to check if the
message was verifiable at the given time.
4. After selecting a certificate chain to verify the control plane
messages, the relying party MUST verify the certificate chain by:
* Executing the regular X.509 verification procedure. For
details, see [X.509].
* Checking that
- all subjects of the certificates in the chain carry the
same ISD number (see also Section 2.7.4.1,
- each certificate is of the correct type (see also
Section 2), and
- the CA certificate validity period covers the AS
certificate validity period.
5. If the verification of the certificate chain was successful, the
relying party can now verify the control plane messages with the
root certificates from the certificate chain.
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.
4.3. Issuing Control Plane AS Certificates
The steps REQUIRED to issue a new AS certificate are the following:
1. The AS creates a new key pair and a certificate signing request
(CSR) using that key pair.
2. The AS sends the certificate signing request to the relevant CA
within the ISD.
3. The CA uses its CA key and the CSR to create the new AS
certificate.
de Kater, et al. Expires 22 October 2026 [Page 48]
Internet-Draft SCION CP-PKI April 2026
4. The CA sends the AS certificate back to the AS.
When an AS joins an ISD, the first CSR is sent out of band to one of
the CAs as part of the formalities to join the ISD. Subsequent
certificate renewals MAY be automated and can leverage the control
plane communication infrastructure (see
[I-D.dekater-scion-controlplane], section "Renewal of Cryptographic
Material").
5. Deployment Considerations
5.1. PKI Availability
The Control Plane PKI relies on short-lived certificates as an
alternative to revocation, as described in Section 1.4.2. AS
certificates typically have a validity of days (see Table 2), except
for the first issued AS certificate. Should an AS not be able to
renew certificates, it would be cut off from the network.
It is therefore recommended to deploy multiple, independent CAs
within an ISD that can issue certificates to all member ASes and
sustain the appropriate certificate renewal load. ASes should then
be able to quickly switch over to a backup CA to renew their
certificates in time.
5.2. Operational Processes for ISD Governance
An ISD is governed by voting ASes. In existing deployments, voting
ASes may produce a regulations document to facilitate operations.
Such document typically describes:
* governance structure
* roles and responsibilities
* admission criteria
* processes
* protection measures for keys (e.g. use of HSMs)
* actions in case of compromise or regulations breach
This document describes a typical TRC signing ceremony in Appendix C,
but further processes are out-of-scope.
de Kater, et al. Expires 22 October 2026 [Page 49]
Internet-Draft SCION CP-PKI April 2026
6. Security Considerations
SCION fundamentally differs from a global monopolistic trust model as
each ISD manages its own trust roots instead of a single global
entity providing those roots. This structure gives each ISD autonomy
in terms of key management and in terms of trust, and prevents the
occurrence of a global kill switch affecting all ISDs at once.
However, each ISD is still susceptible to compromises that could
affect or halt other components (control plane and forwarding).
This section discussed implication of such trust architecture,
covering _inter_-AS security considerations. All _intra_-AS trust-
and security aspects are out of scope.
6.1. Compromise of an ISD
In SCION there is no central authority that could "switch off" an ISD
as each relies on its own independent trust roots. Each AS within an
ISD is therefore dependent on its ISD's PKI for its functioning,
although the following compromises are potentially possible:
* At TRC level: The private root keys of the root certificates
contained in an TRC are used to sign issuing CA certificates. If
one of these private root keys is compromised, the adversary could
issue illegitimate issuing CA certificates which may be used in
further attacks. To maliciously perform a TRC update, an attacker
would need to compromise multiple voting keys, the number of which
is dependent on the voting quorum set in the TRC. The higher the
quorum, the more unlikely a malicious update will be.
* At CA level: The private keys of an ISD's issuing CA certificates
are used to sign the AS certificates and all ASes within an ISD
obtain certificates directly from the CAs. If one of the CA’s
keys is compromised, an adversary could issue illegitimate AS
certificates which may be used to impersonate ASes in further
attacks. A compromised or misbehaving CA could also refuse to
issue certificates to legitimate ASes, cutting them off the
network if no alternative redundant CA is available.
* At AS level: Each AS within an ISD signs control plane messages
with their AS private key. If the keys of an AS are compromised
by an adversary, this adversary can illegitimately sign control
plane messages including Path Construction Beacons (PCBs). This
means that the adversary can manipulate the PCBs and propagate
them to neighboring ASes or register/store them as path segments.
de Kater, et al. Expires 22 October 2026 [Page 50]
Internet-Draft SCION CP-PKI April 2026
6.1.1. Recovery from Compromise
This section deals with possible recovery from the compromises
discussed in the previous paragraph. As described in Section 1.4.2,
there is no revocation in the Control Plane PKI.
* At TRC level: If any of the root keys or voting keys contained in
the TRC are compromised, the TRC MUST be updated as described in
Section 3.5. A trust reset is only required in the case the
number of compromised keys at the same time is greater or equal
than the TRC's quorum (see Section 3.2.7), and a invalid update
has been produced and distributed in the network.
* At CA level: If the private key related to a issuing CA
certificate is compromised, the impacted CA AS MUST obtain a new
CA certificate from the corresponding root AS. Issuing CA
certificates are generally short lived to limit the impact of
compromise. Alternatively, with a TRC update, a new root keys can
also be forced, invalidating the compromised CA.
* At AS level: In the event of a key compromise of a (non-core) AS,
the impacted AS needs to obtain a new certificate from its CA.
This process will vary depending on internal issuance processes.
6.2. Denial of Service Attacks
The Control Plane PKI lays the foundation for the authentication
procedures in SCION by providing each AS within a specific ISD with a
certified key pair. These keys enable the authentication of all
control plane messages - every AS and endpoint can verify all control
plane messages by following the certificate chain.
The relying party MUST be able to discover and obtain new or updated
cryptographic material. For the control plane messages, this is
simplified by the observation that the sender of a message (e.g. of a
path construction beacon during path exploration or a path segment
during a path lookup) always has all the cryptographic material to
verify it. Thus, the receiver can always immediately obtain all the
cryptographic material from the message originator.
As the corresponding PKI messaging only occurs when the control plane
is already communicating, these requests to obtain cryptographic
material are not prone to additional denial of service attacks. We
refer to the security considerations of
[I-D.dekater-scion-controlplane] for a more detailed description of
DoS vulnerabilities of control plane messages.
de Kater, et al. Expires 22 October 2026 [Page 51]
Internet-Draft SCION CP-PKI April 2026
On the other hand, this does not apply for certificate renewal.
Denial of Service on the CA infrastructure or on the communication
links from the individual ASes to the CA could be used by an attacker
to prevent victim ASes from renewing their certificates and halting
the path discovery process. This risk can be mitigated in multiple
ways:
* CAs only need to be accessible from ASes within the ISD, reducing
the potential DoS attack surface
* relying on multiple CAs within an ISD
* creating policies and processes to renew certificates out-of-band
6.3. TRC Distribution and Trust on First Use
Base TRCs act as an ISD root of trust (see Section 1.4).
If an endpoint retrieves the initial TRC in-band (e.g. from a local
control service or a resolution server) without prior validation, it
effectively operates under a "Trust on First Use" (TOFU) assumption.
Care should therefore be taken in trusting the TRC source.
Should an AS be provisioned with a malicious TRC, it would not be
able to communicate to other ASes in the affected ISD, thereby
limiting impact of a malicious TRC.
7. IANA Considerations
This document has no IANA actions.
The ISD and SCION AS number are SCION-specific numbers. They are
currently allocated by the SCION Association (see
[ISD-AS-assignments]).
8. References
8.1. Normative References
[I-D.dekater-scion-controlplane]
de Kater, C., Rustignoli, N., and S. Hitz, "SCION Control
Plane", Work in Progress, Internet-Draft, draft-dekater-
scion-controlplane-17, 2 April 2026,
<https://datatracker.ietf.org/doc/html/draft-dekater-
scion-controlplane-17>.
de Kater, et al. Expires 22 October 2026 [Page 52]
Internet-Draft SCION CP-PKI April 2026
[I-D.dekater-scion-dataplane]
de Kater, C., Rustignoli, N., Hugly, J., and S. Hitz,
"SCION Data Plane", Work in Progress, Internet-Draft,
draft-dekater-scion-dataplane-14, 7 April 2026,
<https://datatracker.ietf.org/doc/html/draft-dekater-
scion-dataplane-14>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>.
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Elliptic Curve Cryptography Subject Public Key
Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,
<https://www.rfc-editor.org/rfc/rfc5480>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/rfc/rfc5652>.
[RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T.
Polk, "Internet X.509 Public Key Infrastructure:
Additional Algorithms and Identifiers for DSA and ECDSA",
RFC 5758, DOI 10.17487/RFC5758, January 2010,
<https://www.rfc-editor.org/rfc/rfc5758>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9217] Trammell, B., "Current Open Questions in Path-Aware
Networking", RFC 9217, DOI 10.17487/RFC9217, March 2022,
<https://www.rfc-editor.org/rfc/rfc9217>.
[X.509] "ITU-T X.509 (10/2016) | Information technology – Open
Systems Interconnection – The Directory: Public-key and
attribute certificate frameworks", January 2016,
<https://handle.itu.int/11.1002/1000/13031>.
de Kater, et al. Expires 22 October 2026 [Page 53]
Internet-Draft SCION CP-PKI April 2026
[X.680] "ITU-T X.680 (02/2021) | Information technology - Abstract
Syntax Notation One (ASN.1): Specification of basic
notation", January 2021,
<https://handle.itu.int/11.1002/1000/14468>.
[X.690] "ITU-T X.690 (02/2021) | Information technology - ASN.1
encoding rules: Specification of Basic Encoding Rules
(BER), Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER)", January 2021,
<https://handle.itu.int/11.1002/1000/14472>.
[X9.62] "ANSI X9.62-1998 | Public Key Cryptography For The
Financial Services Industry: The Elliptic Curve Digital
Signature Algorithm", 1998.
8.2. Informative References
[BARRERA17]
Barrera, D., Chuat, L., Perrig, A., Reischuk, R., and P.
Szalachowski, "The SCION internet architecture",
Association for Computing Machinery (ACM), Communications
of the ACM vol. 60, no. 6, pp. 56-65, DOI 10.1145/3085591,
May 2017, <https://doi.org/10.1145/3085591>.
[CHUAT22] Chuat, L., Legner, M., Basin, D., Hausheer, D., Hitz, S.,
Mueller, P., and A. Perrig, "The Complete Guide to SCION",
ISBN 978-3-031-05287-3, 2022,
<https://doi.org/10.1007/978-3-031-05288-0>.
[ISD-AS-assignments]
"SCION Registry", 2026, <http://scion.org/registry/>.
[RFC8210] Bush, R. and R. Austein, "The Resource Public Key
Infrastructure (RPKI) to Router Protocol, Version 1",
RFC 8210, DOI 10.17487/RFC8210, September 2017,
<https://www.rfc-editor.org/rfc/rfc8210>.
Appendix A. Certificate Extensions in ASN.1 Syntax
de Kater, et al. Expires 22 October 2026 [Page 54]
Internet-Draft SCION CP-PKI April 2026
SCION-CP-PKI-CERT-EXTENSIONS {
iso(1) identified-organization(3) dod(6) internet(1) private(4)
enterprise(1) scion(55324) module(0) id-scion-pki-cert-ext(101)
}
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- Root SCION object identifier (IANA Private Enterprise Number 55324)
id-scion OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 55324 }
-- SCION Control Plane PKI
id-cppki OBJECT IDENTIFIER ::= { id-scion 1 }
-- SCION ISD-AS Attribute
id-at-ia AttributeType ::= {id-scion id-cppki(1) id-at(2) 1}
-- SCION Key Purposes
id-scion-kp OBJECT IDENTIFIER ::= { id-cppki 3 }
-- Identifies a Sensitive voting certificate
id-kp-sensitive OBJECT IDENTIFIER ::= { id-scion-kp 1 }
-- Identifies a Regular voting certificate
id-kp-regular OBJECT IDENTIFIER ::= { id-scion-kp 2 }
-- Identifies a Root certificate
id-kp-root OBJECT IDENTIFIER ::= { id-scion-kp 3 }
END
Appendix B. TRC in ASN.1 Syntax
SCION-CP-PKI-TRC {
iso(1) identified-organization(3) dod(6) internet(1) private(4)
enterprise(1) scion(55324) module(0) trc(1)
}
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
IMPORTS
Certificate
FROM PKIX1Explicit88 {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18)
};
de Kater, et al. Expires 22 October 2026 [Page 55]
Internet-Draft SCION CP-PKI April 2026
TRCValidity ::= SEQUENCE {
notBefore GeneralizedTime,
notAfter GeneralizedTime
}
TRCPayload ::= SEQUENCE {
version TRCFormatVersion,
iD TRCID,
validity TRCValidity,
gracePeriod INTEGER,
noTrustReset BOOLEAN,
votes SEQUENCE SIZE (0..2047) OF INTEGER (0..4095),
votingQuorum INTEGER (1..2047),
coreASes SEQUENCE OF ASN,
authoritativeASes SEQUENCE OF ASN,
description UTF8String (SIZE (0..8192)),
certificates SEQUENCE SIZE (0..4095) OF Certificate
}
TRCFormatVersion ::= INTEGER { v1(0) }
TRCID ::= SEQUENCE {
iSD ISD,
serialNumber INTEGER (1..MAX),
baseNumber INTEGER (1..MAX)
}
ISD ::= INTEGER (1..65535)
ASN ::= PrintableString
END
Appendix C. Signing Ceremony Initial TRC
A Signing Ceremony is used to create the initial (first) Trust Root
Configuration of an ISD. Each ISD may decide how to conduct this
ceremony, but it is RECOMMENDED to establish a procedure similar to
the one described below:
C.1. Ceremony Participants
The Signing Ceremony SHOULD include the following participants:
de Kater, et al. Expires 22 October 2026 [Page 56]
Internet-Draft SCION CP-PKI April 2026
* *Ceremony Administrator* - an individual in charge of moderating
the signing process, guiding the participants through the steps,
and acting as an intermediary for sharing information. The
Ceremony Administrator is typically appointed by the ISD Manager
or by resolution of the Voting ASes.
* *Voting AS Representatives* - individuals representing each Voting
AS who are able to create voting signatures on the TRC. They are
in possession of a device with the private keys of their
respective certificates in the TRC.
* *Witness(es)* - individual(s) who have no active role in the
Signing Ceremony but may stop the process and request more
information if they feel its integrity may have been compromised.
The Witness(es) are typically appointed by resolution of the
Voting ASes.
*Note:* The ISD members MUST decide on the roles of the Signing
Ceremony participants in advance of Signing Ceremony, and MUST have
reached agreement about the Certificate Authority (CA) ASes (that
will also issue the root certificates). It is assumed that all
parties are trustworthy and issues encountered during the Signing
Ceremony may be assumed to be caused by honest mistakes and not by
malicious intent. Hash comparison checks are included to counter
mistakes and so that every participant can ensure they are operating
on the same data, and the private keys of each participant never
leave their machine. The Ceremony Administrator does not have to be
entrusted with private keys.
C.2. Ceremony Preparations
The participants MUST decide in advance on the physical location of
the Signing Ceremony, the devices that will be used, and the ISD
policy as follows:
* ISD number - usually obtained from the SCION registry, see
Section 3.2.2;
* The description of the TRC, see Section 3.2.10;
* Validity period of the TRC, see Section 3.2.3;
* Grace period of the TRC (except for Base TRCs);
* Voting quorum for the TRC, see Section 3.2.7;
* AS numbers of the Core ASes, see Section 3.2.8;
de Kater, et al. Expires 22 October 2026 [Page 57]
Internet-Draft SCION CP-PKI April 2026
* AS numbers of the Authoritative ASes, see Section 3.2.9;
* The list of Control Plane Root Certificates.
Each representative of a Voting AS MUST also create the following
before the ceremony:
* A sensitive voting private key and a self-signed certificate
containing the corresponding public key.
* A regular voting private key and a self-signed certificate
containing the corresponding public key.
In addition, each Certificate Authority MUST create a control plane
root private key and a self-signed certificate containing the
corresponding public key. A representative of the Certificate
Authority need not be present at the ceremony as they do not need to
sign the TRC, but they MUST provide their root certificate to be
shared at the ceremony. The validity period of the certificates
generated in advance MUST cover the full TRC validity period.
The location MUST provide electricity and power sockets for each
participant, and should provide a monitor or projector that allows
the Ceremony Administrator to display proceedings.
The Ceremony Administrator and Voting ASes MUST each bring to the
Signing Ceremony a secure machine capable of signing and verifying
TRCs and computing the SHA-512 digest of the files. For voting ASes,
the machine requires access to their own sensitive and regular voting
private keys.
The Ceremony Administrator MUST provide or be provided with a device
to exchange data between the ceremony participants.
The Signing Ceremony SHOULD include a procedure to verify that all
devices are secure.
C.3. Ceremony Phases
The number of Voting ASes present at the Signing Ceremony must be
equal to or larger than the specified voting quorum.
The signing process has four phases of data sharing, led by the
Ceremony Administrator who provides instructions to the other
participants:
de Kater, et al. Expires 22 October 2026 [Page 58]
Internet-Draft SCION CP-PKI April 2026
C.3.1. Certificate Exchange
All parties share the certificates that must be part of the TRC with
the Ceremony Administrator. For the Voting ASes, these are the
sensitive and the regular voting certificates, and for the
Certificate Authority these are the Control Plane root certificates.
Each representative copies the requested certificates from their
machine onto a data exchange device provided by the Ceremony
Administrator that is passed between all representatives, before
being returned to the Ceremony Administrator. Representatives MUST
NOT copy the corresponding private keys onto the data exchange device
as this invalidates the security of the ceremony.
The Ceremony Administrator then checks that the validity period of
each provided certificate covers the previously agreed upon TRC
validity, that the signature algorithms are correct, and that the
certificate type is valid (root, sensitive voting or regular voting
certificate). If these parameters are correct, the Ceremony
Administrator computes the SHA-512 hash value for each certificate,
aggregates and bundles all the provided certificates, and finally
calculates the SHA-512 hash value for the entire bundle. All hash
values must be displayed to the participants.
The Ceremony Administrator MUST then share the bundle with the
representatives of the voting ASes who MUST validate on their machine
that the hash value of their certificates and that of the bundled
certificates is the same as displayed by the Ceremony Administrator.
This phase concludes when every representative has confirmed the
SHA-512 sums are correct. If there is any mismatch then this phase
MUST be repeated.
C.3.2. Generation of the TRC Payload
The Ceremony Administrator generates the TRC payload based on the
bundled certificates and the Section 3.2 completed in accordance with
ISD policy, see Appendix C.2.
For each bundled certificate, the voting representatives MUST then
verify the certificate type and that the following fields contain the
correct information:
* issuer
* subject
* validity
de Kater, et al. Expires 22 October 2026 [Page 59]
Internet-Draft SCION CP-PKI April 2026
* signature
Once the voting representatives have verified the TRC data, the
Ceremony Administrator computes the DER encoding of the data
according to Appendix B and the SHA-512 hash value of the TRC payload
file. The TRC payload file is then shared with the voting
representatives via the data exchange device who verify the TRC
payload hash value by computing this on their machine and checking it
matches the one displayed by the Ceremony Administrator.
This phase concludes when all voting representatives confirm that the
contents of the TRC payload are correct.
C.3.3. TRC Signing
Each voting representative attaches a signature created with their
own private voting key to the TRC (payload file), using their own
machine. This serves to prove possession of the private keys.
This phase concludes when all voting representatives have attached
their signatures to the TRC.
C.3.4. TRC Validation
All voting representatives copy the TRC payload signed with their
private voting keys to the data exchange device and return this to
the Ceremony Administrator. The Ceremony Administrator assembles the
final TRC by aggregating the payload data and verifying the
signatures based on the certificates exchanged during phase
Appendix C.3.1. The Ceremony Administrator then shares the assembled
TRC with all participants who MUST again inspect the signatures and
verify them based on the certificates exchanged in phase
Appendix C.3.1.
The Signing Ceremony is completed once when every voting
representative confirms that the signatures match. All participants
can then use the TRC to distribute trust anchors for the ISD.
Change Log
Changes made to drafts since ISE submission. This section is to be
removed before publication.
draft-dekater-scion-pki-12
* Overall review and wording polish
* Introduction: shorten and refer to -controlplane
de Kater, et al. Expires 22 October 2026 [Page 60]
Internet-Draft SCION CP-PKI April 2026
* Consistently use "Issuing CA certificate" / root certificate"
* Sections 2 and 3 (Certificate, TRC specification): reduce number
of subheadings, reword TRC field descriptions. - Clarify that TRC
validity uses GeneralizedTime
* Add ASN.1 modules in the appendix for Certificate extensions and
TRCs
* Tables 3-7: sharpen normative language use
draft-dekater-scion-pki-11
* Signing ceremony: minor updates to align with current process
* Signature field: clarify implications of using other algorithms or
curves and mention mti set may be updated in future protocol
iterations
* Clarify distinction between SCION ASes and BGP ASes through the
text.
* Intro: remove duplicated motivation and component description and
add a reference to the same text in -controlplane
* Clarify that initial AS certificates may have a longer validity to
allow enough time for deployment
* "SCION-Specific Constraints and Conditions" section: drop
requirement to use "UTF8String" for all fields, allow use of
GeneralizedTime to align with RFC5280
* Security considerations: move and reword section "Dependency on
Certificates" to new section "Deployment Considerations"
* Security considerations: new section on TRC Distribution
* Remove informative reference to I-D.dekater-panrg-scion-overview
and to Anapaya's ISD assignments, since they are taken over by
SCION Association in 2026. Remove unused references to RFC5398
and RFC6996.
draft-dekater-scion-pki-10
* removed ISD assignment table and replaced to reference in Control
Plane draft
* Updated number assignment reference
de Kater, et al. Expires 22 October 2026 [Page 61]
Internet-Draft SCION CP-PKI April 2026
* Signatures: mention that other algorithms that ECDSA may be used
in the future
* Figures: add SVG version
draft-dekater-scion-pki-09
* Signing ceremony and introduction - improved text
* Clarified why a CA must have an ISD-AS number assigned
* Mention Active Discovery as a TRC discovery mechanism
* Abstract: mention goal and that document is not an Internet
Standard
draft-dekater-scion-pki-08
* Fix some oversized diagrams
* Introduction text rewording
draft-dekater-scion-pki-07
Minor changes:
* Clarified relationship with RPKI.
* Added this changelog
* General text editing
* References: fixed ITU, ANSI, Assigned ISD-AS, fixed cross-
reference to text formatting in the CP draft
draft-dekater-scion-pki-06
Major changes:
* Added overview of SCION components to Introduction section.
Minor changes:
* General edits to make terminology consistent, remove duplication
and rationalize text.
* Removed forward references.
de Kater, et al. Expires 22 October 2026 [Page 62]
Internet-Draft SCION CP-PKI April 2026
* Added RFC2119 compliant terminology.
Acknowledgments
Many thanks go to Fritz Steinmann (SIX Group AG), Juan A. Garcia
Prado (ETH Zurich), Russ Housley (IETF), Brian Trammell (Google),
Ramon Keller (LibC Technologies), Patrick Ambord (independent),
Dominik Roos (Anapaya), and Kevin Meynell (SCION Association) 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.
Authors' Addresses
Corine de Kater
SCION Association
Email: c_de_kater@gmx.ch
Nicola Rustignoli
SCION Association
Email: nic@scion.org
Samuel Hitz
Anapaya Systems
Email: hitz@anapaya.net
de Kater, et al. Expires 22 October 2026 [Page 63]