Security Block

The third part of a RELOAD message is the security block. The security block is represented by a SecurityBlock structure:

struct {

CertificateType type; // From RFC 6091 opaque certificate<0..2^16-1>;

} GenericCertificate;

struct {

GenericCertificate certificates<0..2^16-1>;

Signature signature;

} SecurityBlock;

The contents of this structure are:

certificates

A bucket of certificates.

signature

A signature.

The certificates bucket SHOULD contain all the certificates necessary to verify every signature in both the message and the internal

message objects, except for those certificates in a root-cert element of the current configuration file. This is the only location in the message which contains certificates, thus allowing only a single copy of each certificate to be sent. In systems that have an alternative certificate distribution mechanism, some certificates MAY be omitted.

However, unless an alternative mechanism for immediately generating certificates, such as shared secret security (Section 13.4) is used, implementers MUST include all referenced certificates.

NOTE TO IMPLEMENTERS: This requirement implies that a peer storing data is obligated to retain certificates for the data that it holds.

Each certificate is represented by a GenericCertificate structure, which has the following contents:

type

The type of the certificate, as defined in [RFC6091]. Only the use of X.509 certificates is defined in this document.

certificate

The encoded version of the certificate. For X.509 certificates, it is the Distinguished Encoding Rules (DER) form.

The signature is computed over the payload and parts of the

forwarding header. In case of a Store, the payload MUST contain an additional signature computed as described in Section 7.1. All signatures MUST be formatted using the Signature element. This element is also used in other contexts where signatures are needed.

The input structure to the signature computation MAY vary depending on the data element being signed.

enum { invalidSignerIdentityType(0),

cert_hash(1), cert_hash_node_id(2), none(3)

(255) } SignerIdentityType;

struct {

select (identity_type) { case cert_hash;

HashAlgorithm hash_alg; // From TLS opaque certificate_hash<0..2^8-1>;

case cert_hash_node_id:

HashAlgorithm hash_alg; // From TLS opaque certificate_node_id_hash<0..2^8-1>;

case none:

/* empty */

/* This structure may be extended with new types if necessary*/

};

} SignerIdentityValue;

struct {

SignerIdentityType identity_type;

uint16 length;

SignerIdentityValue identity[SignerIdentity.length];

} SignerIdentity;

struct {

SignatureAndHashAlgorithm algorithm; // From TLS SignerIdentity identity;

opaque signature_value<0..2^16-1>;

} Signature;

The Signature construct contains the following values:

algorithm

The signature algorithm in use. The algorithm definitions are found in the IANA TLS SignatureAlgorithm and HashAlgorithm registries. All implementations MUST support RSASSA-PKCS1-v1_5 [RFC3447] signatures with SHA-256 hashes [RFC6234].

identity

The identity, as defined in the two paragraphs following this list, used to form the signature.

signature_value

The value of the signature.

Note that storage operations allow for special values of algorithm and identity. See the Store Request definition (Section 7.4.1.1) and the Fetch Response definition (Section 7.4.2.2).

There are two permitted identity formats, one for a certificate with only one Node-ID and one for a certificate with multiple Node-IDs.

In the first case, the cert_hash type MUST be used. The hash_alg field is used to indicate the algorithm used to produce the hash.

The certificate_hash contains the hash of the certificate object (i.e., the DER-encoded certificate).

In the second case, the cert_hash_node_id type MUST be used. The hash_alg is as in cert_hash, but the cert_hash_node_id is computed over the NodeId used to sign concatenated with the certificate; i.e., H(NodeId || certificate). The NodeId is represented without any framing or length fields, as simple raw bytes. This is safe because NodeIds are a fixed length for a given overlay.

For signatures over messages, the input to the signature is computed over:

overlay || transaction_id || MessageContents || SignerIdentity where overlay and transaction_id come from the forwarding header and || indicates concatenation.

The input to signatures over data values is different and is described in Section 7.1.

All RELOAD messages MUST be signed. Intermediate nodes do not verify signatures. Upon receipt (and fragment reassembly, if needed), the destination node MUST verify the signature and the authorizing certificate. If the signature fails, the implementation SHOULD

simply drop the message and MUST NOT process it. This check provides a minimal level of assurance that the sending node is a valid part of the overlay, and it provides cryptographic authentication of the sending node. In addition, responses MUST be checked as follows by the requesting node:

1. The response to a message sent to a Node-ID MUST have been sent by that Node-ID unless the response has been sent to the wildcard Node-ID.

2. The response to a message sent to a Resource-ID MUST have been sent by a Node-ID which is at least as close to the target

Resource-ID as any node in the requesting node’s Neighbor Table.

The second condition serves as a primitive check for responses from wildly wrong nodes but is not a complete check. Note that in periods of churn, it is possible for the requesting node to obtain a closer neighbor while the request is outstanding. This will cause the response to be rejected and the request to be retransmitted.

In addition, some methods (especially Store) have additional authentication requirements, which are described in the sections covering those methods.