SCION Control-Plane PKI

2.2.1.3.1. AlgorithmIdentifier Sequence

X.509 defines the syntax of the AlgorithmIdentifier as follows:¶

   AlgorithmIdentifier  ::=  SEQUENCE  {
       algorithm   OBJECT IDENTIFIER,
       parameters  ANY DEFINED BY algorithm OPTIONAL
   }

Note: In SCION implementations, the parameters field MUST be absent, as defined in [RFC8410].¶

In general, if the AlgorithmIdentifier in a specific SCION implementation is not defined as described above, the implementation should stop the validation process entirely and error out.¶

2.2.1.4.1. ISD-AS number Attribute

The ISD-AS number attribute identifies the SCION ISD and AS. In the SCION open source implementation, the attribute type is id-at-ia, defined as:¶

   id-at-ia AttributeType ::= {id-ana id-cppki(1) id-at(2) 1}

where id-ana specifies the root SCION object identifier (OID).¶

Note: The SCION open source implementation currently uses the Anapaya IANA Private Enterprise Number (55324) as root SCION object identifier (OID):
id-ana ::= OBJECT IDENTIFIER {1 3 6 1 4 1 55324}¶

The following points apply when setting the attribute value of the ISD-AS number attribute:¶

• The string representation MUST follow the canonical formatting defined in ISD and AS numbering.¶
• The canonical string representation uses a dash separator between the ISD and AS numbers.¶
• The ISD numbers are formatted as decimal.¶
• The canonical string formatting of AS numbers in the BGP AS range (0, 2^32-1) is the decimal form. Larger AS numbers, i.e., from 2³² to 2^48-1, use a 16-bit, colon-separated, lower-case, hex encoding with leading zeros omitted: 1:0:0 to ffff:ffff:ffff.¶

Example:
AS ff00:0:110 in ISD 1 is formatted as 1-ff00:0:110.¶

The ISD-AS number attribute MUST be present exactly once in all SCION control-plane certificates. Implementations MUST NOT create nor successfully verify certificates that do not include the ISD-AS number, or include it more than once.¶

2.2.1.9.1. authorityKeyIdentifier Extension

The authorityKeyIdentifier extension is defined in clause 9.2.2.1 of X.509.¶

The authorityKeyIdentifier extension identifies the private key used to sign the certificate. It is defined as follows:¶

   authorityKeyIdentifier EXTENSION ::= {
       SYNTAX AuthorityKeyIdentifier
       IDENTIFIED BY id-ce-authorityKeyIdentifier
   }

   AuthorityKeyIdentifier ::= SEQUENCE {
       keyIdentifier             [0]   KeyIdentifier OPTIONAL,
       authorityCertIssuer       [1]   GeneralNames OPTIONAL,
       authorityCertSerialNumber [2]   CertificateSerialNumber OPTIONAL,
       ...
   }
   (WITH COMPONENTS {..., authorityCertIssuer PRESENT,
                          authorityCertSerialNumber PRESENT } |
   WITH COMPONENTS {..., authorityCertIssuer ABSENT,
                         authorityCertSerialNumber ABSENT } )

   KeyIdentifier ::= OCTET STRING

Using the keyIdentifier attribute is the preferred way to specify the authorityKeyIdentifier extension.¶

Important: SCION implementations may also support the use of the authorityCertIssuer and authorityCertSerialNumber attributes. However, if these attributes are set and support for them is missing, implementations should error out.¶

This extension MUST always be non-critical (which is the default, see the code block displaying the generic format of SCION control-plane certificates in Section 2.2.1). However, SCION implementations MUST error out if the extension is not present AND the certificate is not self-signed.¶

2.2.1.9.2. subjectKeyIdentifier Extension

The subjectKeyIdentifier extension is defined in clause 9.2.2.2 of X.509, (10/2016).¶

The subjectKeyIdentifier extension identifies the public key being certified. 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. It is defined as follows:¶

   subjectKeyIdentifier EXTENSION ::= {
       SYNTAX SubjectKeyIdentifier
       IDENTIFIED BY id-ce-subjectKeyIdentifier
   }

   SubjectKeyIdentifier ::= KeyIdentifier

This extension MUST always be non-critical (which is the default, see the code block displaying the generic format of SCION control-plane certificates in Section 2.2.1). However, SCION implementations must error out if the extension is not present.¶

2.2.1.9.3. keyUsage Extension

The keyUsage extension is defined in clause 9.2.2.3 of X.509, (10/2016).¶

The keyUsage extension identifies the intended usage of the public key in the corresponding certificate. The ASN.1 definition is as follows:¶

   keyUsage EXTENSION ::= {
       SYNTAX KeyUsage
       IDENTIFIED BY id-ce-keyUsage
   }

   KeyUsage ::= BIT STRING {
       digitalSignature  (0),
       contentCommitment (1),
       keyEncipherment   (2),
       dataEncipherment  (3),
       keyAgreement      (4),
       keyCertSign       (5),
       cRLSign           (6),
       encipherOnly      (7),
       decipherOnly      (8),
   }

The attributes of the keyUsage extension define the various possible ways of using the public key. The attributes have the following meaning in SCION:¶

• digitalSignature: The public key can be used to verify the digital signature of a control-plane payload.¶
• contentCommitment: Not used.¶
• keyEncipherment: Not used.¶
• dataEncipherment: Not used.¶
• keyAgreement: Not used.¶
• keyCertSign: The public key can be used to verify the CA signature on a control-plane certificate.¶
• cRLSign: Not used.¶
• encipherOnly: Not used.¶
• decipherOnly: Not used.¶

Important: If the certificate's public key is used to verify the signature of a control-plane payload (digitalSignature attribute), it must be possible to trace back the private key used for the signature. This is done by referencing the ISD-AS and the subject key identifier (via the subjectKeyIdentifier extension). For more information about the subjectKeyIdentifier extension, see Section 2.2.1.9.2.¶

Each control-plane certificate type uses the public key differently, and consequently also specifies the attributes of the keyUsage extension differently. For more information, see the following sections describing the control-plane and voting certificates: Section 2.2.2, Section 2.2.3, Section 2.2.4, and Section 2.2.5.¶

If present, the keyUsage extension should be marked as "critical". That is, the critical Boolean attribute of this extension must be set to TRUE (the default is FALSE, see the code block displaying the generic format of SCION control-plane certificates in Section 2.2.1).¶

Note: If a certificate extension is marked "critical", the public key in the certificate should only be used for the purpose set in the critical extension.¶

2.2.1.9.4. extKeyUsage Extension

The extKeyUsage extension is defined in clause 9.2.2.4 of X.509.¶

The extKeyUsage extension specifies additional usages of the public key in the certificate. It is defined as follows:¶

   extKeyUsage EXTENSION ::= {
       SYNTAX             SEQUENCE SIZE (1..MAX) OF KeyPurposeId
       IDENTIFIED BY      id-ce-extKeyUsage
   }

   KeyPurposeId ::= OBJECT IDENTIFIER

SCION uses the following attributes of the Extended Key Usage extension, as defined in Section 4.2.1.12 of [RFC5280]:¶

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

This extension MUST be present in control-plane root-, AS- and voting certificates. It MAY be present in control-plane CA certificates. For the exact settings per certificate type, see the below sections describing the control-plane and voting certificates: Section 2.2.2, Section 2.2.3, Section 2.2.4, and Section 2.2.5.¶

2.2.1.9.5. basicConstraints Extension

The basicConstraints extension is defined in clause 9.4.2.1 of X.509.¶

The basicConstraints extension specifies whether the certificate subject may act as a CA. The ASN.1 definition for the basicConstraints extension is as follows:¶

   basicConstraints EXTENSION ::= {
       SYNTAX          BasicConstraintsSyntax
       IDENTIFIED BY   id-ce-basicConstraints
   }

   BasicConstraintsSyntax ::= SEQUENCE {
       cA                BOOLEAN DEFAULT FALSE,
       pathLenConstraint INTEGER(0..MAX) OPTIONAL,
   }

• cA attribute: Specifies whether the certificate subject may act as a CA. If yes, this attribute MUST be set to TRUE.¶
• pathLenConstraint attribute: This attribute is only relevant if the cA attribute is set to TRUE. It specifies the maximum number of CA certificates that may follow this CA certificate in the certification chain. Value "0" means that this CA may only issue end-entity certificates, but no CA certificates. If the attribute is not set, there is no limit to the allowed length of the certification path.¶

The settings of the basicConstraints extension differ for each control-plane certificate type. For more information, see the below sections describing the control-plane and voting certificates: Section 2.2.2, Section 2.2.3, Section 2.2.4, and Section 2.2.5.¶

2.2.2.1.1. keyUsage Extension

• digitalSignature attribute: This attribute MUST NOT be set (because the CP root certificate should not be used to verify control-plane messages).¶
• keyCertSign attribute: This attribute MUST be set.¶

2.2.2.1.2. extKeyUsage Extension

The extKeyUsage extension MUST be present in the CP root certificate. It must be defined as follows:¶

• id-kp-serverAuth attribute: MUST NOT be set.¶
• id-kp-clientAuth attribute: MUST NOT be set.¶
• id-kp-timeStamping attribute: MUST be set.¶

Additionally, the id-kp-root attribute must be specified, as follows:¶

   id-kp-root AttributeType ::= {id-ana id-cppki(1) id-kp(3) 3}

where id-ana specifies the root SCION object identifier (OID).¶

Note: The SCION open source implementation currently uses the Anapaya IANA Private Enterprise Number (55324) as root SCION object identifier (OID): id-ana ::= OBJECT IDENTIFIER {1 3 6 1 4 1 55324}¶

2.2.2.1.3. basicConstraints Extension

The basicConstraints extension MUST be present in the CP root certificate.
The extension attributes must be set as follows:¶

• cA attribute: MUST be set to TRUE.¶
• pathLenConstraint attribute: Should be set to "1". Additionally, it must be marked as "critical", according to X.509.
  ¶

2.2.3.1.1. keyUsage Extension

• digitalSignature attribute: This attribute MUST NOT be set (because the control-plane CA certificate should not be used to verify control-plane messages).¶
• keyCertSign attribute: This attribute MUST be set.¶

2.2.3.1.2. extKeyUsage Extension

The extKeyUsage extension MAY be present in the CP CA certificate.¶

If the extKeyUsage extension is present in the CP CA certificate, the attributes id-kp-serverAuth and id-kp-clientAuth MUST NOT be set.¶

2.2.3.1.3. basicConstraints Extension

The basicConstraints extension MUST be present in the CP CA certificate.
The extension attributes must be set as follows:¶

• cA attribute: MUST be set to TRUE.¶
• pathLenConstraint attribute: SHOULD be set to "0". This means that the CP CA certificate can only issue end-entity certificates. Additionally, the attribute must be marked as "critical", according to X.509.
  ¶

2.2.4.1.1. keyUsage Extension

• digitalSignature attribute: This attribute MUST be set.¶
• keyCertSign attribute: This attribute MUST NOT be set.¶

2.2.4.1.2. extKeyUsage Extension

The extKeyUsage extension MUST be present in the CP AS certificate.
It must be defined as follows:¶

• id-kp-serverAuth attribute: MUST be set, if the CP AS certificate is used on the server-side of a control-plane TLS session establishment.¶
• id-kp-clientAuth attribute: MUST be set, if the CP AS certificate is used on the client-side of control-plane TLS session establishment.¶
• id-kp-timeStamping attribute: MUST be set.¶

2.2.4.1.3. basicConstraints Extension

Control-plane AS certificates should not include the basicConstraints extension.¶

2.2.5.2.1. Extension Constraints of Voting Certificates

The extensions of both regular and sensitive voting certificates differ from the general certificate requirements described previously, in the following ways.¶

3.1.2.2.1. version Field

The version field describes the version of the TRC format specification.¶

Currently, the version MUST always be "v1".¶

3.1.2.2.2. iD Field

The iD field specifies the unique identifier of the TRC.¶

The identifier is a unique sequence of¶

• ISD number (iSD attribute),¶
• base number (baseNumber attribute), and¶
• TRC serial number (serialNumber attribute).¶

All numbers MUST be positive integers.¶

• The ISD number MUST be an integer in the inclusive range between 1 and 65535 (i.e., the ISD numbering range).¶
• The base number indicates the starting point of the current TRC update chain. This starting point is either the ISD's initial TRC or the currently valid base TRC, if the valid base TRC differs from the initial TRC. The latter MUST be the case after a trust reset.¶
• The serial number represents the current update cycle, counting from the initial TRC of a specific ISD.¶

A TRC where the base number is equal to the serial number is a base TRC. The initial TRC is a special case of a base TRC. An ISD's initial TRC MUST have a serial number of 1 and a base number of 1. With every TRC update, the serial number MUST be incremented by one. This facilitates uniquely identifying the predecessor and successor TRC in a TRC update chain.¶

If a trust reset is necessary, a new base TRC is announced, in order to start a new and clean TRC update chain. The base number of this new TRC update chain SHOULD be the number following the serial number of the latest TRC that was produced by a non-compromised TRC update for this ISD.¶

Example
The following simple example illustrates how to specify the ID of the TRCs in an TRC update chain for ISD 14. The IDs are given in a human-readable notation, where Bxx is the base number, and Sxx the serial number.¶

3.1.2.2.3. validity Field

The validity field defines the validity period of the TRC. This is the period of time during which the TRC is in the "valid" state. The notBefore and notAfter attributes of the validity field specify the lower and upper bound of the time interval during which a TRC can be active.¶

Note: An active TRC is a valid TRC that can be used for verifying certificate signatures. The time period during which a TRC is active can be shorter than the time period during which the TRC is valid. For more information, see Section 3.1.1.¶

The validity field consists of a sequence of two dates, as defined in section 7.2. of X.509.¶

In addition to this standard definition, the following constraint applies to the validity field of the TRC used in SCION:¶

• All TRCs MUST have a well-defined expiration date. SCION implementations MUST NOT create TRCs that use the "99991231235959Z" generalized time value, and verifiers MUST error out when encountering such a TRC.¶

3.1.2.2.4. gracePeriod Field

The gracePeriod field of a TRC specifies the period of time during which the predecessor TRC can still be considered active (the "grace period"). The grace period starts at the beginning of the validity period of the new TRC.¶

The validity period of the predecessor TRC ends when¶

• the grace period has passed,¶
• the predecessor's expiration time is reached, or¶
• the successor TRC of the new TRC has been announced.¶

Note: The event that happens first marks the end of the predecessor's validity period.¶

The gracePeriod field defines the grace period as a number of seconds (positive integer).¶

The value of the gracePeriod field in a base TRC MUST be zero. The value of the gracePeriod field in a non-base TRC SHOULD be non-zero. It should be long enough to provide sufficient overlap between the TRCs in order to facilitate interruption-free operations in the ISD. If the grace period is too short, some control-plane AS certificates might expire before the corresponding AS can fetch an updated version from its CA.¶

3.1.2.2.5. noTrustReset Boolean

The noTrustReset Boolean specifies whether a trust reset is forbidden by the ISD. Within a TRC update chain, this value CANNOT be changed by a regular or sensitive update. However, it is possible to change the noTrustReset value in the event of a trust reset, where a new base TRC is created.¶

The noTrustReset field is optional and defaults to FALSE.¶

Important: Note that once the noTrustReset Boolean is set to TRUE and a trust reset is disallowed, this cannot be reversed. Therefore, ISDs SHOULD always set this value to FALSE, unless they have sufficiently assessed the risks and implications of making a trust reset impossible.¶

Note: A trust reset represents a special use case where a new base TRC is created. It therefore differs from a TRC update (regular or sensitive), as the signatures in the new base TRC cannot be verified with the certificates contained in the predecessor TRC. Instead, a trust reset base TRC must be axiomatically trusted, similarly to how the initial TRC is trusted.¶

3.1.2.2.6. votes Field

The votes field contains a sequence of indices that refer to the voting certificates in the predecessor TRC. If index i is part of the votes field, then the voting certificate at position i in the certificates sequence of the predecessor TRC casted a vote on the successor TRC.¶

Note: In a base TRC, the votes sequence is empty.¶

Every entry in the votes sequence MUST be unique.
Further restrictions on votes are discussed in Section 3.1.5.¶

Note: The votes sequence of indices is mandatory in order to prevent stripping voting signatures from the TRC. Absence of the votes sequence makes it possible to transform a TRC with more voting signatures than the Section 3.1.2.2.7 into multiple verifiable TRCs with the same payload, but different voting signature sets. This would violate the requirement of uniqueness of a TRC.¶

3.1.2.2.7. votingQuorum Field

The votingQuorum field defines the number of necessary votes on a successor TRC to make it verifiable.¶

A voting quorum greater than one will prevent a single entity from creating a malicious TRC update.¶

3.1.2.2.8. coreASes Field

The coreASes field contains the AS numbers of the core ASes in this ISD.¶

Each core AS number MUST be unique in the sequence of core AS numbers. That is, each AS number must appear only once in the coreASes field.¶

3.1.2.2.9. authoritativeASes Field

The authoritativeASes field contains the AS numbers of the authoritative ASes in this ISD.¶

Authoritative ASes are those ASes in an ISD that always have the latest TRCs of the ISD. As a consequence, authoritative ASes also start the announcement of a TRC update.¶

• Every authoritative AS MUST be a core AS and be listed in the coreASes field.¶
• Each authoritative AS number MUST be unique in the sequence of authoritative AS numbers. That is, each AS number must appear only once in the authoritativeASes field.¶

3.1.2.2.10. description Field

The description field contains a UTF-8 encoded string that describes the ISD.¶

• The description field SHOULD NOT be empty.¶
• The description of the ISD MUST be in English. Additionally, the description field MAY contain information in other languages.¶

3.1.2.2.11. certificates Field

The voting ASes and the certification authorities (CAs) of an ISD are not specified explicitly in the ISD's TRC. Instead, this information is defined by the list of voting and root certificates in the certificates field of the TRC payload.¶

The certificates field is a sequence of self-signed X.509 certificates. Each certificate in the certificate sequence must be one of the following types:¶

• a sensitive voting certificate,¶
• a regular voting certificate, or¶
• a CP root certificate.¶

Note: The listing location of a certificate within the TRC corresponds with the certificate's type.¶

A certificate that is no control-plane root or voting certificate MUST NOT be included in the sequence of certificates in the certificates field.¶

The constraints on these certificates are described in Section 2.2.2 and Section 2.2.5, respectively. Additionally, the following constraints MUST hold for each certificate:¶

• Each certificate MUST be unique in the sequence of certificates. That is, each certificate must appear only once in the certificates field.¶
• The issuer / serialNumber pair for each certificate MUST be unique.¶
• If an ISD-AS number is present in the distinguished name of the certificate, the ISD number in the certificate MUST be equal to the ISD number of this TRC (which is defined in the iD field (see Section 3.1.2.2.2).¶
• Every certificate MUST have a validity period that fully contains the validity period of this TRC. That is, the notBefore date of this TRC's validity period MUST be equal to or later than the certificate's notBefore date, and the notAfter date of this TRC's validity period MUST be before or equal to the certificate's notAfter date.¶
• Per certificate type, every certificate distinguished name MUST be unique.¶

The following must hold for the entire sequence of certificates in the certificates field:¶

• votingQuorum <= count (sensitive voting certificates)
  That is, the quorum defined in the TRC's votingQuorum field (Section 3.1.2.2.7) must be smaller than or equal to the number of sensitive voting certificates specified in the TRC's certificates field.¶
• votingQuorum <= count (regular voting certificates)
  That is, the quorum defined in the TRC's votingQuorum field (Section 3.1.2.2.7) must be smaller than or equal to the number of regular voting certificates specified in the TRC's certificates field.¶

3.2.2.2.1. Location

The location must provide electricity and enough power sockets for each participant. Furthermore, it should provide a monitor (or projector) that allows the ceremony administrator to screen cast.¶

3.2.2.2.2. Devices

Each party brings their own device that is provisioned with the required material, as described below.¶

• Device to exchange data. This device can either be provided by the ceremony administrator, or, if preferable, by any of the voting representatives.¶
• Ceremony administrator's device: The ceremony administrator should bring a machine that is capable of creating and verifying a TRC. Furthermore, it needs to be able to compute the SHA-512 digest (hash value) of files.¶
• Voting representative's device: The voting representative should bring a machine that is capable of signing and verifying TRCs. Thus, the machine needs to have access to all the voting private keys. Furthermore, it needs to be able to compute the SHA-512 digest (hash value) of the files. The exact binaries that are required are described in a separate document.¶

Important: It is very important that all devices, especially the data exchange device, are not compromised. Therefore, the ceremony should ideally include a procedure to verify that the devices are secure.¶

3.2.2.2.3. Preparation Steps

Each party involved in a TRC signing ceremony must go through a few steps in preparation for the ceremony. This section outlines these steps.¶

3.2.2.3.1. Phase 1: Certificate Exchange

In Phase 1 of the signing ceremony, all parties share the certificates that must be part of the TRC with the ceremony administrator. For the representatives of the voting ASes, these are the sensitive and the regular voting certificates. For the representatives of the ASes that are also Certificate Authorities, the list of certificates must include the CP root certificate.¶

The actual sharing happens over the data exchange device, which goes from one voting representative to the next. Each voting representative copies the requested certificates from their own machine onto the data exchange device, before forwarding the device to the next voter. The last voter returns the device to the ceremony administrator.¶

Important: Note that only the certificates must be shared during this step, not the private keys. Copying a private key by mistake invalidates the security of the ceremony.¶

For each provided certificate, the ceremony administrator checks that its validity period covers the previously agreed-upon TRC validity, that the signature algorithms are correct, and that the certificate is of the valid type (root, sensitive voting or regular voting certificate). If the results of these checks are as expected, the ceremony administrator computes the SHA256 sum for each certificate. The ceremony administrator then aggregates and bundles the provided certificates, and calculates the hash value (SHA-512 digest) over the entire bundle. Additionally, the ceremony administrator displays all hash values on the monitor.¶

The ceremony administrator now shares the bundle with all voters. This could happen again via the data exchange device, which goes from one voter to the next. Each voting representative verifies that the certificates they contributed have the same hash value as the displayed value on the monitor. Furthermore, all voting representatives must confirm that the hash value of the bundled certificates on their machine is equal to the value on the monitor.¶

Phase 1 is concluded when every voting representative has confirmed that the SHA256 sums are correct.¶

Note: If there is a mismatch in any of the SHA256 sums, Phase 1 needs to be repeated.¶

3.2.2.3.2. Phase 2: Generation of the TRC Payload

In Phase 2 of the ceremony, the ceremony administrator generates the TRC payload based on the bundled certificates and the agreed-upon ISD policy. The result is displayed on the monitor along with a hash value (SHA-512 digest).¶

To be able to generate the payload, the ceremony administrator must ask the voting representatives for¶

• The ISD number of the ISD. The number (identifier, ID) of an ISD must be chosen and agreed upon by the participants during the signing ceremony of the ISD's initial TRC. The ceremony administrator needs the ISD number to specify the identifier (ID) of the initial TRC. This iD is part of the TRC payload. For more information, see Section 3.1.2.2.2.¶
• The description of the TRC. For more information, see Section 3.1.2.2.10.¶
• The AS numbers of the core ASes of the ISD. For more information, see Section 3.1.2.2.8.¶
• The AS numbers of the authoritative ASes of the ISD. For more information, see Section 3.1.2.2.9.¶
• The voting quorum for the next TRC update. For more information, see Section 3.1.2.2.7.¶
• The validity period of the new TRC. For more information, see Section 3.1.2.2.3.¶

Note: It is assumed that the voting ASes have agreed on the answers to the above questions in advance, before the signing ceremony.¶

The ceremony administrator can now specify the TRC payload variables in the payload template file, and show the filled-in template on the monitor. When the voters have verified the data, the ceremony administrator can compute the DER encoding of the TRC data as well as the SHA256 sum of the TRC payload file. The ceremony administrator then distributes the TRC payload (via the data exchange device) to all voting representatives, who verify the payload's hash value. The voters do this by computing the hash value of the TRC payload on their machine and checking whether their value matches the one on the monitor.¶

Phase 2 successfully concludes once every voting representative confirms that the contents of the TRC payload are correct.¶

3.2.2.3.3. Phase 3: TRC Signing

In Phase 3, each voting representative attaches a signature created with each one of their private voting keys to the TRC (payload file). They do this on their own machine. The purpose of signing a TRC that contains newly introduced public keys with the corresponding private keys is to prove the possession of the private keys.¶

Phase 3 concludes after all voting representatives have cast their votes.¶

3.2.2.3.4. Phase 4: TRC Validation

In Phase 4, all voting representatives share the signed TRC with the ceremony administrator. This happens again over the data exchange device, which goes from one voter to the next. Each voting representative copies the TRC payload signed with the voter's private keys from their own machine onto the data exchange device. The last voter returns the device to the ceremony administrator, who assembles the final TRC by aggregating the payload data with the votes (signatures) cast by the voting representatives.¶

The signed TRC is validated by inspecting its contents on the monitor and verifying the signatures based on the exchanged certificates in Phase 1. The ceremony administrator then shares the signed TRC with all participants. Each of them must then inspect it once more, and verify it based on the certificates exchanged in Phase 1. At this point, the ceremony is completed. All participants have the signed TRC, and can use it to distribute the trust anchors for their ISD.¶