Public Key Infrastructure (PKI)

Public key infrastructure become the central

focus of modern security mechanism on
the internet .
PKI is closely related to the idea of
asymmetric key cryptography mainly
including message digest, digital signature
and encryption services.
The requirement to enable all these services
is the technology of digital certificate.
 PKI
Validating digital certificate is both crucial
and complex. Special protocols such as
CRL,OCSP and SCVP are designed to
handle this task.
PKIX and PKCS are the two popular
standards for digital certificate and PKI.
A problem of key exchange and key
agreement is solved by using digital
certificate.
 Digital Certificate
Conceptually, we can compare digital
certificate to the document such as our
passport or driving license, these help us
in establishing our identity such as full
name, nationality , birth date ,photograph.
A Digital certificate is a small computer file.
Digital certificate shows association
between my public key and me.
 Digital Certificate
A Digital certificate must contain the user
name and user’s public key.
Example of digital certificate:
Subject name:
Serial number :
Valid from:
Valid to:
Issuer name :
Public key :
 Digital Certificate
Every digital certificate has a unique serial
number.
Two digital certificate issued by same issuer
can not have same serial number .
Certification Authority:
A certification authority is a trusted agency
that can issue digital certificate.
The authority of acting as a CA has to be
with someone who everybody trusts.
 Digital Certificate
Usually , CA is a reputed organization , such
as passport office , financial institution
,software company etc.
Two of the world’s most famous CA’s are
VeriSign and Entrust.
Safescrypt Limited ,a subsidiary of Satyam
infoway Limited ,became the first indian
CA .
 Digital certificate
A Standard called as X.509 defines a structure of
digital certificate. The International
telecommunication union came up with this
standard .At that time it was a a part of another
standard called X.500. since then, X.509 was
revised twice ,the current version of standard is
version 3,called as X.509V3.
Figure shows structure of X.509 V3.there are
different fields which specifies version of
standard contains which field.
 X.509
Version 1 of of the X.509 standard
contained seven basic fields ,version 2
added two more fields and version 3
added one more field. these additional
fields are called as extensions.
Version: Identifies a particular version of the
X.509 protocol, which is used for this
digital certificate. This field can contain
1,2,3 etc.
 X.509
Certificate serial Number:
Contains a unique integer number, which is
generated by CA.
Signature Algorithm Identifier:
Identifies the algorithm used by CA to sign
this certificate.
Issuer Name:
Identifies the distinguished name of the CA
that create and signed this certificate .
 X.509

Validity:
Contains two date time values which specify the
time frame within which the certificate should be
considered as valid . These values generally
specify the date and time up to seconds or
milliseconds.
Subject Name:
Identifies the distinguished name of the end entity
to whom this certificate refers. this field must
contain an entry unless an alternative name is
defined in version 3 extension .
 X.509
Subject Public key Information :
Contains the subject public key and
algorithm related to that key. This field can
never be blank.
These are fields in version 1 some fields are
added,
Issuer Unique Identifier: Helps to identify
C.A uniquely if two or more CAs have
used the same issuer name over time
 X.509

Subject Unique Identifier: Helps to identify

subject uniquely if two or more subjects
have used the same subject name over
time.
The digital certificate standard certifies that
The same issuer name or subject name
should never be used more than once in
the first place. These are fields added by
version 2 & these are optional & helps to
distinguish between 2 issuers
 X.509 V3
Following are the various fields of X.509
digital certificate version 3
Authority Key Identifier: A CA may have
multiple private public key pair. This field
defines the which of the key pairs used to
sign this certificate.
Subject Key Identifier: A subject may have
multiple public private key pair. This field
defines which of those key pairs are used
 X.509 V3
to sign so that corresponding key can be
verified.
Key Usage: Defines the scope of the
operation of the public key of particular
certificate,e.g. we can specify whether
particular public key can be used for all
cryptographic operations or only for
encryption or only for the Diffie-Hellman
key exchange etc.
 X.509 V3
Extended Key Usage: Can be sued in addition
to or in place of key usage field.Specifies
which protocols this certificate can
interoperate with e.g. these protocols are
transport layer security, client
authentication, server authentication etc.
Private Key usage Period: Allows defining
different usage period limit for the private
& public key corresponding to this
certificate.
 X.509 V3
If this field is empty, the validity of private
key corresponding to this certificate is
same as that of public key.
Certificate Policy: Defines policies &
optional qualifier information that the CA
associates with a given certificate
Policy mapping: Used only when the
subject of given certificate is also a CA i.e
when CA issues a certificate to another
CA
 X.509 V3
The certifier CA specifies which of its
policies the CA being certified must allow
Subject Alternative Name: Optional
defines 1 or more alternative names for
the subject of the given certificate.
However if the subject name field in the
main format is empty, this field must
contain some value.
 X.509 V3
Issuer Alternative Name: Optionally
defines 1 more alternative names for the
issuer of the given certificate.
Subject Directory Attributes: Can be used
to provide additional information about
subject such as subject phone/fax
number, Email Id etc.
Basic Constraints: Indicate whether the
subject in this certificate may act as CA.
 X.509 V3
This field also specifies if the subject can,in
turn, allow other subject to become CAs
For instance, if CA X is issuing the particular
certificate to another CA Y,X can not only
specify if Y can act as CA & issue
certificate to other subjects, but also
whether Y can grant the authority of
becoming CA to other subjects, in turn
 X.509 V3
Name Constraint: Specifies the name
space.
Policy Constraint: Used only for the CA
certificate
 Certificate Hierarchy
Certification Authority Hierarchy is also
called chain of trust, all the CAs are
grouped in to multiple hierarchy
CA Hierarchy begins with the root CA.
Root CA has one or more second level CA’s
below. Each second level CA can have
one or more third level CA which in turn
can have lower level CA’s & so on.This is
like a reporting hierarchy in organization,
 Certificate Hierarchy
Where CEO or managing director is the
highest authority. Many senior managers
report to CEO & many managers report to
senior managers. Many people would
report to each manager & so on.
This sort of hierarchy release the root CA
from to have manage all possible digital
certificates. Instead the root CA can
deligate this job to second level CA & this
 Certificate Hierarchy
Delegation can be region wise e.g. one
second level CA can be responsible for
western region & another for eastern
region etc.
Each of these second level CAs can appoint
third level CAs statewide within that
region. each third level could delegate its
responsibilities to 4th level CAs city wise &
so on
 Cross Certification
Root CAs are for different for different
countries.one country can have multiple
countries e.g. Root CAs in US are
Verisign,Thawte & the US postal service.
In such cases there is no single root CA
which can be trusted by concerned
parties.To solve this problem an
alternative is there for cross
certification.This came about because
 Cross Certification
The single monolithic CA certifying every possible
user in the world is quite unlikely instead the
concept of the decentralized CAs for different
countries, political organization & business is far
better. This allows CAs not only worry smallest
population of the user but also work
independently. Moreover cross certification
allows CAs & end users from different public key
infrastructure domain to interact.
 Cross Certification
Cross Certificate are issued by the CAs to
create non hierarchical trust path.
Figure shows, the root CAs Alice & Bob are
different but they have cross certified each
other. This means that Alice’s root CA has
obtained a certificate for itself Bob’s root
CA.Now Alice’s software trusts only her
own root CA,it is not a problem since
Bob’s root CA is certified by Alice root CA.
 Cross Certification
The technology of the certificate hierarchy,
self signed certificate & cross certification,
virtually any other can verify any other
user’s digital certificate & based on
that,deside to either trust it or reject it.
 X.500 Directories
The X.500 directory service is a global
directory service. Its components
cooperate to manage information about
objects such as countries, organizations,
people, machines, and so on in a
worldwide scope. It provides the capability
to look up information by name (a white-
pages service) and to browse and search
for information (a yellow-pages service).
 X.500 Directories
The information is held in a directory
information base (DIB). Entries in the DIB
are arranged in a tree structure called the
directory information tree (DIT). Each
entry is a named object and consists of a
set of attributes. Each attribute has a
defined attribute type and one or more
values. The directory schema defines the
mandatory and optional attributes for each
class of object (called the object class).
 X.500 Directories
Each named object may have one or more
object classes associated with it.
The X.500 namespace is hierarchical. An
entry is unambiguously identified by a
distinguished name (DN). A distinguished
name is the concatenation of selected
attributes from each entry, called the
relative distinguished name (RDN),
 X.500 Directories
in the tree along a path leading from the root
down to the named entry.
Users of the X.500 directory may (subject to
access control) interrogate and modify the
entries and attributes in the DIB (directory
information base).
 X.500 Directories
The Directory model:
X.500 uses a distributed approach to realize
a global Directory Service. The idea is that
local (communication oriented) information
of an Organisation is maintained locally in
one or more so-called Directory System
Agents (DSAs).
 X.500 Directories
Note that 'local' is a flexible expression here:
it is possible that one DSA keeps
information of more than one organisation.
The opposite is also possible: Directory data
of one large organisation can reside in
multiple DSAs, which is still considered
local from a service-provision point of
view.
 X.500 Directories
A DSA is essentially a database:
• in which the information is stored in a
structure according to the X.500
information model .that has the ability,
where necessary, to exchange data with
other DSAs through use of the Directory
System Protocol (DSP) of the X.500
recommendation set.
 X.500 Directories
. 'organisations' are defined, and below an
organisation 'individuals', or additionally,
'organisational units', are defined (see the
simplified illustration below where only
three countries and no organisational units
are presented).

The DIT is a representation of the global

Directory:
X.500 Directories
 X.500 Directories
Each DSA holds part of the global Directory and is
able to find out, through the hierarchical DIT
structure, which DSA holds a certain part of the
Directory. This is done by means of 'knowledge
references'. Some implementors have chosen to
use an alternative approach for the X.500 (1988)
version of this concept (since they thought it was
not appropriate), which resulted in
interoperability problems between DSA
implementations by different vendors.
 X.500 Directories
The information model :
The X.500 standard defines the information
model used in the Directory Service. All
information in the Directory is stored in
'entries', each of which belongs to at least
one so-called 'object class'. In the White
Pages application of X.500 object classes
are defined, such as 'country',
'organisation', 'organisational unit' and
'person'.
 X.500 Directories
The actual information in an entry is
determined by so-called 'attributes' which
are contained in that entry. The object
classes to which an entry belongs define
which types of attributes an entry may use
and hence, what information is specific for
entries belonging to that object class.
The object class 'person' for example,
allows attribute types like 'common name',
 X.500 Directories
'telephone number', and 'e-mail address' to
be used and the object class 'organisation'
allows for attribute types like 'organisation
name' and 'business category'. Depending
on its type, an attribute can take one or
more values.
At least one attribute value of the entry is
used to specify a name for an entry. The
entry of a person is usually named after
the value of the attribute type 'common
 X.500 Directories
An example of an entry Attribute type Attribute value

belonging to the Object Class: top

object class 'person' person

is: Common Peter Jurg

Name: P. Jurg
Surname: Jurg

Postal Address: SURFnet bv

Postbus 19035
NL-3501 DA
Utrecht
Telephone +31 30 305305
Number:
Mail: jurg@surfnet.nl
 X.500 Directories
The names that occur in the DIT are simply the
names of entries. Hence, the entry shown in
figure 2.1 occurs in the DIT as the node 'Peter
Jurg' below the node of the organisation
'SURFnet'.The name of an entry must be unique
at the level in the sub-tree of the DIT to which
the entry belongs. So if there are two people
called Peter Jurg at SURFnet, they must have a
different first value for the attribute type
Common Name in their entries.
 X.500 Directories
Core Services: X.500
• Directory System Agent (DSA). The DSA is the
core directory server. A single DSA will
typically hold only a part of the data available
in the total directory.
• Directory User Agent (DUA). A DUA is the
client process that accesses information in the
directory. This could be a (human) user
interface or embedded in another application.
 X.500 Directories
• Directory Access Protocol (DAP). DAP is the
protocol which a DUA uses to access one or
more DSAs. Thus it is the protocol which
allows the client/server model of the X.500
directory.
• Directory System Protocol (DSP). DSP is the
protocol that DSAs use to talk to each other,
and it carries the same operations as DAP,
along with some DSA control information.
 X.500 Directories
• These interactions are governed by a set
of procedures for distributed operations,
which enable a set of DSAs to provide a
coherent service, with the DUA unaware
of how the directory data is distributed
between DSAs.