Relaynet Public Key Infrastructure and Revocation Profile

  • Id: RS-002.
  • Status: Working draft.
  • Type: Implementation.

Abstract

This document describes how to issue, distribute, store, revoke and interpret X.509 certificates in Relaynet messaging protocols. Despite the use of X.509 certificates, this PKI profile is independent of and incompatible with the Internet PKI profile as used in the TLS protocol.

Table of contents

  1. Basic Constraints and Attributes
  2. Certificate Types
    1. Endpoint Certificate
    2. Parcel Delivery Authorization (PDA)
      1. Rate Limiting Extension
    3. Gateway Certificate
  3. Certificate Type Extension
  4. Certificate and Key Rotation
  5. Certificate Revocation
    1. Endpoint Self-Signed Certificate Revocation
    2. Parcel Delivery Deauthorization (PDD)
    3. Gateway Certificate Revocation (GCR)
  6. X.509 Extensions
    1. Authority Key Identifier
    2. Subject Key Identifier
  7. Security and Scalability Considerations

Basic 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 itself (a self-issued certificate) or a peer endpoint when the certificate is a parcel delivery authorization.

Parcel Delivery Authorization (PDA)

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

If Endpoint A is private, the endpoint and its gateways MUST refuse parcels where the sender certificate is not a valid PDA.

The chain of a PDA is formed of the following sequence (from leaf to root):

  1. (Optional) Endpoint B’s signature-only certificate. A certificate that MUST only be used to sign messages in the endpoint channel (e.g., parcels) on behalf of Endpoint B.
  2. Endpoint B’s certificate.
  3. (Optional) Endpoint A’s signature-only certificate. A certificate that MUST only be used to issue PDAs.
  4. Endpoint A’s certificate, issued by its gateway.

Gateways MUST refuse PDAs whose issuing endpoint’s Common Name does not match that of the recipient of the 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, relaying gateways MUST use the time when the message was received, whilst user 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:

PKIPDARateLimitId OBJECT IDENTIFIER ::= {
    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:

PKIPDARateLimit ::= SEQUENCE {
    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

A gateway’s certificate MUST be either self-issued or issued by its peer gateway, forming the chain below (from leaf to root):

  1. (Optional) The gateway’s signature-only certificate. A certificate that MUST only be used to issue endpoint certificates.
  2. The gateway’s certificate.
  3. (Optional) The peer gateway’s signature-only certificate. A certificate that MUST only be used to issue gateway certificates.
  4. (Optional) The peer gateways’s certificate.

A certificate issued by another gateway MUST NOT be used to issue additional gateway certificates.

Certificate Type Extension

Every certificate in this PKI MUST use the critical extension PDA Certificate Type to specify its type.

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

PDACertTypeId OBJECT IDENTIFIER ::= {
    itu-t(0) identified-organization(4) etsi(0) reserved(127) etsi-identified-organization(0)
        relaycorp(17) relaynet(0) pki(0) 1
    }

Whilst its value is defined as follows:

PDACertType ::= ENUMERATED {
    senderSignOnly        (0),   -- A sender endpoint's signature-only certificate
    sender                (1),   -- A sender endpoint's certificate
    recipientSignOnly     (2),   -- A recipient endpoint's signature-only certificate
    recipient             (3),   -- A recipient endpoint's certificate
    gatewaySignOnly       (4),   -- A gateway's signature-only certificate
    gateway               (5),   -- A gateway's certificate
    peerGatewaySignOnly   (6),   -- A peer gateway's signature-only certificate
    peerGateway           (7)    -- A peer gateway's certificate
    }

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 format signature.
  • 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 relayers 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:

Parcel Delivery Deauthorization (PDD)

A Parcel Delivery Deauthorization (PDD) revokes one or more PDAs. It may be requested by the endpoint or its gateway.

An endpoint MUST use the message transport binding to instruct its gateway to revoke its self-issued certificate or a specific PDA. Such a request MUST include the following data, serialized in the format determined by the specific binding:

  • (Required) The endpoint address affected by the deauthorization. This is needed in case the endpoint has multiple active certificates as a result of a key rotation.
  • (Optional) Serial numbers of the PDAs to revoke. It may be absent to revoke all the PDAs issued by the endpoint.
  • (Required) Expiry date of the deauthorization. If revoking all PDAs from the endpoint, this MUST be the expiry date of the endpoint certificate. If revoking a specific PDA, this MUST be the expiry date of the PDA.

Gateways MUST include all their active PDDs in their Cargo Collection Authorizations, and they MUST enforce PDDs for as long as they are active.

Relaying gateways MAY cache PDDs until they expire in order to refuse future parcels whose PDA has been revoked.

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 format signature, 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 relayer from identifying and dropping such messages.

X.509 Extensions

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.

Security and Scalability Considerations

An endpoint or gateway implemented as a distributed system SHOULD use different keys (and therefore different certificates) for signing and decrypting, as supported by this specification. This might not be necessary when the endpoint/gateway is a monolith.