4/25/2012

X.509 Overview

1. Authentication Applications: X.509 and

Public Key Infrastructure (PKI)

X.509 recommended by ITU-IT.

Part of X.500 directory service standards.
distributed servers maintaining user info database

Defines framework for authentication services.

Dr Joseph Sevilla

directory may store public-key certificates

with public key of user signed by certification authority

MTD 8502 Network Security

Also defines authentication protocols based on the use of

public key certificates.
Uses public-key crypto & digital signatures.
algorithms not standardised, but RSA is recommended

X.509 certificates are widely used.

Used by S/MIME, IP Security, SSL/TLS and SET
2

Public Key Certificates

Generation of Public Key Certificates

For purposes of electronic transactions,

certificates are digital documents.
The specific functions of the Certificate include:
Establish identity: Associate, or bind, a public key to
an individual, organisation, corporate position, or other
entity.
Assign authority: Establish what actions the holder
may or may not take based upon this certificate.
Secure confidential information: e.g. encrypting the
session's symmetric key for data confidentiality.
3

Public Key Certificates

Public Certificates

Typically, a Certificate contains:

a public key,
a name,
an expiration date,
the name of the authority that issued the certificate,
a serial number,
any pertinent policies describing how the certificate was
issued and/or how the certificate may be used,
the digital signature of the certificate issuer,
and perhaps other information.
5

4/25/2012

Certificate Authorities

X.509 Certificates

Certificate Authorities are the repositories for publickeys and can be any agency that issues certificates.

When a sender needs an intended receiver's public key,

the sender must get that key from the receiver's CA.
Elements of a certificate:

A company, for example, may issue certificates to its employees,

a college/university to its students, a store to its customers, an
Internet service provider to its users, or a government to its
constituents.

User certificates are assumed to be created by some

trusted certification authority.
The directory server just provides an easily accessible
location for users to obtain certificates.

version (1, 2, or 3)
serial number (unique within CA) identifying certificate
signature algorithm identifier
issuer X.500 name (CA that created certificate)
period of validity (from - to dates)
subject X.500 name (name of owner)
subject public-key info (algorithm, parameters, key)

X.509 certificates

X.509 certificates

issuer unique identifier (to identify uniquely a certain CA

in case the name has been used by others. v2+)
subject unique identifier (identifies subject uniquely in
case name has been used by different entities v2+)
extension fields (v3)
signature (of hash of all fields in certificate)

notation CA<<A>> denotes certificate for A signed

by CA

10

Obtaining a Certificate

Obtaining a Certificate

Certificates have the following characteristics:

If A does not securely know the public key of X2

Bs CA then Bs certificate is useless.
If both CAs have securely exchanged their own
public keys:

any user with access to the public key of the CA can verify the
user public key that was certified.
only the CA can modify a certificate.

Because they cannot be forged, certificates can be placed

in a public directory.
Once B is in possession of As certificate, B is confident
that messages it encrypts with As public key will be
secure from eavesdroppers.
CA must ensure that its public key is provided to users
securely.
11

A can obtain from the directory X2s certificate signed

by X1 (As CA).
A then obtains the certificate of B signed by X2.

12

4/25/2012

CA Hierarchy

CA Hierarchy Use

If both users share a common CA then they are

assumed to know its public key.
Otherwise CA's must form a hierarchy:
Use certificates linking members of hierarchy to validate
other CA's
Each CA has certificates for clients (forward) and
parent (Reverse).
Each client trusts parents certificates.
Enable verification of any certificate from one CA by
users of all other CAs in hierarchy.
13

14

Certificate Revocation

Authentication Procedures

Certificates have a period of validity. A new certificate

issued just prior to the expiration of the previous
May need to revoke before expiry for reasons like:

X.509 includes three alternative authentication

procedures:
1. One-Way Authentication
2. Two-Way Authentication
3. Three-Way Authentication

1. User's private key is compromised.

2. User is no longer certified by this CA.
3. CA's certificate is compromised.

All use public-key signatures.

CAs maintain list of revoked certificates.

It is assumed that the two parties know each others

public key either by obtaining from the directory or
because it is included in the previous message.

Certificate Revocation List (CRL).

Users should check certificates with CAs CRL to

determine that the certificate has not been revoked.
15

16

One-Way Authentication

Two-Way Authentication

Single transfer of information from A to B. Establishes:

2 messages (A->B, B->A) which also establishes in

addition to the previous messages:

The identity of A and that message is from A.

That message was intended for B.
Integrity & originality of message.

The identity of B and that reply is from B.

That reply is intended for A.
Integrity & originality of reply.

Message must include: timestamp (tA), nonce (rA), B's identity (IDB)
and is signed with As private key (sgnData).
Nonce (unique within the expiration time of the message) used to detect
replay attacks.
The timestamp prevents delayed delivery of messages.

Permits both parties to verify identity of each other.

Reply includes original nonce from A to validate the reply.
Also timestamp and nonce from B.

May also include additional info for B.

e.g. session key E[PUb, Kab].

May also include additional info for A.

17

18

4/25/2012

Three-Way Authentication

X.509 Version 3

Three messages (A->B, B->A, A->B) which enables above

authentication without synchronized clocks.
Has reply from A back to B containing signed copy of nonce from B.
Means that timestamps need not be checked or relied upon.
Easy to detect replay attacks.

Version 2 does not convey all the information needed.

FORD95 lists the following requirements not satisfied:
Subject field is inadequate to convey the identity of a key owner to
a public key user.
Also inadequate for many applications which typically recognize
entities by an e-mail address, URL, etc.
Need to indicate security policy information to enable functions
such as IPSec to relate an X.509 certificate to a given policy.
Need to limit the damage that can result from a faulty or malicious
CA by setting constraints on the applicability of a particular
certificate.
Need to identify different keys used by same owners at different
times. Supports key life cycle management.
19

20

Certificate Extensions

Certificate Extensions

Due to the shortcomings, v3 includes a number of optional

extensions that may be added to the v2 format
Extensions consist of a an ID, criticality indicator (CI) and
an extension value

key and policy information

Ci indicates whether the value can be safely ignored

convey info about subject & issuer keys, plus indicators of

certificate policy
Policy is a set of rules that indicate the applicability of the
certificate

certificate subject and issuer attributes

support alternative names, in alternative formats for certificate
subject and/or issuer
Convey additional information about the certificate subject to
increase certificate confidence

Certificate extensions fall into three main categories:

Key and policy information
Subject and issuer attributes
Certification path constraints

certificate path constraints

allow constraints on use of certificates by other CAs
Includes basic, name and policy constraints
21

22

Public Key Infrastructure

Public Key Infrastructure

Certificates and the collection of CAs will form a Public Key

Infrastructure (PKI).

PKI X.509 (PKIX) has the following elements:

The Domain Name System (DNS) introduced the idea of a distributed

database to identify hosts.
A PKI will fill a similar void in the e-commerce and PKC realm.

While certificates and the benefits of a PKI are most often associated
with electronic commerce, the applications for PKI are much broader:
Secure electronic mail, payments and electronic checks, Electronic Data
Interchange (EDI), secure transfer of Domain Name System (DNS) and
routing information, electronic forms, and digitally signed documents.

A single "global PKI" is still many years away.

Objective behind PKI: enable secure, convenient and efficient
acquisition of public keys

23

End entity/end users and devices

CA: issues and revokes certificates
Registration Authority (RA): can assume a number of
administrative functions from the CA
CRL issuer: optional component that CA can delegate
to publish CRLs
Repository: generic term to denote any method of
storing certificates and CRLs so the can be retrieved by
End entities
24

4/25/2012

Public Key Infrastructure

PKIX Management Functions

Registration: process of user making itself known to the CA before it
is issued keys
Initialization: install key materials before client system can function
appropriately
Certification: issuing certificate and posting it to a repository
Key pair recovery: allows end entities to recover their key pairs from
an authorized backup facility
Key pair update: as key pairs need to be updated regularly and new
ones issued
Revocation request: An authorized body advises a CA of an
abnormal request that requires certificate revocation
Cross certification: Two CAs exchange information used in
establishing a cross-certificate
25

26

Resources
Gary C. Kessler May 1998 (Last updated: 15 July
2008) on:
http://www.garykessler.net/library/crypto.html

Cryptography and Network Security by Stallings, 4

Ed

27