Signature

NDN Signature is defined as two consecutive TLV blocks: SignatureInfo and SignatureValue. The following general considerations about SignatureInfo and SignatureValue blocks that apply for all signature types:

1. SignatureInfo is included in signature calculation and fully describes the signature, signature algorithm, and any other relevant information to obtain parent certificate(s), such as KeyLocator
2. SignatureValue is excluded from signature calculation and represent actual bits of the signature and any other supporting signature material.

The reason for separating the signature into two separate TLV blocks is to allow efficient signing of a contiguous memory block (e.g., for Data packet this block starts from Name TLV and ends with SignatureInfo TLV).

Signature ::= SignatureInfo
              SignatureValue

SignatureInfo ::= SIGNATURE-INFO-TYPE TLV-LENGTH
                    SignatureType
                    KeyLocator?
                    ... (SignatureType-specific TLVs)

SignatureValue ::= SIGNATURE-VALUE-TYPE TLV-LENGTH
                    ... (SignatureType-specific TLVs and
                    BYTE+

SignatureType

SignatureType ::= SIGNATURE-TYPE-TYPE TLV-LENGTH
                    nonNegativeInteger

This specification defines the following SignatureType values:

Value	Reference	Description
0	DigestSha256	Integrity protection using SHA-256 digest
1	SignatureSha256WithRsa	Integrity and provenance protection using RSA signature over a SHA-256 digest
3	SignatureSha256WithEcdsa	Integrity and provenance protection using an ECDSA signature over a SHA-256 digest
4	SignatureHmacWithSha256	Integrity and provenance protection using SHA256 hash-based message authentication codes
2,5-200		reserved for future assignments
>200		unassigned

KeyLocator

A KeyLocator specifies either Name that points to another Data packet containing certificate or public key or KeyDigest to identify the public key within a specific trust model (the trust model definition is outside the scope of the current specification). Note that although KeyLocator is defined as an optional field in SignatureInfo block, some signature types may require presence of it and some require KeyLocator absence.

KeyLocator ::= KEY-LOCATOR-TYPE TLV-LENGTH (Name | KeyDigest)

KeyDigest ::= KEY-DIGEST-TYPE TLV-LENGTH BYTE+

See Name specification for the definition of Name field.

The specific definition of the usage of Name and KeyDigest options in KeyLocator field is outside the scope of this specification. Generally, Name names the Data packet with the corresponding certificate. However, it is up to the specific trust model to define whether this name is a full name of the Data packet or a prefix that can match multiple Data packets. For example, the hierarchical trust model [BZA+13] uses the latter approach, requiring clients to fetch the latest version of the Data packet pointed by the KeyLocator (the latest version of the public key certificate) in order to ensure that the public key was not yet revoked.

DigestSha256

DigestSha256 provides no provenance of a Data packet or any kind of guarantee that packet is from the original source. This signature type is intended only for debug purposes and limited circumstances when it is necessary to protect only against unexpected modification during the transmission.

DigestSha256 is defined as a SHA256 hash of the Name, MetaInfo, Content, and SignatureInfo TLVs:

SignatureInfo ::= SIGNATURE-INFO-TYPE TLV-LENGTH(=3)
                    SIGNATURE-TYPE-TYPE TLV-LENGTH(=1) 0

SignatureValue ::= SIGNATURE-VALUE-TYPE TLV-LENGTH(=32)
                     BYTE+(=SHA256{Name, MetaInfo, Content, SignatureInfo})

Note that SignatureInfo does not require KeyLocator field, since there digest calculation and verification does not require any additional information. If KeyLocator is present in SignatureInfo, it must be ignored.

SignatureSha256WithRsa

SignatureSha256WithRsa is the basic signature algorithm that MUST be supported by any NDN-compliant software. As suggested by the name, it defines an RSA public key signature that is calculated over SHA256 hash of the Name, MetaInfo, Content, and SignatureInfo TLVs.

SignatureInfo ::= SIGNATURE-INFO-TYPE TLV-LENGTH
                    SIGNATURE-TYPE-TYPE TLV-LENGTH(=1) 1
                    KeyLocator

SignatureValue ::= SIGNATURE-VALUE-TYPE TLV-LENGTH
                     BYTE+(=RSA over SHA256{Name, MetaInfo, Content, SignatureInfo})

Note

SignatureValue size varies (typically 128 or 256 bytes) depending on the private key length used during the signing process.

This type of signature ensures strict provenance of a Data packet, provided that the signature verifies and signature issuer is authorized to sign the Data packet. The signature issuer is identified using KeyLocator block in SignatureInfo block of SignatureSha256WithRsa. KeyDigest option in KeyLocator is defined as SHA256 digest over the DER encoding of the SubjectPublicKeyInfo for an RSA key as defined by RFC 3279.” See KeyLocator section for more detail.

Note

It is application’s responsibility to define rules (trust model) of when a specific issuer (KeyLocator) is authorized to sign a specific Data packet. While trust model is outside the scope of the current specification, generally, trust model needs to specify authorization rules between KeyName and Data packet Name, as well as clearly define trust anchor(s). For example, an application can elect to use hierarchical trust model [BZA+13] to ensure Data integrity and provenance.

SignatureSha256WithEcdsa

SignatureSha256WithEcdsa defines an ECDSA public key signature that is calculated over the SHA256 hash of the Name, MetaInfo, Content, and SignatureInfo TLVs. The signature algorithm is defined in [RFC5753], Section 2.1.

SignatureInfo ::= SIGNATURE-INFO-TYPE TLV-LENGTH
                    SIGNATURE-TYPE-TYPE TLV-LENGTH(=1) 3
                    KeyLocator

SignatureValue ::= SIGNATURE-VALUE-TYPE TLV-LENGTH
                     BYTE+(=ECDSA over SHA256{Name, MetaInfo, Content, SignatureInfo})

Note

The SignatureValue size depends on the private key length used during the signing process (about 63 bytes for a 224 bit key).

This type of signature ensures strict provenance of a Data packet, provided that the signature verifies and the signature issuer is authorized to sign the Data packet. The signature issuer is identified using the KeyLocator block in the SignatureInfo block of the SignatureSha256WithEcdsa. KeyDigest option in KeyLocator is defined as SHA256 digest over the DER encoding of the SubjectPublicKeyInfo for an EC key as defined by RFC 5480. See the KeyLocator section for more detail.

The value of SignatureValue of SignatureSha256WithEcdsa is a DER encoded DSA signature as defined in Section 2.2.3 in RFC 3279.

Ecdsa-Sig-Value  ::=  SEQUENCE  {
     r     INTEGER,
     s     INTEGER  }

SignatureHmacWithSha256

SignatureHmacWithSha256 defines a hash-based message authentication code (HMAC) that is calculated over the Name, MetaInfo, Content, and SignatureInfo TLVs, using SHA256 as the hash function, salted with a shared secret key. The signature algorithm is defined in Section 2 in RFC 2104.

SignatureInfo ::= SIGNATURE-INFO-TYPE TLV-LENGTH
                    SIGNATURE-TYPE-TYPE TLV-LENGTH(=1) 4
                    KeyLocator

SignatureValue ::= SIGNATURE-VALUE-TYPE TLV-LENGTH(=32)
                     BYTE+(=HMAC{Name, MetaInfo, Content, SignatureInfo})

Note

The shared secret key is not included in the signature and must not be included anywhere in the data packet, as it would invalidate security properties of HMAC.

Note

As stated in Section 3 of RFC 2104, shared keys shorter than the SHA256 output byte length (32 bytes) are strongly discouraged.

Provided that the signature verifies, this type of signature ensures provenance that the Data packet was signed by one of the parties who holds the shared key. The shared key used to generate HMAC signature can be identified by the KeyLocator block in SignatureInfo, e.g., by using the Name according to application’s naming conventions. It is the application’s responsibility to establish association between the shared key and the identities of the parties who hold the shared key.

[BZA+13]

(1, 2) Chaoyi Bian, Zhenkai Zhu, Alexander Afanasyev, Ersin Uzun, and Lixia Zhang. Deploying key management on NDN testbed. Technical Report NDN-0009, Revision 2, NDN, February 2013. http://named-data.net/techreports.html.