Relaynet Public Key Infrastructure and Revocation Profile

  • Id: RS-002.
  • Status: Working draft.
  • Type: Implementation.
  • Issue tracking label: spec-pki.


This document describes how to issue, revoke and process X.509 certificates in Relaynet messaging protocols. Despite the use of X.509 certificates, this Public Key Infrastructure (PKI) profile is independent of and incompatible with the Internet PKI profile as used in the TLS protocol.

Table of contents

  1. Introduction
  2. General Constraints and Attributes
  3. Certificate Types
    1. Endpoint Certificate
    2. Parcel Delivery Authorization (PDA)
      1. Rate Limiting Extension
    3. Gateway Certificate
    4. Cargo Delivery Authorization (CDA)
  4. Certificate and Key Rotation
  5. Certificate Revocation
    1. Endpoint Self-Signed Certificate Revocation
    2. Gateway Certificate Revocation (GCR)
  6. X.509 Extensions
    1. Basic Constraints
    2. Authority Key Identifier
    3. Subject Key Identifier


Relaynet relies extensively on its PKI in order to authenticate and authorize nodes without a real-time connection to an external authentication/authorization server, as well as to encrypt payloads when the Channel Session Protocol is not employed.

One prominent use of the Relaynet PKI is in the Relaynet Abstract Message Format (RAMF), where certificates are used to authenticate the sender of the message and ensure the integrity of the message. Any valid certificate can be used to sign a message bound for a public node, but every message bound for a private node has to be signed with a certificate issued by the recipient (in which case the certificate will be called a delivery authorization).

This PKI applies to the long-term keys that identify endpoints and gateways in Relaynet, and it also serves as the basis for issuing certificates for initial keys in the Channel Session Protocol. The requirements and recommendations in this document do not apply to the Internet PKI certificates used in Message Transport Bindings.

General Constraints and Attributes

Certificates in this PKI profile MUST be represented as X.509 v3 certificates.

The Distinguished Name MUST only contain the Common Name (CN) attribute, and it MUST be set to the node’s private address (e.g., CN=0b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c).

A certificate MUST NOT be valid before its issuer is valid or after its issuer expires.

Certificate Types

Endpoints and gateways can use the following types of certificates.

Endpoint Certificate

An endpoint certificate MUST be issued by one of the following Certificate Authorities (CAs):

  • Itself, if it is a public endpoint.
  • Its private gateway, if it is a private endpoint.
  • Another endpoint, resulting in a parcel delivery authorization.

Parcel Delivery Authorization (PDA)

Given private Endpoint A and Endpoint B, Endpoint A MAY instruct its gateway and its public gateway to accept parcels from Endpoint B by signing Endpoint B’s certificate, which will result in a special endpoint certificate called Parcel Delivery Authorization (PDA).

The certification path of a PDA is formed of the following sequence (from end entity to root):

  1. Endpoint B’s certificate.
  2. Endpoint A’s certificate.
  3. Endpoint A’s private gateway.
  4. Endpoint A’s public gateway.

When relaying parcels where the recipient is a private endpoint, gateways MUST refuse those where the certificate for the sender of the parcel was not issued by the target endpoint. In other words, the Common Name of the second certificate MUST match the recipient of the RAMF-serialized parcel.

Rate Limiting Extension

Endpoint A MAY rate limit the volume of parcels that Endpoint B may send with the PDA by including the non-critical extension PDA Rate Limiting.

Gateways SHOULD enforce the rate limiting specified by the extension, if present. When evaluating the eligibility of a message for rate limiting purposes, public gateways MUST use the time when the message was received, whilst private gateways MUST use the date specified in the RAMF message.

The target endpoint (Endpoint A) MAY enforce the rate limiting.

The ASN.1 Object Identifier of this extension is defined as follows:

    itu-t(0) identified-organization(4) etsi(0) reserved(127) etsi-identified-organization(0)
        relaycorp(17) relaynet(0) pki(0) 0

The ASN.1 value of the extension is defined as follows:

    limit  INTEGER,
    period INTEGER

Where, limit specifies how many parcels can be sent within a given number of seconds (period). For example, a limit of 1 and a period of 86400 allow a maximum of one parcel a day.

Gateway Certificate

Each gateway has at least two certificates for the same long-term key pair: One self-issued and one certificate issued by each of its peers. Consequently, every private gateway has exactly two certificates because it has exactly one peer, while a public gateway may have more certificates.

Self-issued certificates MUST only be used to issue certificates to peers, and therefore such certificates will be the root for a PDA or a Cargo Delivery Authorization (CDA). Self-issued certificates MUST NOT be used to sign channel or binding messages. Peers MAY use the self-issued certificate to encrypt payloads when not using the Channel Session Protocol.

Certificates issued by peers MUST be used to sign channel and binding messages like cargoes. A certificate issued by a private gateway to its public peer is known as a CDA, and additional requirements and recommendations apply.

Cargo Delivery Authorization (CDA)

Any certificate issued by a private gateway to a public one is regarded as a Cargo Delivery Authorization (CDA), and it authorizes the public gateway to send cargo to the private gateway.

CDAs SHOULD be valid for at least 24 hours, and they MUST NOT be valid for more than 30 days.

Certificate and Key Rotation

Endpoints and gateways MAY use multiple certificates, with the same or different asymmetric keys (and therefore different addresses), at any point in time, in order to facilitate certificate or key rotation.

An endpoint or gateway initiating a certificate rotation MUST share the new certificate using a Certificate Rotation Message (CRM) through the appropriate messaging channels. Such a message MUST:

  • Be serialized with the Relaynet Abstract Message Format (RAMF), using the octet 0x10 as its concrete message type.
  • Be signed with a certificate that the target endpoint/gateway already trusts.
  • Have their payload encrypted as specified in the Core and RAMF specifications.
  • Have its payload plaintext contain only the new certificate.

CRMs MUST be top-level messages in the endpoint channel, but they MUST be encapsulated in cargo in the gateway channel (along with parcels) to prevent malicious couriers from identifying and dropping such messages.

Since a recipient could have multiple keys at any point in time, endpoints and gateways MUST include the appropriate metadata to identify the correct certificate in any Cryptographic Message Syntax (CMS) enveloped-data values that they generate.

Certificate Revocation

Certificates MUST be revoked when their private keys are compromised, when a rotation is complete, or when deemed appropriate by their subject or issuer.

Endpoint Self-Signed Certificate Revocation

The endpoint MUST:

Gateway Certificate Revocation (GCR)

A gateway MAY revoke its own certificate by issuing a GCR message to its peer gateway(s). These messages MUST be serialized with RAMF, using the octet 0x11 as its concrete message type, and have an empty payload (i.e., one of length zero).

GCRs MUST be sent in the payload plaintext of a cargo, along with parcels, in order to prevent a malicious courier from identifying and dropping such messages.

X.509 Extensions

Basic Constraints

Each certificate MUST have its Basic Constraints extension as defined in the X.509 v3 specification. The extension MUST be marked as critical and its attributes MUST be set as follows depending on the type of certificate:

Certificate type cA pathLenConstraint
Self-issued gateway certificate true 2
Non-self-issued gateway certificate (excluding CDAs) true 1
Endpoint certificate (excluding PDAs) true 0
Delivery authorization (PDAs and CDAs) false 0

Authority Key Identifier

Except for self-issued certificates, all certificates MUST include the Authority Key Identifier extension as defined in the X.509 v3 specification.

Subject Key Identifier

All certificates MUST include the Subject Key Identifier extension as defined in the X.509 v3 specification.