Line Information Database (LIDB)

A Line Information Database (LIDB) is a record kept by the local telephone service provider that consists of a number of details for each customer. The categories included in a Line Information Database include subscriber information, such as a service profile, name, address and credit card validation information. For instance, caller ID name is stored in LIDB. The acronym LIDB often is pronounced "lid-bee."

LIDB is used in the United States and Canada by traditional telephone companies to store and retrieve Caller ID records. Local phone switches, also known as Class 5 switches, use SS7 signaling protocol to query these centralized databases and pass this information during call set up. The information includes subscriber's information such as service profile, 10-digit line number, service provider ID, equipment indicator and billing specifications.

Internetwork Calling Name (ICNAM) is a service that works in the same manner as LIDB. With ICNAM, rather than returning calling card or bill name validation data, the query data returned is the name of the calling party.

There are two main components to the Caller ID info seen by a receiver of a call: the number and the name. The number is the "easy" part, but the name takes a little more effort to set up.

• Setting your own CNAM within your PBX has no effect in the U.S. and many other countries. Only the CID number is transmitted to the terminating carrier, and those carriers then look up the name from a database.

• If you will be making calls to Canadian numbers, you can pass the Caller ID Name from your PBX.

In the U.S., CNAM information depends on what is stored in a Line Information Database (LIDB), which contains records of numbers and names. There are many different databases, and each carrier decides which database to use.

ssl certificate 101

A certificate verifies that an entity is the owner of a particular public key.

Certificates that follow the X.509 standard contain a data section and a signature section. The signature section is to verify the certificate authenticity, and the data section includes such information as:

• The Distinguished Name of the entity that owns the public key
• The Distinguished Name of the entity that issued the certificate
• expiration info
• The public ke

You can obtain a certificate from a Certificate Authority (CA) such as VeriSign, Godaddy etc. Alternately, you can create a self-signed certificate, in which the owner and the issuer are the same.

An organization that issues certificates can establish a hierarchy of CAs. The root CA has a self-signed certificate. Each subordinate CA has a certificate that is signed by the next highest CA in the hierarchy. A certificate chain is the certificate of a particular CA, plus the certificates of any higher CAs up through the root CA. (certificate chain)

https://docs.oracle.com/cd/E19509-01/820-3503/ggbgc/index.html

ssl certificate and private key

In normal key-pair based PKI (public key infrastructure), there are private key and public key as a pair (Use one key to encrypt, and use the other key to decrypt). In a certificate-based system, there are private key and certificate.

Public-key cryptography is based on the concept of a key pair, which consists of a public key and a private key. Data that has been encrypted with a public key can be decrypted only with the corresponding private key. Conversely, data that has been encrypted with a private key can be decrypted only with the corresponding public key.

Certificate holds more information than the public key. The certificate is a wrapper for the public key, in addition, it contains additional information such as issuer, what the certificate is supposed to be used for, and other types of metadata. Certificate also contains signature to help verify the public key ownership.

Typically, a certificate is signed by a certificate authority (CA) using CA's private key. This verifies the authenticity of the certificate. Company A's public key signed with a valid CA's private key is called company A's certificate.

Servers are typically configured with certificates issued by well-known issuers called Certificate Authorities (CAs). Similar to a server, a CA has a certificate and a private key. When issuing a certificate for a server, the CA signs the server certificate using its private key. The client can then verify that the server has a certificate issued by a CA the client trusts. Client (like browsers) generally contains a list of well known CAs that it trusts.

In short, server has a certificate signed by trusted CA, The client only believes the server certificate if it is signed by a certificate authority it trusts. Because CAs are trusted, their own Public Keys used to verify the signatures of issued Digital Certificates are widely published. 

So practically, during ssl handshake, what happens is instead of sending its own public key, the client sends the symmetric key (session key) encrypted by the public key of the server. Server decrypts it with its private key and it gets to know the symmetric key. Now the further communication happens with this symmetric key encryption and decryption.