SCION Control Plane PKI
draft-dekater-scion-pki-13
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-06-05 | ||
| 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-13
Network Working Group C. de Kater
Internet-Draft N. Rustignoli
Intended status: Informational SCION Association
Expires: 7 December 2026 S. Hitz
Anapaya Systems
5 June 2026
SCION Control Plane PKI
draft-dekater-scion-pki-13
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 7 December 2026 [Page 1]
Internet-Draft SCION CP-PKI June 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 7 December 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 . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Trust Relations within an Isolation Domain . . . . . . . 8
1.4.1. Updates and Trust Resets . . . . . . . . . . . . . . 8
1.4.2. Substitutes to Certificate Revocation . . . . . . . . 9
1.5. Overview of Certificates, Keys, and Roles . . . . . . . . 9
2. Certificate Specification . . . . . . . . . . . . . . . . . . 11
2.1. Control Plane Root Certificate . . . . . . . . . . . . . 11
2.2. Control Plane Issuing CA Certificate . . . . . . . . . . 12
2.3. Control Plane AS Certificate . . . . . . . . . . . . . . 12
2.4. Voting Certificates . . . . . . . . . . . . . . . . . . . 13
2.5. Key Pairs Overview and Notations . . . . . . . . . . . . 13
2.6. X.509 Certificate Profiles and Constraints . . . . . . . 16
2.6.1. version . . . . . . . . . . . . . . . . . . . . . . . 16
2.6.2. serialNumber . . . . . . . . . . . . . . . . . . . . 16
2.6.3. signature . . . . . . . . . . . . . . . . . . . . . . 17
de Kater, et al. Expires 7 December 2026 [Page 2]
Internet-Draft SCION CP-PKI June 2026
2.6.4. issuer . . . . . . . . . . . . . . . . . . . . . . . 17
2.6.5. validity . . . . . . . . . . . . . . . . . . . . . . 18
2.6.6. subject . . . . . . . . . . . . . . . . . . . . . . . 18
2.6.7. subjectPublicKeyInfo . . . . . . . . . . . . . . . . 18
2.6.8. Unique Identifiers . . . . . . . . . . . . . . . . . 19
2.7. Extensions . . . . . . . . . . . . . . . . . . . . . . . 19
2.7.1. authorityKeyIdentifier Extension . . . . . . . . . . 19
2.7.2. subjectKeyIdentifier Extension . . . . . . . . . . . 20
2.7.3. keyUsage Extension . . . . . . . . . . . . . . . . . 20
2.7.4. extKeyUsage Extension . . . . . . . . . . . . . . . . 21
2.7.5. basicConstraints Extension . . . . . . . . . . . . . 24
3. Trust Root Configuration Specification . . . . . . . . . . . 25
3.1. TRC Types and States . . . . . . . . . . . . . . . . . . 26
3.2. TRC Fields . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.1. version . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.2. iD . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.3. validity . . . . . . . . . . . . . . . . . . . . . . 28
3.2.4. gracePeriod . . . . . . . . . . . . . . . . . . . . . 28
3.2.5. noTrustReset . . . . . . . . . . . . . . . . . . . . 29
3.2.6. votes . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.7. votingQuorum . . . . . . . . . . . . . . . . . . . . 30
3.2.8. coreASes . . . . . . . . . . . . . . . . . . . . . . 30
3.2.9. authoritativeASes . . . . . . . . . . . . . . . . . . 30
3.2.10. description . . . . . . . . . . . . . . . . . . . . . 31
3.2.11. certificates . . . . . . . . . . . . . . . . . . . . 31
3.2.12. localizedDescriptions . . . . . . . . . . . . . . . . 32
3.2.13. descriptionLanguage . . . . . . . . . . . . . . . . . 32
3.3. TRC Signature Syntax . . . . . . . . . . . . . . . . . . 33
3.3.1. SCION-specific rules . . . . . . . . . . . . . . . . 33
3.3.2. TRC Equality . . . . . . . . . . . . . . . . . . . . 34
3.4. Certification Path - Trust Anchor Pool . . . . . . . . . 34
3.5. TRC Updates . . . . . . . . . . . . . . . . . . . . . . . 35
3.5.1. Changed or New Certificates . . . . . . . . . . . . . 35
3.5.2. Update Rules - Overview . . . . . . . . . . . . . . . 36
3.5.3. General Update Rules . . . . . . . . . . . . . . . . 38
3.5.4. Regular TRC Update . . . . . . . . . . . . . . . . . 38
3.5.5. Sensitive TRC Update . . . . . . . . . . . . . . . . 39
3.5.6. Signing a TRC Update . . . . . . . . . . . . . . . . 39
3.5.7. TRC Update Verification . . . . . . . . . . . . . . . 40
3.6. Trust Reset . . . . . . . . . . . . . . . . . . . . . . . 40
3.7. Initial TRC Signing Ceremony . . . . . . . . . . . . . . 41
4. CP-PKI Operations . . . . . . . . . . . . . . . . . . . . . . 41
4.1. Distribution of TRCs . . . . . . . . . . . . . . . . . . 41
4.1.1. Base TRC . . . . . . . . . . . . . . . . . . . . . . 41
4.1.2. TRC Update Discovery . . . . . . . . . . . . . . . . 42
4.2. Signing and Verifying Control Plane Messages . . . . . . 43
4.2.1. Signing a Control Plane Message . . . . . . . . . . . 43
4.2.2. Verifying a Control Plane Message . . . . . . . . . . 43
de Kater, et al. Expires 7 December 2026 [Page 3]
Internet-Draft SCION CP-PKI June 2026
4.3. Issuing Control Plane AS Certificates . . . . . . . . . . 45
5. Deployment Considerations . . . . . . . . . . . . . . . . . . 46
5.1. PKI Availability . . . . . . . . . . . . . . . . . . . . 46
5.2. Operational Processes for ISD Governance . . . . . . . . 46
6. Security Considerations . . . . . . . . . . . . . . . . . . . 47
6.1. Compromise of an ISD . . . . . . . . . . . . . . . . . . 47
6.1.1. Recovery from Compromise . . . . . . . . . . . . . . 48
6.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 48
6.3. TRC Distribution and Trust on First Use . . . . . . . . . 49
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 49
8.1. Normative References . . . . . . . . . . . . . . . . . . 49
8.2. Informative References . . . . . . . . . . . . . . . . . 51
Appendix A. Certificate Extensions in ASN.1 Syntax . . . . . . . 52
Appendix B. TRC in ASN.1 Syntax . . . . . . . . . . . . . . . . 53
Appendix C. Signing Ceremony Initial TRC . . . . . . . . . . . . 55
C.1. Ceremony Participants . . . . . . . . . . . . . . . . . 55
C.2. Ceremony Preparations . . . . . . . . . . . . . . . . . . 55
C.3. Ceremony Phases . . . . . . . . . . . . . . . . . . . . 56
C.3.1. Certificate Exchange . . . . . . . . . . . . . . . . 57
C.3.2. Generation of the TRC Payload . . . . . . . . . . . . 57
C.3.3. TRC Signing . . . . . . . . . . . . . . . . . . . . . 58
C.3.4. TRC Validation . . . . . . . . . . . . . . . . . . . 58
Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
draft-dekater-scion-pki-13 . . . . . . . . . . . . . . . . . . 59
draft-dekater-scion-pki-12 . . . . . . . . . . . . . . . . . . 60
draft-dekater-scion-pki-11 . . . . . . . . . . . . . . . . . . 60
draft-dekater-scion-pki-10 . . . . . . . . . . . . . . . . . . 61
draft-dekater-scion-pki-09 . . . . . . . . . . . . . . . . . . 61
draft-dekater-scion-pki-08 . . . . . . . . . . . . . . . . . . 61
draft-dekater-scion-pki-07 . . . . . . . . . . . . . . . . . . 61
draft-dekater-scion-pki-06 . . . . . . . . . . . . . . . . . . 62
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 62
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62
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:
_PKI_ - providing cryptographic material within an unique trust
model. It is described in this document.
de Kater, et al. Expires 7 December 2026 [Page 4]
Internet-Draft SCION CP-PKI June 2026
_Control Plane_ (CP) - 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
*Authoritative AS*: Authoritative ASes are those ASes in an ISD that
always have the latest TRC of the ISD. As a consequence,
Authoritative ASes also start the announcement of a TRC update.
*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.
*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. ISD
operators 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.
*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.
*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 has at
least one Core AS.
*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).
de Kater, et al. Expires 7 December 2026 [Page 5]
Internet-Draft SCION CP-PKI June 2026
*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.
*Trust Reset*: A trust reset is the action of creating and announcing
a new base TRC for an existing ISD, to mitigate a compromised TRC.
*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.
*Voters*: Those parties 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.
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.
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].
de Kater, et al. Expires 7 December 2026 [Page 6]
Internet-Draft SCION CP-PKI June 2026
The monopoly model requires global consensus on a single root of
trust, which introduces a single point of failure. The oligopoly
model, conversely, utilizes multiple roots of trust that are
typically afforded equal authority, introducing multiple potential
points of vulnerability, as the compromise of any individual root can
undermine the security of the broader ecosystem.
The SCION trust architecture allows parties that mutually trust each
other to form their own trust domain, and to freely decide which
other trust domains should be trusted. It therefore provides 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.
To fulfill these requirements, 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 *Voters*. Furthermore, each ISD
has a set of ASes that form the ISD core, known as the *Core ASes*.
The set of Core ASes and Voters may be but do not necessarily have to
be the same entities, since Voters do not require an AS number.
Governance is implemented by a policy called the *Trust Root
Configuration* (TRC), which is negotiated by the Voters 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. An
ISD's TRC is used for signatures pertaining to information
originating from that ISD, such as paths, but for nothing originating
outside of the ISD. This ISD-level scoping of trust roots enhances
security by strictly limiting effect of a compromise to data
originating from the compromised AS. An ISD's trust roots and policy
are encoded in the TRC, which has a base and serial 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
de Kater, et al. Expires 7 December 2026 [Page 7]
Internet-Draft SCION CP-PKI June 2026
TRCs. The TRC serves as a way to bootstrap all authentication within
SCION. Additionally, TRC versioning is used as an alternative to
revocation in case of compromised roots of trust.
The TRC also provides _trust agility_ by enabling relying parties
(endpoints and ASes) to select the trust roots used to initiate
certificate validation. For endpoints, this implies users can choose
trusted ISDs when verifying path segments. For ASes, this implies
they can choose trusted ISDs for beaconing, thereby establishing
transparent trust relationships between parts of the network. The
SCION trust model therefore, differs from the one provided by other
PKI architectures.
To achieve trust agility, SCION avoids global PKIs such as the RPKI
[RFC8210] where trust roots are provided by the Regional Internet
Registries. Instead, in the CP-PKI, each ISD has its own trust root.
Note that SCION does not provide IP prefix origin validation.
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 Voters and then distributed throughout the ISD.
While it is not necessary that all the ASes of the ISD trust each
other, within the CP-PKI all ASes implicitly trust the ISD's Voters,
as well as its CA(s).
1.4.1. Updates and Trust Resets
There are two types of TRC updates: regular and sensitive. The
update type depends on which fields are changed (see Section 3.5).
In both cases the base TRC remains unchanged. Authoritative ASes
announce these TRC updates (see Section 3.2.9).
In case the TRC has been compromised, it may be re-established
through a process called trust reset (see Section 3.6). In this
case, a new base TRC is created.
de Kater, et al. Expires 7 December 2026 [Page 8]
Internet-Draft SCION CP-PKI June 2026
1.4.2. Substitutes to Certificate Revocation
The Control Plane PKI does not explicitly support certificate
revocation. Instead it relies on the TRC update mechanism, on trust
resets, and on short-lived certificates. This approach constitutes
an alternative to a revocation system for the following reasons:
* 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 [RFC5280] and
OCSP [RFC6960] 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
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 7 December 2026 [Page 9]
Internet-Draft SCION CP-PKI June 2026
+----------------------------------------+
| TRC 2 (SerialNumber=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. The TRC number (e.g.,
TRC 1) refers to the TRC's serialNumber.
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
de Kater, et al. Expires 7 December 2026 [Page 10]
Internet-Draft SCION CP-PKI June 2026
public keys of voting certificates must therefore be explicitly
verified during the Signing Ceremony (Appendix C) that is used to
bootstrap trust for the initial TRC.
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.
* *Voters*: They may sign TRC updates. The process of appending a
signature to a new TRC is called "casting a vote", and the
designated "Voters" hold the private keys to sign a TRC update.
* *Authoritative ASes*: They always have the latest TRCs of the ISD.
They start the announcement of a TRC update.
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].
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.
2.1. Control Plane Root Certificate
The private key of the control plane root (CP 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 Issuing CAs in an ISD.
de Kater, et al. Expires 7 December 2026 [Page 11]
Internet-Draft SCION CP-PKI June 2026
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. They are embedded in the TRC of an ISD,
and they act as the starting point of an ISD's certificate
verification path.
The RECOMMENDED maximum validity period of a control plane root
certificate is 5 years.
*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.2. 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.
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 15 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.3. 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.
de Kater, et al. Expires 7 December 2026 [Page 12]
Internet-Draft SCION CP-PKI June 2026
The RECOMMENDED maximum validity period of a CP AS certificate is 3
days. AS operators are advised to renew these certificates by a
margin of at least their configured Hop Field expiration time, as
described in the "AS Entry Signature" section of
[I-D.dekater-scion-controlplane].
2.4. Voting Certificates
There are two types of voting certificates: regular voting
certificates and 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.
The distinction between regular and sensitive updates is described in
Section 3.5.
Voting certificates may be used to cast votes in a TRC updates. In
X.509 terms, voting certificates are self-signed end entity
certificates. This means that the issuer and subject of a voting
certificate are the same entity, and the public key within the
certificate can be used to verify the certificate's signature.
However, a voting certificate cannot be used to verify other
certificates.
The RECOMMENDED maximum validity period of a voting certificate is 5
years.
2.5. Key Pairs Overview and Notations
Table 1 and Table 2 below provide an overview of certificates and
corresponding key pairs.
de Kater, et al. Expires 7 December 2026 [Page 13]
Internet-Draft SCION CP-PKI June 2026
+======================+==============+============================+
| 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
+==============+==========+============+=================+==========+
| 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 | 5 years |
| voting | | | | |
| cert. | | | | |
+--------------+----------+------------+-----------------+----------+
| CP root | C_root | SK_root | PK_root | 5 years |
| certificate | | | | |
+--------------+----------+------------+-----------------+----------+
| CP issuing | C_CA | SK_root | PK_CA | 15 days |
| CA | | | | (3) |
| certificate | | | | |
+--------------+----------+------------+-----------------+----------+
| CP AS | C_AS | SK_CA | PK_AS | 3 days |
| certificate | | | | |
+--------------+----------+------------+-----------------+----------+
Table 2: Certificates
de Kater, et al. Expires 7 December 2026 [Page 14]
Internet-Draft SCION CP-PKI June 2026
(1) A TRC may include multiple certificates of each type.
(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 15 days with 8 days overlap between two issuing CA
certificates is RECOMMENDED to enable the best possible operational
procedures when performing an 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 (SerialNumber=1) |
| (base/initial) |
| +------------------------------------------+ |
| | - Version - Core ASes | |
| | - ID - Description | |
| | - 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 | |
| | | |
de Kater, et al. Expires 7 December 2026 [Page 15]
Internet-Draft SCION CP-PKI June 2026
| | +-----+ +-----+ +-----+ +-----+ | |
| | | (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|
+-----------+ +-----------+
Figure 2: TRC and the different types of associated certificates.
Arrows indicate the certificate hierarchy.
2.6. X.509 Certificate Profiles and Constraints
Control Plane PKI certificates are X.509 v3 certificate with
additional constraints applied. 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.6.1. version
The version field describes the X.509 version of the encoded
certificate. It MUST be set to "v3" because X.509 extensions are
required.
2.6.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.
de Kater, et al. Expires 7 December 2026 [Page 16]
Internet-Draft SCION CP-PKI June 2026
2.6.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]
and 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])
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.6.4. issuer
The issuer field contains the distinguished name (DN) of the entity
that issued and signed the certificate (usually a CA). This field
MUST NOT be empty.
de Kater, et al. Expires 7 December 2026 [Page 17]
Internet-Draft SCION CP-PKI June 2026
In addition to the attributes described in section 4.1.2.4 [RFC5280],
SCION implementations MUST also support the SCION-specific id-at-ia
attribute.
2.6.4.1. id-at-ia Attribute
The id-at-ia attribute identifies the SCION ISD and AS numbers. It
is is included in an AttributeTypeAndValue sequence where the type is
id-at-ia and value contains the ISD-AS number string. Its formatting
MUST follow [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.
The id-at-ia object identifier is defined in Appendix A.
The id-at-ia attribute MUST be included in the issuer and subject
fields of root, issuing CA, and AS certificates. It SHOULD be
included in voting certificates.
When present, the id-at-ia attribute MUST appear exactly once in a
given distinguished name (DN), and implementations MUST reject
certificates if the id-at-ia appears more than once.
2.6.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.5. SCION deployments SHOULD adopt these
values.
2.6.6. subject
The subject field defines the entity that owns the certificate. It
MUST NOT be empty. In addition to the attributes described in
section 4.1.2.6 [RFC5280], SCION implementations MUST also support
the SCION-specific id-at-ia attribute, see Section 2.6.4.1.
2.6.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.
de Kater, et al. Expires 7 December 2026 [Page 18]
Internet-Draft SCION CP-PKI June 2026
2.6.8. Unique Identifiers
The issuerUniqueID and subjectUniqueID fields MUST NOT be used
according to [RFC5280] section 4.1.2.8.
2.7. 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
* subjectKeyIdentifier
* keyUsage
* extKeyUsage
* basicConstraints
The following sections describe the SCION-specifics in regard to
these extensions.
2.7.1. authorityKeyIdentifier Extension
The authorityKeyIdentifier extension identifies the public key
corresponding to the private key used to sign a certificate. For its
syntax and definition, see [RFC5280], section 4.2.1.1, and [X.509],
clause 9.2.2.1.
To ensure deterministic matching, the authorityKeyIdentifier
attributes are strictly restricted:
* keyIdentifier: MUST be included.
* authorityCertIssuer & authorityCertSerialNumber: MUST NOT be
included. Implementations MUST return an error if either is
present.
This extension MUST be marked as non-critical as per [RFC5280]
section 4.2. Implementations MUST return an error if the extension
is not present AND the certificate is not self-signed.
de Kater, et al. Expires 7 December 2026 [Page 19]
Internet-Draft SCION CP-PKI June 2026
2.7.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.
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.7.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.
When a relying party uses the certificate’s public key to verify the
signature of a control plane payload (digitalSignature attribute),
the relying party traces back the private key used to sign the
certificate by referencing the ISD-AS and the subject key identifier
(via the subjectKeyIdentifier extension). For more information about
the subjectKeyIdentifier extension (see Section 2.7.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 7 December 2026 [Page 20]
Internet-Draft SCION CP-PKI June 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.7.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 7 December 2026 [Page 21]
Internet-Draft SCION CP-PKI June 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 7 December 2026 [Page 22]
Internet-Draft SCION CP-PKI June 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.7.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 7 December 2026 [Page 23]
Internet-Draft SCION CP-PKI June 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.7.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.7.5. basicConstraints Extension
The basicConstraints extension specifies whether the certificate
subject acts 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 acts 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 7 December 2026 [Page 24]
Internet-Draft SCION CP-PKI June 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 | MUST be | MUST be | MUST NOT | MUST NOT |
| | set to | set to | be | be |
| | "1" | "0" (1) | included | included |
+-------------------+----------+----------+-----------+------------+
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.7.
The TRC contains a signed collection of [X.509] v3 certificates and
ISD-specific policies. Encoding for the purpose of signature
calculation is described in Section 3.3.
de Kater, et al. Expires 7 December 2026 [Page 25]
Internet-Draft SCION CP-PKI June 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 3.6). 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.
* Invalid: The TRC is considered invalid if the current time falls
outside its validity period.
Figure 2 shows the content of both a base/initial TRC. All elements
of the TRC are detailed in the following subsections.
de Kater, et al. Expires 7 December 2026 [Page 26]
Internet-Draft SCION CP-PKI June 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.
Although the ASN.1 schema permits larger structures, the total TRC
size SHOULD NOT exceed 4 MB. 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 these attributes:
* iSD: ISD number.
* baseNumber: The base number indicates the starting point of the
current TRC update chain. This starting point is the currently
valid base TRC, which may differ from the initial TRC in the case
of a trust reset.
* serialNumber: The TRC serial number 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. Table 6 shows an example of a TRC update chain.
If a trust reset is necessary, a new base TRC is announced in order
to start a new and clean TRC update chain. The base number of this
new TRC update chain SHOULD be the number following the serial number
of the latest TRC that was produced by a non-compromised TRC update
for this ISD. The trust reset process is described in Section 3.6.
de Kater, et al. Expires 7 December 2026 [Page 27]
Internet-Draft SCION CP-PKI June 2026
+=============+=====+============+==============+
| Update | iSD | baseNumber | serialNumber |
+=============+=====+============+==============+
| Initial | 15 | 1 | 1 |
+-------------+-----+------------+--------------+
| Regular | 15 | 1 | 2 |
+-------------+-----+------------+--------------+
| Regular | 15 | 1 | 3 |
+-------------+-----+------------+--------------+
| Sensitive | 15 | 1 | 4 |
+-------------+-----+------------+--------------+
| Trust reset | 15 | *5* | 5 |
+-------------+-----+------------+--------------+
| Regular | 15 | 5 | 6 |
+-------------+-----+------------+--------------+
Table 6: Example of the attributes contained
in `iD` through a TRC update chain for ISD
15. Note that the base number is only
changed in case of a trust reset, where the
new base number follows the serial number "4
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 reject such a TRC.
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:
de Kater, et al. Expires 7 December 2026 [Page 28]
Internet-Draft SCION CP-PKI June 2026
* the grace period expires;
* the predecessor TRC reaches its expiration time (notAfter);
* 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 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. The trust reset process is described in Section 3.6.
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.
The index is 0-based, meaning that 0 represents the first element.
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.
de Kater, et al. Expires 7 December 2026 [Page 29]
Internet-Draft SCION CP-PKI June 2026
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. A voting quorum lower than the
number of Voters ensures that votes can be cast even if some of the
voters are unavailable.
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
Authoritative ASes are those ASes in an ISD that always possess the
latest TRCs for the ISD and therefore initiate TRC update
announcements. They are provisioned with the latest TRC by Voters
following an update (see Section 3.5.3). Every Authoritative AS MUST
be a Core AS (i.e., be listed in the coreASes field).
The authoritativeASes field contains a sequence listing the
Authoritative AS numbers in the ISD. 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.
de Kater, et al. Expires 7 December 2026 [Page 30]
Internet-Draft SCION CP-PKI June 2026
3.2.10. description
The description field contains a UTF-8 encoded string that describes
the ISD. The text MUST be formatted in accordance with "Net-Unicode"
[RFC5198] to ensure consistent normalization. When this field
contains a language other than English, the corresponding language
SHOULD be identified explicitly in the descriptionLanguage field (see
()[#langtag]).
Multi-language TRCs SHOULD use the localizedDescriptions field
instead of the description field. Either the description or the
localizedDescriptionsfield MUST be present and not be empty.
3.2.11. certificates
The Voters 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 control plane root certificate.
A certificate that is not a 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.7.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 7 December 2026 [Page 31]
Internet-Draft SCION CP-PKI June 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.2.12. localizedDescriptions
The localizedDescriptions field provides an optional mechanism for
including multilingual descriptions. It consists of a sequence of
LocalizedText structures, each containing:
* language: specifies the description's language. It MUST contain a
valid language tag according to [BCP47].
* content: contains the localized description. It MUST be formatted
in accordance with "Net-Unicode" [RFC5198].
3.2.13. descriptionLanguage
The OPTIONAL descriptionLanguage field identifies the language used
to express the description field. When descriptionLanguage is
absent, English (equivalent to the "en" language tag) is used. The
value of the descriptionLanguage MUST be a valid language tag as
described in [BCP47].
de Kater, et al. Expires 7 December 2026 [Page 32]
Internet-Draft SCION CP-PKI June 2026
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 SignedData 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:
- 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]).
de Kater, et al. Expires 7 December 2026 [Page 33]
Internet-Draft SCION CP-PKI June 2026
- 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.6.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.*
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. While root certificates for a given
ISD are distributed via the TRC, AS and issuing CA certificates are
distributed separately. 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 validate a certification path, a relying party builds a collection
of root certificates known as the trust anchor pool. Because TRC
updates can introduce a grace period where multiple TRCs overlap,
relying parties MUST execute the following steps to determine the
correct trust anchor pool for a given verification time:
de Kater, et al. Expires 7 December 2026 [Page 34]
Internet-Draft SCION CP-PKI June 2026
1. From the set of all available TRCs for the ISD, keep only TRCs
whose validity start time (notBefore date) is at or before the
verification time. If no such TRC exists, the process terminates
unsuccessfully.
2. From the selected TRCs, identify those with the highest base
number (baseNumber), then select the TRC among them with the
highest serial number (serialNumber).
3. If the verification time is strictly greater than the selected
TRC's notAfter date then the process terminates unsuccessfully.
4. If the TRC is valid, add its root certificates to the trust
anchor pool.
5. If the TRC is in its grace period, add the preceding TRC's root
certificates to the trust anchor pool.
Note that any entity sending information 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.
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.
3.5.1. Changed or New Certificates
In the context of a TRC update,
de Kater, et al. Expires 7 December 2026 [Page 35]
Internet-Draft SCION CP-PKI June 2026
* 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 7 December 2026 [Page 36]
Internet-Draft SCION CP-PKI June 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 7 December 2026 [Page 37]
Internet-Draft SCION CP-PKI June 2026
3.5.3. General Update Rules
The following rules 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.
* Voters SHOULD distribute the updated TRC to all Authoritative ASes
within the ISD. The distribution mechanism is typically out of
band and it is outside of the scope of this document.
Discovery mechanisms for new TRCs are described in Section 4.1.2.
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 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.
de Kater, et al. Expires 7 December 2026 [Page 38]
Internet-Draft SCION CP-PKI June 2026
- The number of sensitive and regular voting certificates as well
as control plane root certificates included in the certificates
field and their distinguished names.
- 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
de Kater, et al. Expires 7 December 2026 [Page 39]
Internet-Draft SCION CP-PKI June 2026
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.
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 MUST be rejected.
3.6. Trust Reset
A trust reset is a process that results in the creation of a new base
TRC. It is only permitted if the noTrustReset field of the active
TRC is set to FALSE (see Section 3.2.5).
de Kater, et al. Expires 7 December 2026 [Page 40]
Internet-Draft SCION CP-PKI June 2026
It differs fundamentally from a TRC update (whether regular or
sensitive) because the signatures on the new base TRC cannot be
verified using the certificates contained in the predecessor TRC.
Instead, a trust reset base TRC must be axiomatically trusted,
similar to how the initial TRC is trusted. The base number of a new
TRC following a trust reset is changed as shown in Table 6.
This procedure serves as a remediation mechanism when an ISD must re-
establish its root of trust following a severe compromise. A TRC is
considered compromised if its associated root or voting keys have
been exposed. If the number of compromised voting keys is lower than
the voting quorum, a TRC update is sufficient to replace the affected
keys (see Section 3.5).
A trust reset is only required when the number of simultaneously
compromised voting keys meets or exceeds the TRC's voting quorum (see
Section 3.2.7), and an invalid or malicious TRC update has
subsequently been produced and distributed across the network. The
new TRC must be axiomatically trusted and distributed via out-of-band
communication channels.
3.7. 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 initial TRC
by means of a secure offline or online mechanism.
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.7.
de Kater, et al. Expires 7 December 2026 [Page 41]
Internet-Draft SCION CP-PKI June 2026
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.
SCION provides the following mechanisms for discovering TRC updates
and fulfilling the above requirement:
* _Beaconing Process_: The TRC version is announced during the
beaconing process (see [I-D.dekater-scion-controlplane] section
"AS Entry Signed Header"). Each AS MUST announce the latest TRC's
base and serial number known to it. Consequently, relying parties
involved in 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.
* _Path Lookup_: In every path segment, all ASes MUST reference the
latest TRC of their ISD. Consequently, relying parties will
detect TRC updates, including those from remote ISDs, during path
lookups.
* _Active Discovery_: A relying party can actively request any TRC
—either a specific version or the latest available version— from
the sender of the secured information at any time. The necessary
query and response is described in
[I-D.dekater-scion-controlplane], section "Distribution of
Cryptographic Material".
Relying parties such as an AS Control Service require at least one
valid TRC available and should therefore discover TRC updates within
the grace period defined in the updated TRC. 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, ensuring that relying parties can discover TRC
updates in a matter of minutes to hours.
Once a relying party learns of a new TRC, it can obtain the TRC from
one of the Authoritative ASes (see Section 3.2.9).
de Kater, et al. Expires 7 December 2026 [Page 42]
Internet-Draft SCION CP-PKI June 2026
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 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 its own valid 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.6.4.1.
* Subject key identifier: The identifier of the public key to be
used to verify the message. For specification details, see
Section 2.7.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.
* 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, these
certificate chains are distributed separately from the signed
messages.
de Kater, et al. Expires 7 December 2026 [Page 43]
Internet-Draft SCION CP-PKI June 2026
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.
2. If the signature metadata of the message contains the serial and
base number of a previously unseen TRC, the relying party MUST
ensure that they have this TRC.
3. After constructing the pool of root certificates, the relying
party selects the certificate chain used to verify the message.
The AS certificate included in this certificate chain MUST
satisfy all of the following properties:
* The ISD-AS number in the subject of the AS certificate matches
the ISD-AS number in the signature metadata. See also
Section 2.6.4.1.
* The subject key identifier of the AS certificate matches the
subject key identifier in the signature metadata. See also
Section 2.7.2.
* The AS certificate is valid at time of verification. While
this is typically the current time, specific scenarios such as
auditing may require verifying against a historical timestamp.
Refer to [I-D.dekater-scion-controlplane] section "Effects of
Clock Inaccuracy" for considerations about time
synchronization.
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
de Kater, et al. Expires 7 December 2026 [Page 44]
Internet-Draft SCION CP-PKI June 2026
- all subjects of the certificates in the chain carry the
same ISD number (see also Section 2.6.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.
An implication of the above procedure is that path segments are
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
issuing CA within the ISD.
3. The CA uses its CA key and the CSR to issue the new AS
certificate.
4. The CA sends the AS certificate back to the AS.
When an AS joins an ISD, it sends the first CSR 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"). When using this automated in-band renewal process, the
request requires two distinct cryptographic signatures to ensure both
proof of possession and authorization:
de Kater, et al. Expires 7 December 2026 [Page 45]
Internet-Draft SCION CP-PKI June 2026
* Proof of possession: the inner PKCS#10 CSR MUST be signed using
the newly generated private key corresponding to the requested
certificate.
* Authorization: The AS MUST authenticate the request to the Issuing
CA by wrapping the CSR in a CMS SignedData structure
(cms_signed_request). This outer CMS structure MUST be signed
using the existing private key corresponding to one of the AS's
currently active and valid AS certificate.
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.
Furthermore, PKI operators need to ensure that the CAs maintain time
synchronization with other system components. Further considerations
related to this aspect are discussed in
[I-D.dekater-scion-controlplane], sections "Effects of Clock
Inaccuracy" and "Attacks on Time Sources".
To ensure redundancy, an ISD should contain multiple Authoritative
ASes (see Section 3.2.9).
5.2. Operational Processes for ISD Governance
An ISD is governed by Voters who may produce a regulations document
to facilitate operations. Such document typically describes:
* governance structure
* roles and responsibilities
* admission criteria
* processes
de Kater, et al. Expires 7 December 2026 [Page 46]
Internet-Draft SCION CP-PKI June 2026
* protection measures for keys (e.g. use of HSMs)
* actions in case of compromise or regulations breach
Appendix C describes a typical TRC Signing Ceremony, but further
processes are out-of-scope.
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 discusses the implications 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 a 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 enough voting keys to reach the voting
quorum set in the TRC. The higher the quorum, the harder a
malicious update becomes.
* 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.
de Kater, et al. Expires 7 December 2026 [Page 47]
Internet-Draft SCION CP-PKI June 2026
* 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.
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 an invalid update
has been produced and distributed in the network.
* At CA level: If the private key related to an 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 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 needs to 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.
de Kater, et al. Expires 7 December 2026 [Page 48]
Internet-Draft SCION CP-PKI June 2026
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.
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 (e.g., for certificate
renewal);
* 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).
In typical deployments, initial TRCs are provisioned out of band.
Should an endpoint retrieve the initial TRC in-band (e.g. from a
local control service or a resolution server) without prior
validation, it would effectively operate 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
de Kater, et al. Expires 7 December 2026 [Page 49]
Internet-Draft SCION CP-PKI June 2026
[BCP47] Best Current Practice 47,
<https://www.rfc-editor.org/info/bcp47>.
At the time of writing, this BCP comprises the following:
Phillips, A., Ed. and M. Davis, Ed., "Matching of Language
Tags", BCP 47, RFC 4647, DOI 10.17487/RFC4647, September
2006, <https://www.rfc-editor.org/info/rfc4647>.
Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[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-18, 30 April 2026,
<https://datatracker.ietf.org/doc/html/draft-dekater-
scion-controlplane-18>.
[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>.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,
<https://www.rfc-editor.org/rfc/rfc5198>.
[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>.
de Kater, et al. Expires 7 December 2026 [Page 50]
Internet-Draft SCION CP-PKI June 2026
[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>.
[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>.
de Kater, et al. Expires 7 December 2026 [Page 51]
Internet-Draft SCION CP-PKI June 2026
[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/>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013,
<https://www.rfc-editor.org/rfc/rfc6960>.
[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 7 December 2026 [Page 52]
Internet-Draft SCION CP-PKI June 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 Attributes
id-at OBJECT IDENTIFIER ::= { id-cppki 2 }
-- SCION ISD-AS Attribute
id-at-ia OBJECT IDENTIFIER ::= { id-at 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)
de Kater, et al. Expires 7 December 2026 [Page 53]
Internet-Draft SCION CP-PKI June 2026
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18)
};
TRCValidity ::= SEQUENCE {
notBefore GeneralizedTime,
notAfter GeneralizedTime
}
LocalizedText ::= SEQUENCE {
language PrintableString (SIZE (1..64)),
content UTF8String (SIZE (1..8192))
}
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 (1..8192)) OPTIONAL,
certificates SEQUENCE SIZE (1..4095) OF Certificate,
localizedDescriptions [0] SEQUENCE SIZE (1..1024) OF LocalizedText OPTIONAL,
descriptionLanguage [1] PrintableString (SIZE (1..64)) OPTIONAL
}
TRCFormatVersion ::= INTEGER { v1(0) }
TRCID ::= SEQUENCE {
iSD ISD,
serialNumber INTEGER (1..MAX),
baseNumber INTEGER (1..MAX)
}
ISD ::= INTEGER (1..65535)
ASN ::= PrintableString (SIZE (1..16))
END
de Kater, et al. Expires 7 December 2026 [Page 54]
Internet-Draft SCION CP-PKI June 2026
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:
* *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 Voters.
* *Voter representatives* - individuals representing each Voter who
are able to create voting signatures on the TRC. They are in
possession of 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
Voter.
The ISD members must decide on the roles of the Signing Ceremony
participants in advance of the Signing Ceremony, and must have
reached agreement about the Certificate Authority (CA) ASes (that
will also issue the root certificates). Hash comparison checks are
included to counter mistakes and so that every participant can ensure
they are operating on the same data.
The private keys of each participant never leave their machine, so
the Ceremony Administrator does not have to be entrusted with private
keys.
C.2. Ceremony Preparations
The participants agree in advance on the location of the Signing
Ceremony, the devices that will be used, and the ISD policy as
follows:
* ISD number - for public ISDs these are obtained from the SCION
registry, see Section 3.2.2;
de Kater, et al. Expires 7 December 2026 [Page 55]
Internet-Draft SCION CP-PKI June 2026
* 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;
* AS numbers of the Authoritative ASes, see Section 3.2.9;
* The list of control plane root certificates.
Each representative of a Voter 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 Ceremony Administrator and Voters must each bring to the Signing
Ceremony a secure machine capable of signing and verifying TRCs and
computing a hash of the files (e.g., SHA-512 or any equivalent or
better algorithm). For Voters, 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, and the Signing
Ceremony must include a procedure to verify that all devices are
secure.
C.3. Ceremony Phases
The number of Voters present at the Signing Ceremony must be equal to
or larger than the specified voting quorum.
de Kater, et al. Expires 7 December 2026 [Page 56]
Internet-Draft SCION CP-PKI June 2026
The signing process has four phases of data sharing, led by the
Ceremony Administrator who provides instructions to the other
participants:
C.3.1. Certificate Exchange
All certificates that are part of the TRC must be shared with the
Ceremony Administrator. For the Voters, 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 hash value for each certificate,
aggregates and bundles all the provided certificates, and finally
calculates the hash value for the entire bundle. SHA-512 is
typically used as hashing algorithm, although any equivalent or
better algorithm may be used. All hash values must be displayed to
the participants.
The Ceremony Administrator must then share the bundle with the
representatives of the Voters 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
hashes 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 completed TRC fields (see Section 3.2) 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:
de Kater, et al. Expires 7 December 2026 [Page 57]
Internet-Draft SCION CP-PKI June 2026
* issuer
* subject
* validity
* signature
Once the voting representatives have verified the TRC data, the
Ceremony Administrator computes the DER encoding of the data
according to Section 3.3 and the 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 it on their machine and checking that 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 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.
de Kater, et al. Expires 7 December 2026 [Page 58]
Internet-Draft SCION CP-PKI June 2026
draft-dekater-scion-pki-13
* Draftforge review, sort terminology alphabetically
* Review of normative language
* Rename "Voting AS" to "Voter" and clarify that it does not require
an AS number
* remove trust Hierarchy subsection and redundant code block
* "Trust Model": reword and shorten section about monopoly/oligopoly
* "Trust as a function" and "Trust Hierarchy": remove redundant
sections, since concepts are also explained elsewhere (intro and
Ceremony)
* Certificate validity: align maximum validity recommendations to
current practice, clarify margin for AS certificate renewal
* "Regular Voting Certificate" and "Sensitive Voting Certificate":
merge two nearly identical sections into one
* id-at-ia Attribute": reword and clarify that it is optional in
voting certificates
* issuerUniqueID and subjectUniqueID: merge two nearly identical
sections into one "Unique Identifiers" section
* authorityKeyIdentifier Extension: clarify that authorityCertIssuer
and authorityCertSerialNumber MUST NOT be used
* pathLenConstraint: clarify it MUST be set
* authoritativeASes: improve wording to clarify their role and how
they are provisioned with the latest TRC
* TRC: mandate normalization, introduce language tags ([BCP47]) and
localizedDescriptions, introduce more sequence limits in ASN.1 and
recommend a 4MB maximum size.
* "Certification Path - Trust Anchor Pool" replace python pseudocode
with a list of steps
* "Issuing Control Plane AS Certificates": clarify signatures in
case of automatic renewal
de Kater, et al. Expires 7 December 2026 [Page 59]
Internet-Draft SCION CP-PKI June 2026
* "Trust reset": clarify concept with a dedicated section, improve
readability of Table 6
* "TRC Update Discovery" clarify text
* "PKI Availability": clarify dependency on time sync, and that
there should be multiple Authoritative ASes
* Signing Ceremony: remove normative language from appendix
draft-dekater-scion-pki-12
* Overall review and wording polish
* Introduction: shorten and refer to -controlplane
* 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
de Kater, et al. Expires 7 December 2026 [Page 60]
Internet-Draft SCION CP-PKI June 2026
* 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
* 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
de Kater, et al. Expires 7 December 2026 [Page 61]
Internet-Draft SCION CP-PKI June 2026
* 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.
* Added RFC2119 compliant terminology.
Acknowledgments
Many thanks go to Fritz Steinmann (SIX Group AG), Juan A. Garcia
Prado (ETH Zurich), Russ Housley (Vigil Security LLC), Alexey
Melnikov (Isode), Brian Trammell (Google), Ramon Keller (LibC
Technologies), Patrick Ambord (independent), Dominik Roos (Anapaya
Systems AG), 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 7 December 2026 [Page 62]