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 the corresponding user's PIB tables.
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 change 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.
The query interest is defined as:

/localhost/pib/[UserName]/[Verb]/[Param]/<signed_interest_security_components>

UserName indicates the tables in which the query should apply.
Verb indicates the access operation.
Three types of operations are defined: get (Read), search (Read), and update (Write).
The operation get and search are quite similar to each other.
The only difference is that the response to get is the queried entity per se while the response to search operation is the existence (a boolean value) of the queried entity.
Param is a TLV block containing parameters of the query.
Different types of operations have their own parameters.

Get Parameters¶

For get operation, Param is defined as:

   GetParam := Type
               Filter
     Filter := Name | DefaultOf | ListOf
  DefaultOf := EntityDesc
     ListOf := EntityDesc
 EntityDesc := Type
               Name
       Type := ID | KEY | CERT

Type indicates which table the query will be applied eventually.
Filter indicates how to apply the query.
When Name is specified in Filter, PIB will directly lookup the entry with the same name in the table indicated by Type.
When DefaultOf is specified in Filter, PIB will first derive the name of the target through the default information and lookup the entry in the table indicated by Type.
When ListOf is specified in Filter, PIB will collect all the entries that satisfy the condition specified in ListOf.
Here are some examples of GetParam:

GetParam 
{
  Type: KEY
  Filter 
  {  
    Name: /ndn/edu/ucla/ksk-1234
  }
}

The example above is a query to get a key with the name /ndn/edu/ucla/ksk-1234.

GetParam
{
  Type: CERT
  Filter 
  { 
    DefautOf 
    {
      Type: ID
      Name: /ndn/edu/ucla/alice
    }
  }
}

The example above is a query to get the default certificate of an identity /ndn/edu/ucla/alice.

GetParam
{
  Type: CERT
  Filter 
  { 
    ListOf 
    {
      Type: KEY
      Name: /ndn/edu/ucla/ksk-1234
    }
  }
}

The example above is a query to get a list of certificates of a key /ndn/edu/ucla/alice.

Search Parameters¶

The parameters of search operation is quite similar to get operation except that there is no ListOf filter.

SearchParam := Type
               Filter
     Filter := Name | DefaultOf
  DefaultOf := EntityDesc
 EntityDesc := Type
               Name
       Type := ID | KEY | CERT

Update Parameters¶

The parameters of update operation are defined as:

UpdateParam := Entity
               DefaultOpt
     Entity := Identity | PublicKey | Certificate
   Identity := Name
  PublicKey := Name
               Bytes
Certificate := Bytes
 DefaultOpt := USER_DEFAULT | ID_DEFAULT | KEY_DEFAULT | NO_DEFAULT

The operation, once validated, add or update an entry in the corresponding table
and change the default setting according to DefaultOpt.

TLV-TYPE assignments¶

Type	Assigned value	Assigned value (hex)
GetParam	128	0x80
SearchParam	129	0x81
UpdateParam	130	0x82
Type	131	0x83
Filter	132	0x84
Name	133	0x85
DefaultOf	134	0x86
ListOf	135	0x87
EntityDesc	144	0x90
Entity	145	0x91
Identity	146	0x92
PublicKey	147	0x93
Certificate	148	0x94
Bytes	149	0x95
DefaultOpt	150	0x96

Constant value assignments¶

For type Type:

Constant	Assigned value	Assigned value (hex)
ID	0	0x00
KEY	1	0x01
CERT	2	0x02

For type DefaultOpt:

Constant	Assigned value	Assigned value (hex)
NO_DEFAULT	0	0x00
USER_DEFAULT	1	0x01
ID_DEFAULT	2	0x02
KEY_DEFAULT	3	0x03