SCION Control Plane PKI

SCION Control Plane PKI Independent

c_de_kater@gmx.ch

SCION Association

nic@scion.org

Anapaya Systems

hitz@anapaya.net

Internet-Draft 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 The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction SCION is a path-aware internetworking routing architecture as described in . A more detailed introduction, motivation, and problem statement are provided in . 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. Control Plane (CP) - performing inter-domain routing by discovering and securely disseminating path information. It is described in . Data Plane - carrying out secure packet forwarding between SCION-enabled ASes over paths selected by endpoints. It is described in .

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). 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.

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 when, and only when, they appear in all capitals, as shown here.

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 . 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 (). 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 ISD. 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 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 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.

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).

Updates and Trust Resets There are two types of TRC updates: regular and sensitive. The update type depends on which fields are changed (see ). In both cases the base TRC remains unchanged. Authoritative ASes announce these TRC updates (see ). In case the TRC has been compromised, it may be re-established through a process called trust reset (see ). In this case, a new base TRC is created.

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. These approaches constitute 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 and OCSP checks improves performance by removing additional network lookups during PKI processing.
Even with a revocation system, a compromised key cannot be instantaneously revoked. Through their validity period, both short-lived certificates and revocation lists implicitly define an 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.

Overview of Certificates, Keys, and Roles The base TRC constitutes the root of trust within an ISD. provides a view of the trust chain within an ISD, based on its TRC. For detailed descriptions, please refer to and .

Chain of trust within an ISD. The TRC number (e.g., TRC 1) refers to the TRC's serialNumber. | |- 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| +-----------+ +-----------+ +-----------+ ]]> All certificates used in the Control Plane PKI are in X.509 v3 format and additionally the TRC contains self-signed certificates instead of plain public keys. Self-signed certificates have the following advantages over plain public keys: (1) They make the binding between name and public key explicit; and (2) the binding is signed to prove possession of the corresponding private key. The public keys of voting certificates must therefore be explicitly verified during the Signing Ceremony () 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.

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 . 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.

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. 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 .

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 ). 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 ). This ensures that the TRC need not be updated all the time and is thus relatively stable.

Control Plane AS Certificate SCION ASes sign control plane messages, such as Path Construction Beacons, with their AS private key. Consequently, control plane AS certificates holding the corresponding AS public key are required to verify control plane messages. In X.509 terms, control plane AS certificates are end entity certificates. That is, they cannot be used to verify other certificates. The RECOMMENDED maximum validity period of a CP AS certificate is 3 days. 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 .

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 . 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.

Key Pairs Overview and Notations and below provide an overview of certificates and corresponding key pairs. Key chain

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

(1) K_x = PK_x + SK_x, where x = certificate type, PK_x = public key, and SK_x = private key Certificates

Name	Notation	Signed with	Contains	Validity (2)
TRC (trust root conf.)	TRC	SK_sens, SK_reg (1)	C_root, C_sens, C_reg (1)	1 year
Sensitive voting cert.	C_sens	SK_sens	PK_sens	5 years
Regular voting cert.	C_reg	SK_reg	PK_reg	5 years
CP root certificate	C_root	SK_root	PK_root	5 years
CP issuing CA certificate	C_CA	SK_root	PK_CA	15 days (3)
CP AS certificate	C_AS	SK_CA	PK_AS	3 days

(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. 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 and the different types of associated certificates. Arrows indicate the certificate hierarchy.

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 , which apply to all SCION certificate types. For the baseline X.509 v3 format, refer to and Clause 7.2. The following subsections define the specific constraints for the fields contained in the TBSCertificate sequence.

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.

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.

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 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 . SCION implementations MUST include support for the ECDSA curves below.

NIST P-256 (NISTFIPS186-4, section D.1.2.3) (named secp256r1 in )
NIST P-384 (NISTFIPS186-4, section D.1.2.4) (named secp384r1 in )
NIST P-521 (NISTFIPS186-4, section D.1.2.5) (named secp521r1 in )

The OIDs for the above curves are specified in section 2.1.1.1 of . 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

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. In addition to the attributes described in section 4.1.2.4 , SCION implementations MUST also support the SCION-specific id-at-ia attribute.

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 , 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 . 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.

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 . SCION deployments SHOULD adopt these values.

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 , SCION implementations MUST also support the SCION-specific id-at-ia attribute, see .

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.

Unique Identifiers The issuerUniqueID and subjectUniqueID fields MUST NOT be used according to section 4.1.2.8.

Extensions , 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 , section 4.2.1. The corresponding clauses in 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.

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 , section 4.2.1.1, and , 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 section 4.2. Implementations MUST return an error if the extension is not present AND the certificate is not self-signed.

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 , section 4.2.1.2, and , clause 9.2.2.2. This extension MUST be marked as non-critical. Implementations MUST return an error if the extension is not present.

keyUsage Extension The keyUsage extension identifies the intended usage of the public key in the corresponding certificate. For the syntax and definition of the keyUsage extension, see , section 4.2.1.3, and , 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 ). 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. keyUsage extension - Specifications per certificate type

Certificate Type	Root	Issuing CA	AS	Voting
Attribute:
`keyUsage` extension itself	REQUIRED	REQUIRED	REQUIRED	OPTIONAL
`digitalSignature` bit	MUST NOT be asserted (1)	MUST NOT be asserted (1)	MUST be asserted	MUST NOT be asserted
`keyCertSign` bit	MUST be asserted	MUST be asserted	MUST NOT be asserted	MUST NOT be asserted

(1) Root and Issuing CA certificates SHOULD NOT be used to verify control plane messages.

extKeyUsage Extension The extKeyUsage extension specifies additional usages of the public key in the certificate. For the syntax and definition of the extKeyUsage extension, see , 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 :

id-kp-serverAuth: If set, the public key can be used for SCION Control Plane server authentication.
id-kp-clientAuth: If set, the public key can be used for SCION Control Plane client authentication.
id-kp-timeStamping: If set, the public key can be used for the verification of timestamps.

Additionally, the Extended Key Usage extension sequence MAY include the SCION-specific attributes id-kp-root, id-kp-regular, and id-kp-sensitive. These attributes are used in the TRC setup to distinguish root certificates, regular voting certificates, and sensitive voting certificates from each other. For more information, see . 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. extKeyUsage extension - Specifications per certificate type

Certificate Type	Root	Issuing CA	AS	Voting
Attribute:
`extKeyUsage` extension itself	REQUIRED	OPTIONAL	REQUIRED	REQUIRED
`id-kp-serverAuth`	MUST NOT be included	MUST NOT be included	MUST be included, if the certificate is used on the server-side of a control plane TLS session.	MUST NOT be included
`id-kp-clientAuth`	MUST NOT be included	MUST NOT be included	MUST be included, if the certificate is used on the client-side of a control plane TLS session.	MUST NOT be included
`id-kp-timeStamping`	MUST be included		MUST be included	MUST be included
SCION-specific attributes (see )	`id-kp-root` MUST be included			Regular voting cert: `id-kp-regular` MUST be included. Sensitive voting cert: `id-kp-sensitive` MUST be included

Note: the use of extKeyUsage in root certificates renders them incompatible with standard TLS handshakes according to , 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.

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 .

basicConstraints Extension The basicConstraints extension specifies whether the certificate subject acts as a CA. For the syntax and definition of the basicConstraints extension, see , 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. basicConstraints extension - Specifications per certificate type

Certificate Type	Root	Issuing CA	AS	Voting (regular and sensitive)
Attribute:
`basicConstraints` extension itself	REQUIRED	REQUIRED	SHOULD NOT be present	SHOULD NOT be present
`cA`	MUST be asserted	MUST be asserted	If the extension is present, this attribute MUST NOT be asserted	If the extension is present, this attribute MUST NOT be asserted
`pathLenConstraint`	MUST be set to "1"	MUST be set to "0" (1)	MUST NOT be included	MUST NOT be included

(1) Control Plane CAs can only issue end entity certificates.

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 . The TRC contains a signed collection of v3 certificates and ISD-specific policies. Encoding for the purpose of signature calculation is described in . 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 syntax.

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 ). 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.
Updated: 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 ). 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 ). 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.

shows the content of both a base/initial TRC. All elements of the TRC are detailed in the following subsections.

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 . 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.

version The version field describes the version of the TRC format specification. It MUST be "v1".

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. 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 . 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

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

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 . 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.

gracePeriod The gracePeriod field specifies the duration, in seconds, during which the predecessor TRC remains active after a new TRC is issued. This grace period starts at the beginning of the validity period of the new TRC. A predecessor TRC ceases to be active when the earliest of the following events occurs:

the grace period expires;
the predecessor TRC reaches its expiration time (notAfter);
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.

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 .

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 . 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 . 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.

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.

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 , 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.

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 ). 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.

description The description field contains a UTF-8 encoded string that describes the ISD. The text MUST be formatted in accordance with "Net-Unicode" 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 ). 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.

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 . 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.
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 ).
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 () 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 () MUST be smaller than or equal to the number of regular voting certificates specified in the TRC's certificates field.

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 .
content: contains the localized description. It MUST be formatted in accordance with "Net-Unicode" .

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 .

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 , and is encapsulated in a CMS ContentInfo element, as defined in Section 3 of . For signature calculation, the data that is to be signed MUST be encoded using ASN.1 Distinguished Encoding Rules (DER) .

SCION-specific rules SCION implementations MUST fulfill the following additional rules, as well as the general syntax rules specified in :

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 .
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 ).
- 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 ).
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 ).
- The algorithm specified in the signatureAlgorithm field MUST be one of the algorithms supported by SCION . For details, see .
- The digestAlgorithm is determined by the algorithm specified in the signatureAlgorithm field.

TRC Equality The signer information in the signed TRC is part of an unordered set, as per . 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 .
The REQUIRED signatures for new certificates are implied by the currently valid TRC payload, and, in case of a TRC update, the predecessor payload.

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:

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.
From the selected TRCs, identify those with the highest base number (baseNumber), then select the TRC among them with the highest serial number (serialNumber).
If the verification time is strictly greater than the selected TRC's notAfter date then the process terminates unsuccessfully.
If the TRC is valid, add its root certificates to the trust anchor pool.
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 , section "Distribution of Cryptographic Material". If it cannot be resolved, the verification process fails. For more details, see .

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.

Changed or New Certificates In the context of a TRC update,

A certificate is changing if the certificate is part of the certificates sequence in the predecessor TRC, but no longer part of the certificates sequence in the updated TRC. Instead, the certificates sequence of the updated TRC holds another certificate of the same type and with the same distinguished name.
A certificate is new if there is no certificate of the same type and distinguished name at all in the certificates sequence of the predecessor TRC.

Every new sensitive or regular voting certificate in a TRC attaches a signature to the TRC. This is done to ensure that the freshly included voting entity agrees with the contents of the TRC it is now part of.

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. Overview of the update types and corresponding rules

Type of TRC Update	Unchanged Elements	Changed Elements	Other Rules to Hold
Both Regular AND Sensitive	- `iD` field: `iSD` and `baseNumber` - `noTrustReset` field	`iD` field: `serialNumber` MUST be incremented by 1	`votes` field: Number of votes (indices) => number set in the `votingQuorum` field of the predecessor TRC
Regular	- Quorum in the `votingQuorum` field - Core ASes in the `coreASes` field - ASes in the `authoritativeASes` field - Nr. and distinguished names of root & voting certificates in the `certificates` field - Set of sensitive voting certificates in the `certificates` field		`votes` field: - All votes MUST only refer to regular voting certificates in the predecessor TRC - MUST include votes of each changed regular voting certificate from the predecessor TRC `signatures` field: - MUST include signatures of each changed root certificate from the predecessor TRC
Sensitive	If the update does not qualify as a regular update, it is a sensitive update		`votes` field: - All votes MUST only refer to sensitive voting certificates in the predecessor TRC

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 ).
The serialNumber in the iD field MUST be incremented by one.
The noTrustReset field MUST NOT change (see also ).
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 and .
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 ). 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 .

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.
- 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.

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.

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 ) defines the required number of voters, which will represent regular or sensitive voting certificates, respectively. Furthermore, if one or more new certificates are added to the updated TRC, the corresponding voting representatives MUST also sign the updated TRC in order to show that they have access to the private keys listed in these fresh certificates. This is called "showing proof-of-possession" and is done by signing the TRC with the respective private key. For the distinction between changed and new certificates in a TRC update, see . 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.

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.

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 ). 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 . 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 or lost. If the number of exposed or lost voting keys is lower than the voting quorum (see ), a TRC update is sufficient to replace the affected keys (see ). The new TRC must be axiomatically trusted and distributed via out-of-band communication channels.

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. 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.

CP-PKI Operations This section details the procedures for deploying the CP-PKI and securing control plane communications.

Distribution of TRCs

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 .

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 . 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 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 , 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 ).

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.

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 .
Subject key identifier: The identifier of the public key to be used to verify the message. For specification details, see .

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 .
Timestamp: For many messages, the time at which it was signed is useful information to ensure freshness.

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. 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:

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 ) 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 .
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.
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 .
- The subject key identifier of the AS certificate matches the subject key identifier in the signature metadata. See also .
- 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 section "Effects of Clock Inaccuracy" for considerations about time synchronization.
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 .
- Checking that
  - all subjects of the certificates in the chain carry the same ISD number (see also ,
  - each certificate is of the correct type (see also ), and
  - the CA certificate validity period covers the AS certificate validity period.
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.

Issuing Control Plane AS Certificates The steps required to issue a new AS certificate are the following:

The AS creates a new key pair and a certificate signing request (CSR) using that key pair.
The AS sends the certificate signing request to the relevant issuing CA within the ISD.
The CA uses its CA key and the CSR to issue the new AS certificate.
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 , 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:

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.

Deployment Considerations

PKI Availability The Control Plane PKI relies on short-lived certificates as an alternative to revocation, as described in . AS certificates typically have a validity of days (see ), 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 , sections "Effects of Clock Inaccuracy" and "Attacks on Time Sources". To ensure redundancy, an ISD should contain multiple Authoritative ASes (see ).

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
protection measures for keys (e.g. use of HSMs)
actions in case of compromise or regulations breach

describes a typical TRC Signing Ceremony, but further processes are out-of-scope.

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.

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.
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.

Recovery from Compromise This section deals with possible recovery from the compromises discussed in the previous paragraph. As described in , 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 . A trust reset is only required in the case the number of compromised voting keys at the same time is greater or equal than the TRC's quorum (see ).
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.

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. 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 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.

TRC Distribution and Trust on First Use Base TRCs act as an ISD root of trust (see ). 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.

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 ).

References Normative References SCION Control Plane SCION Association SCION Association Anapaya Systems This document describes the Control Plane of the path-aware, inter- domain network architecture SCION (Scalability, Control, and Isolation On Next-generation networks). A fundamental characteristic of SCION is that it gives path control to SCION-capable endpoints that can choose between multiple path options, thereby enabling the optimization of network paths. The SCION Control Plane is responsible for discovering these paths and making them available to the endpoints. The SCION Control Plane creates and securely disseminates path segments between SCION Autonomous Systems (AS) which can then be combined into forwarding paths to transmit packets in the data plane. This document describes mechanisms of path exploration through beaconing and path registration. In addition, it describes how Endpoints construct end-to-end paths by combining path segments obtained through a path lookup process. 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 in this work are offered to the community for its consideration in the further evolution of the Internet. SCION Data Plane Independent SCION Association Independent Anapaya Systems This document describes the Data Plane of SCION (Scalability, Control, and Isolation On Next-generation networks), a path-aware, inter-domain network architecture. Unlike IP-based forwarding, SCION embeds inter-domain forwarding directives in the packet header, enabling endpoints to construct and select end-to-end paths from segments discovered by the Control Plane. The role of the Data Plane is to combine such segments into end-to-end paths, and to forward data according to the specified path. This document describes the SCION packet format, header structure, and extension headers. It also describes the cryptographic mechanisms used for path authorization, processing at routers including a life of a packet example. 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. Unicode Format for Network Interchange The Internet today is in need of a standardized form for the transmission of internationalized "text" information, paralleling the specifications for the use of ASCII that date from the early days of the ARPANET. This document specifies that format, using UTF-8 with normalization and specific line-ending sequences. [STANDARDS-TRACK] Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] Elliptic Curve Cryptography Subject Public Key Information This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279. [STANDARDS-TRACK] Matching of Language Tags This document describes a syntax, called a "language-range", for specifying items in a user's list of language preferences. It also describes different mechanisms for comparing and matching these to language tags. Two kinds of matching mechanisms, filtering and lookup, are defined. Filtering produces a (potentially empty) set of language tags, whereas lookup produces a single language tag. Possible applications include language negotiation or content selection. This document, in combination with RFC 4646, replaces RFC 3066, which replaced RFC 1766. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Tags for Identifying Languages This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Cryptographic Message Syntax (CMS) This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA This document updates RFC 3279 to specify algorithm identifiers and ASN.1 encoding rules for the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures when using SHA-224, SHA-256, SHA-384, or SHA-512 as the hashing algorithm. This specification applies to the Internet X.509 Public Key infrastructure (PKI) when digital signatures are used to sign certificates and certificate revocation lists (CRLs). This document also identifies all four SHA2 hash algorithms for use in the Internet X.509 PKI. [STANDARDS-TRACK] Current Open Questions in Path-Aware Networking In contrast to the present Internet architecture, a path-aware internetworking architecture has two important properties: it exposes the properties of available Internet paths to endpoints, and it provides for endpoints and applications to use these properties to select paths through the Internet for their traffic. While this property of "path awareness" already exists in many Internet-connected networks within single domains and via administrative interfaces to the network layer, a fully path-aware internetwork expands these concepts across layers and across the Internet. This document poses questions in path-aware networking, open as of 2021, that must be answered in the design, development, and deployment of path-aware internetworks. It was originally written to frame discussions in the Path Aware Networking Research Group (PANRG), and has been published to snapshot current thinking in this space. ITU-T X.509 (10/2016) | Information technology – Open Systems Interconnection – The Directory: Public-key and attribute certificate frameworks ITU-T X.680 (02/2021) | Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation 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) ANSI X9.62-1998 | Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References SCION Registry X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP This document specifies a protocol useful in determining the current status of a digital certificate without requiring Certificate Revocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFCs 2560 and 6277. It also updates RFC 5912. The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1 In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver them. This document describes version 1 of the RPKI-Router protocol. RFC 6810 describes version 0. This document updates RFC 6810. The SCION internet architecture ETH Zürich in Switzerland ETH Zürich in Switzerland ETH Zürich in Switzerland ETH Zürich in Switzerland ETH Zürich in Switzerland Association for Computing Machinery (ACM) The Complete Guide to SCION ETH Zuerich ETH Zuerich ETH Zuerich Otto von Guericke University Magdeburg Anapaya Systems ETH Zuerich ETH Zuerich

Certificate Extensions in ASN.1 Syntax

TRC in ASN.1 Syntax

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:

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 AS 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.

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 ;
The description of the TRC, see ;
Validity period of the TRC, see ;
Grace period of the TRC (except for Base TRCs);
Voting quorum for the TRC, see ;
AS numbers of the Core ASes, see ;
AS numbers of the Authoritative ASes, see ;
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.

Ceremony Phases The number of Voters present at the Signing Ceremony must be equal to or larger than the specified voting quorum. The signing process has four phases of data sharing, led by the Ceremony Administrator who provides instructions to the other participants:

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.

Generation of the TRC Payload The Ceremony Administrator generates the TRC payload based on the bundled certificates and completed TRC fields (see ) in accordance with ISD policy, see . For each bundled certificate, the voting representatives must then verify the certificate type and that the following fields contain the correct information:

issuer
subject
validity
signature

Once the voting representatives have verified the TRC data, the Ceremony Administrator computes the DER encoding of the data according to 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.

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.

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 . 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 . 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.

draft-dekater-scion-pki-15

Shrink figure 2 and to fit in one page
TRC ASN.1 module: remove empty lines to fit in a page

draft-dekater-scion-pki-14

Final check (check cross-references, minor changes)
Trust reset - clarify text

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 () 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
"Trust reset": clarify concept with a dedicated section, improve readability of
"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
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
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), Tilmann Zäschke (ETH Zurich), 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 - the book is an important source of input and inspiration for this draft.