Public key Info Base (PIB) Service¶

Public Key Info Management¶

NDN data packets are secured through digital signatures.
In order to generate a valid signature, an NDN application needs to know not only the correct key to use but also the correct public key information that should be put into the KeyLocator of a data packet.
The information needs to be managed locally on the system where the application is running.

The information related to keys is managed at three granularities: identities, keys, and certificates.
A key is always associated with a namespace, called "identity".
An identity however may have more than one keys.
Each key is named as /<Identity>/[KeyId].
The KeyId uniquely identifies a key which belongs to the Identity.
Among these keys, only one is the default key of the identity.
If only identity is provided when signing a packet, the default key of the identity will be used to sign the packet.

A certificate is always associated with the key in the certificate
If a certificate is provided when signing a packet, the corresponding private key should be used to sign the packet
and the name of the certificate name may be put into the KeyLocator of the packet.

A key may have more than one certificates (e.g., certificates may be issued by different parties).
Among these certificates, only one is the default certificate of the key.
The default certificate of the default key of an identity is the default certificate of the identity.
If only identity is provided when signing a packet, the name of the default certificate of the identity may be put into the KeyLocator of the packet.

All the information above may be accessed by different APIs and applications on the same system,
therefore it is desirable to make the information provisioning as a system service.

Since public keys and certificates are supposed to be publicly available,
the service also serves as a local storage of certificate and public keys,
besides providing the public key related information.

PIB management model¶

The public key information of each system user is managed separately in PIB.
For now, PIB service is a system service (i.e., run by root).
PIB service may be separated into several user services (i.e., run by each user) in the future.

Each user has three tables in PIB: identity table, key table, and certificate table.
The public key information of a user is managed in these tables.
Identity table consists of two columns: identity (primary key) and default_key_id.
Key Table consists of five columns: identity, key_id, key_type, key_bits, and default_cert_name.
The combination of identity and key_id is the primary key of key table.
Certificate table consists of four columns: certificate_name (primary key), identity, key_id, and certificate_data.

Besides the tables for each user, PIB has two more management tables: user table and certificate_publishing table.
User table stores user's local management key (we will discuss it later) and user's default identity
Each user has its own default identity.
From the default identity, the default key and certificate of the user can be derived.

The read access to a user's public key information is not restricted,
while the write access to a user's public key information requires authentication.
The write access is expressed as signed commands.
The signing key can be authenticated only if the key already exists in PIB.
Each key has its own write access privilege which is defined as:

• The root user has the root key of the local system. The root key has the highest privilege, i.e., its owner is allowed to change anything in PIB. The identity of the root key is /localhost, and the name of the root key should be /localhost/[KeyId].
• Each user has its own local management key. The local management key is allowed to change anything in the user's PIB info including the three tables and user's own entry in the user table. The identity of the user local management key is /localhost/user/[UserName], and the name of the key should be /localhost/user/[UserName]/[KeyId]. Note that the local management key of the root user is the root key.
• All the other keys are called regular keys. A regular key is allowed to change keys/certificates with identities under the key's own namespace, e.g., a key with the identity /ndn/ucla/alice is allowed to add a key with the identity /ndn/ucla/alice/chat but is not allowed to change a key with the identity /ndn/ucla/bob.

PIB Service Protocol¶

PIB service provides an interface to NDN applications for public key info lookup.
The interface is defined in terms of NDN packets (interest/data).
A query to PIB is expressed as a signed interest.