Chapter 9 Certificates and PKI

Cryptography and Security Services:
Mechanisms and Applications
Chapter 9
Certificates and Public-
Key Infrastructure
Manuel Mogollon
m_mogollon@verizon.net
M. Mogollon – 1
Session 7 – Contents
• Certificates
 X.509 Basic Certificate Fields
 RSA Certification
• Public Key Infrastructure
 PKI Management Components
 CA Trust Models
 Encryption Algorithms Supported In PKI
2
Certificates PKI Life-cycle Processes Trust Models Algorithms
M. Mogollon – 2
Authentication and Confidentiality
Encipher
Sender’s Session
Private Key RSA
Key
Hash Encipher Digital
RSA Signature Digital Envelope
Cleartext Encipher Signed Cipher
Hash DES
Message
Message
SHA-1
Sender’s
Certificate
Message Sender
Digital Envelope
Recipient
Decipher
Sender’s
Public Key Sender’s Session
Decipher
DSS / RSA Certificate Key
Digital Decipher
DES Signed Cipher
Signature
Message
Hash Deciphered
SHA-1 Message
Hash Hash
Verification Yes/No
3
M. Mogollon – 3
What is a Public Key Certificate?
public key certificate / n. Information provided by

an issuing organization, a Certificate Authority, that
has a copy of the end-user’s public key signed by the
Certificate Authority, the hash value of the end-user’s
public key, the name of the key’s owner, and a digital
signature of the Certificate Authority. Certificates are
used to identify the owner of a particular public key.
4
M. Mogollon – 4
Certificates
• Secrecy of the public key is not required.
• Authenticity of the public key is necessary to avoid spoofing and
playback attacks.
• A public key can be authenticated (signed by a Certificate
Authority).
• A user can send his public key with a certificate which can then be
used to verify the authenticity of the public key.
• Certificates may also include additional user information.
• Any user with access to the public key of the CA can recover the
user public key that was certified.
• No party other than the CA can modify the certificate without being
detected.
Certificates provide a safe method of distributing public keys via
electronic media.
5
M. Mogollon – 5
Certificates
Alice’s Computer Certificate Authority
Random
Number Alice’s info and public key
Generator Authority’s Public Key
Alice’s Public Key
Generate
s
Sign
Keys Authority’s Private Key
Alice’s Private Key
Signed certificate
Certificate Authority’s
Public Key
Decipher
Alice I am Alice. This is my

certificate to prove it. It Alice’s public key and info
includes my public key.
Who certifies the Certificate Authority’s public key?
6
M. Mogollon – 6
X.509 Certificate
Certificate version
Certificate serial number
ID of the algorithm used by the
issuer (CA) to sign the certificate
CA’s name issuing the certificate
Certificate validity period (not
before, not after) A
End-entity’s name S R
Subject’s
Certificate N A
Subject public key information Information 1 D
Issuer CA’s unique ID (optional) + I
X
End-entity’s unique ID (optional) D
Hash Digital 64
Extensions (optional) Encipher Signature E
SHA-1
Authority-Key Identifier R
Subject-Key Identifier Certificate
● Authority’s
Private Key
ASN1: Abstract Syntax One Notation

DER: Distinguish Encoding Rules (tag, length, value)
7
M. Mogollon – 7
RSA Certification
• The Certificate Authority generates its own secret prime numbers,
pca and qca, its own secret encryption exponent, PrivCA, and its
corresponding public decryption exponent, PubCA.
• The Certificate Authority's public numbers, PubCA and
NCA (NCA = pCA . qCA), are provided to all users in the network.
• The CA certifies Alice's public key and identification number by
computing the certificate public number of Alice:
Priv
C Alice = ( Ident Alice , Pub Alice ) ca mod N CA
• Upon receiving the certificate, Alice verifies the certificate by
checking:
( Ident Alice , Pub Alice ) = C Alice Pub ca mod N CA
• When Alice wants to establish a secure communication with Bob,
she sends her certificate CA to Bob and, since he has PubCA and
NCA, then Bob can obtain Ident Alice and Pub Alice by computing the
following: Pub
( Ident Alice , Pub Alice ) = (C Alice ) CA
mod N CA
8
M. Mogollon – 8
What is a PKI?
public-key infrastructure / n. (abbr. PKI) (1) a mechanism

for (a) establishing trust according to a defined trust
model; (b) making entities uniquely identifiable within
a domain; (c) distributing information regarding the
validity of the binding between a particular key pair
and an entity.* (2) An authentication mechanism.
PKI is about managing certificates and keys

during their complete life cycles; as well as
the entities involved.*
* Adams, C., Lloyd S. “Understanding PKI”
9
M. Mogollon – 9
PKI
• When public-key is used, it is necessary to have a

comprehensive system that efficiently delivers security
services such as confidentiality, access control, data
integrity, authentication, and non-repudiation in a
cohesive manner.
• That system is called Public Key Infrastructure or PKI.
• PKI enables organizations to set-up and define secure
networks in a consistent manner across a wide variety
of applications.
10
M. Mogollon – 10
Public Key Infrastructure
Functions Elements
• Manages the complete life • A Certificate Authority
cycle of keys and certificates. • A certificate repository
• Provides key backup and • A certificate revocation system
recovery.
• Updates automatic key pairs
• Key backup recovery
and certificates • Support for non-repudiation of
• Manages key histories digital signatures
• Automatic update of key pairs
• Supports cross-certification
and certificates
• Management of key histories
• Support for cross certification
• Open standards and support
for legacy applications.
11
M. Mogollon – 11
PKI Management Model
1. Alice registers with the certificate
Certificate Authority / authority and applies for a
Registration Authority Repository Site certificate.
2. The CA verifies Alice’s identity
and issues a certificate.
3
3. The CA publishes the certificate
at a repository site
4. Alice sends her enciphered
message and certificate to Bob.
1 2 5 6 The message was signed with
Alice’s private key to ensure
authenticity, message integrity,
and non-repudiation.
Enciphered
Message
5. After receiving the message, Bob
goes to the repository site to
Digital check the authenticity of Alice’s
Signature certificate.
4
7
Alice Bob 6. The repository site gives the
status of Alice’s certificate.
7. Bob verifies the message’s
integrity using Alice’s public key.
12
M. Mogollon – 12
PKI Management Entities
Certificate
Authority -2
Publish Certificate
Publish CRL Certificate Revocation Certificate Out-of-band

R List (CRL) Issuer Authority -1 publication
e
p Publish Registration
o Authority
s Certificate
I
t
o
r PKI Users
y
S
I
T
e
Search, Read End-Entity
(PKI User)
Published Certificates Out-of-band
loading
13
M. Mogollon – 13
PKI Management Model
• End-Entities (PKI Users)
 An end-entity is a user of PKI certificates and/or an end-user system that is the subject
of a certificate.
• Certification Authority
 The identity and public key of each PKI user can be authenticated (signed) by a
Certificate Authority.
 A CA can issue several kinds of certificates including: User (end-entity) certificates, CA
certificate (a certificate for itself or for another CA), and cross certificates (an
authentication process across security domains).
• Registration Authority
 An RA is an optional system to which a CA can delegate certain management
functions.
 Functions will vary from case to case, but they may include the end-entity verification
process, personal authentication, token distribution, revocation reporting, name
assignment, key generation, archival of key pairs, etc.
 RAs do not issue certificates or CRLs.
• Repository Site
 The repository site is a system or collection of distributed systems that stores
certificates and Certificate Revocation Lists (CRLs) and serves as a means of
distributing these certificates and CRLs to end-entities.
 Certificates are stored at a repository site so that applications can retrieve them on
behalf of a user.
14
M. Mogollon – 14
PKI Management Requirements
1. Conform to the ISO /IEC 9594 -8 / ITU – T X.509 standard.
2. Update regularly any key pair without affecting any other key pair.
3. Kept to a minimum the use of confidentiality (encryption) in order to ease regulatory
problems.
4. Allow the use of different industry-standard cryptographic algorithms.
5. Allow the generation of key pairs by end-entity, the CA, or the RA.
6. Support the publication of certificates by the end-entity concerned, by an RA or by a
CA
7. Support the production of Certificate Revocation Lists (CRLs) by allowing certified
end-entities to make requests for the revocation of certificates.
8. Use a variety of "transport" mechanisms, including specifically mail, http, TCP/IP
and ftp.
9. The CA is the final authority for certification creation.
10. Support scheduled, non-compromised CA key updates.
11. The CA itself may in some implementations or environments, carry out the functions
of an RA.
12. An end-entity requesting a certificate containing a given public key must be able to
demonstrate possession of the corresponding private key value.
15
M. Mogollon – 15
Certificate Life-Cycle
Initialization
• Key pair generation
• Registration
• Certificate creation
• Key & certificate
distribution Issued
• Certificate • Certificate retrieval
dissemination • Certificate validation
• Key backup
• Key recovery
• Key update
• Certificate update Cancellation
• Certificate expiration
• Certificate revocation
• Key history
• Key archive
16
M. Mogollon – 16
Key Lifecycle Management
Initialization
Key Generation
Certificate
Certificate or Validation
Issuance
Key Usage
Key Expiration
Key Update
17
M. Mogollon – 17
Certificate Life-Cycle
Certificate Key Certificate

Application Generation Creation
Key Recovery Certificate

and Update Distribution
Dissemination
Certificate End-Entity
Certificate
and Certified Certificate
Expiration
Key Usage Acceptance
Certificate Certificate Certificate

Revocation Suspension Resumption
18
M. Mogollon – 18
Digital Signature
2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 …. 2021
Pair Key
Signed Document 1
Document Document 2
Public Key in
Certificate
Certificate
Renewed
Certificate
(s)
Certificate Policy Example:
The pair key lifetime is 5 years.
The digital signature (public key) is valid for 10 years.
A certificate must be renewed every year.
19
M. Mogollon – 19
PKI Management Operations
PKI Management Entities
C
e Certificate
r Authority -2
t Publish Certificate • Cross-certification request
I • Cross-certificate update
f
I Publish CRL Certificate Revocation
c Certificate Out-of-band
a List (CRL) Issuer Authority -1 publication
t
e Publish Registration 5
s Certificate Authority 4
1, 3 7 8
R 2, 6
e
p
o PKI Users
s • Initialization 1 Registration Form Request
I • Registration 2 Registration Form Replay
3 Registration Form Submission.
t • Certification 4 Registration Setup Request
o • Issuance 5 Registration Setup Results
r • Key Pair Recovery and Update 6 Registration Results
y • Certificate Renewal and update 7 Certificate Request
• Certificate Revocation Request 8 Certificate Response
&
Search, Read End-Entity
C (PKI User)
R Published Certificates Out-of-band loading
L
CRL: Certificate Revocation List
20
M. Mogollon – 20
End Entity−CA/RA Processes Exchanged
4
Certificate
• Registration 5
Authority -1
 Identity of the end-entity is established and verified. Registration

Authority
• Key Pair Generation
 Generation of public key pair, either by the end-entity, 1 2 3 6 7 8
the RA, or by the CA. In some environments, a

trusted-party may generate the key pair. End Entity
1
(PKI User)
 If the key-pair is going to be used for non-repudiation, 1 Registration Form Request
then it should be generated by the end-entity, the 2 Registration Form Replay
3 Registration Form Submission.
owner of the public-key pair. 4 Registration Setup Request
5 Registration Setup Results
6 Registration Results
• Certificate Creation 7 Certificate Request
 Only the CA can generate certificates. 8 Certificate Response
• Certificate and Key-pair Dissemination

 Certificate is sent to the end-entity using physical delivery, off-line distribution.
 Certificate is sent to an end-entity application (S/MIME), online distribution.
 Key-pair is sent to the end-entity, if the key-pair was generated by the CA.
• Key Backup (Optional)
 Key pair is stored by a trusted third key.
21
M. Mogollon – 21
End Entity−CA/RA Processes Exchanged
• Key Pair Recovery
 Key pair recovery allows end-entities to recover key material from a CA or RA
when they lose key material or forget passwords, or when the devices where
key material are stored get corrupted.
 Key pair backup and recovery refers to the encrypting key pair; the
organization can recover the end-entity private key if the key is lost, so loss of
a private key doesn’t mean loss of valuable data.
 The backup and recovery of signing keys should not be allowed because it
destroys the basic requirement of non-repudiation.
• Key Pair Update
 The key pair update process supports the regular update of every key pair.
Key pairs need to be updated regularly (i.e., replaced with a new key pair),
and a new certificate should be generated for the new key pair.
• Certificate Renewal and Update
 Certificates are assigned a valid time period. When a certificate expires, it can
be renewed or updated, Renewal means that the public key and information
remain the same and a new certificate is issued. Update means that a new
public key pair and information are generated and a new certificate is issued.
22
M. Mogollon – 22
End Entity – Repository Processes Exchanged
C • Certification Retrieval
e
r  Certification retrieval is the process by which an end-
t entity retrieves an end-entity certificate to either (1)
I
f encrypt data destined for another end-entity using the
I public key included in the certificate, or (2) verify a
c digital signature received from another entity.
a
t • Certificate Validation
e
s  The certificate was issued by a trusted CA. The
C
certificate needs to be validated.
R  The certificate has not been changed.
L
 The certificate has not expired.
R  The certificate has not been revoked. The CRL should
e
p be check.
o
s
I Search, Read End Entity
t (PKI User)
o Published Certificates
r
y
23
M. Mogollon – 23
CA1 – CA2 Processes Exchanged
• Cross Certification
 “Alice” has been certified by CA1 and “Bob” has been
certified by CA2. Certificate
 Alice trusts only the certificates signed by CA1, and Authority -2
Bob trusts only the certificates signed by CA2. Cross-
 It is not possible for Alice to certify Bob because Alice Certification
and Bob are in different domains. Certificate
 If CA1 cross-certifies CA2, Alice can extend her trust to Authority -1
the end-entities certified by CA2, including Bob.
• Inter-domain cross-certificate
 When the subject and issuer CAs belong to different administrative domains.
• Intra-domain cross-certificate
 When the CAs belong to the same domain.
• Cross certification controls are possible
 Trust can be extended to certain groups within an organization within another CA;
e.g., organization “A” may set cross certification so their customer account
managers can only accept certificates from the purchasing department of
organization “B”.
24
M. Mogollon – 24
CRL Structure
CRL version
ID of the algorithm used by the
issuer (CA) to sign the CRL
CA’s name issuing the CRL
Date & time this CRL was issued A
S R
Date & time next CRL will be issued Subject’s
Certificate N A
List of revoked certificates (S/N, Information 1 D
revocation time) + I
Extensions (optional) X
Authority Key Identifier Hash Digital D 64
Subject Key Identifier Encipher Signature E
SHA-1
● R
● Certificate
Authority’s
Private Key
ASN1: Abstract Syntax One notation
DER: Distinguish Encoding Rules (tag, length, value)
25
M. Mogollon – 25
Hierarchical Trust Model
Root CA
Level 1 Level 1
CA1 CA2
Level n Level n Level n Level n

CA3 CA4 CA5 CA6
End End End End End End End End

Entity A Entity B Entity C Entity D Entity E Entity F Entity G Entity H
Advantage: Relatively simple to implement

Disadvantage: No cross certification between CAs. If end-
entity A wants to certify end-entity F, it needs
to go all the way to CA5.
26
M. Mogollon – 26
Mesh Trust Model
Cross-Certification
Root CA Root CA
(1)
Root CA
(2)
Level 1 Level 1
CA1 CA2
Level 1
CA2
Level n
CA3 Level n
CA5
Level n
CA5
End End
Entity A Entity F
End
Entity B
• All root CAs are cross-certified with each other, or whenever their
respective communities need to communicate with each other.
27
M. Mogollon – 27
Web Trust Model • The Web trust model is the most widely
used trust model.
 There are only two leading browsers in the
market.
 Certificates are included in the initial web
browser distribution.
 Web browsers are distributed with more than
100 CA public keys pre-installed.
Entrust VeriSign Equifax
CA CA CA • Browsers use pre-installed certificates
to sign, verify, encrypt and decrypt
S/MIME email messages and to
establish Secure Socket Layer (SSL)
Level 1 Level 1 Level 1 sessions.
CA1 CA2 CA2 • It is a very difficult task for an end-user
to manage the numerous “trusted CA
certificates” installed in a browser.
End End End • There is no practical way to prevent
Entity A Entity B Entity C either users, or others with access to
their workstations, from making
unauthorized alterations to the list.
• There is no practical mechanism to
revoke certificates.
Web Model  If Netscape or Microsoft makes a mistake
and installs a “bad” CA, there is no way to
revoke that certificate from the millions of
web browsers in use.
28
M. Mogollon – 28
User-Centric Model
• Used by Pretty Good Privacy
(PGP) in a decentralized
environment. Root CA Root CA
• Any user can act as a certifying Alice Bob
authority and validate another
user’s public key certificate.
• Not all certificates generated Root CA
by users are valid certificates. Jason Root CA
Sandra
 A certificate generated by Alice,
who is acting as CA, may not be
valid to other users because they
know that Alice cannot be trusted Root CA
Rick
as a CA.
• Each user is directly
responsible for deciding which User-Centric Model
certificates to accept and
which ones to reject.
29
M. Mogollon – 29
Comparison of Trust Models
Characteristics Hierarchical Mesh Trust-List (Web)
Trusted key(s) “Root” CA CA that issued user’s File of (usually) many trusted CA
certificate. certificates in each browser.
Trust paths Chain of parent-child Mesh of bi-directional Pre-ordered certificate list.

certificates. cross certificate pairs.
Trust path finding Directory-Based, Directory-Based, complex. Minimal; finds individual
comparatively certificates in LDAP directory.
simple.
Cross-certification May be supported. Basis of PKI No direct capability.
Certificate status Certificate Certificate Revocation List None (may add support for On-
Revocation List. line Certificate Status Protocol in
future).
30
M. Mogollon – 30
Certificate Path and Validation
Same
Self Signed Certificate
Root CA Issuer:
●●● ●●● Subject: Root ●●●
Root
Intermediate CA Certificate
Intermediate Issuer: CA
CA 2 ●●● ●●● Subject: CA2 ●●●
Root
Intermediate CA Certificate
Intermediate Issuer:
CA 1 ●●● ●●● Subject: CA1 ●●●
CA2
End Entity Certificate

End Issuer: Subject: End
Entity A ●●● ●●● ●●●
CA1 Entity A
31
M. Mogollon – 31
Encryption Algorithms Supported in PKI
• Signature Algorithms
 Mandatory Algorithm: DSA/SHA-1
 Other Algorithms: HMAC/SHA-1, RSA/MD5 and ECDSA/ECDH
• Public Key (Asymmetric) Algorithms
 Mandatory Algorithm: Diffie-Hellman
 Other Algorithms: RSA, ECDH.
• Symmetric Algorithms
 Mandatory Algorithm: 3DES and AES in CBC mode.
 Other Algorithms: RC5, Cast 128,.
32
M. Mogollon – 32
Models for PKI Deployment
• In-Sourcing
 Gives an organization full control of a PKI implementation by utilizing its own resources,
including personnel and hardware, and/or hiring external resources.
 Allows organizations to issue and manage certificates in a consistent manner.
• Out-Sourcing
 Takes the PKI management burden from the organization and gives control of the PKI
operation to an external party.
• Factors in Choosing PKI Deployment Model
 Total cost of ownership − software, hardware, personnel, facilities, training, legal fees,
etc.
 Degree of control that the organization wants to maintain during the PKI operation.
 Perceived sense of trust that customers will have from knowing that the PKI operations
are out-sourced or in-sourced.
 Response time associated with PKI related services.
 Level of help desk support.
 Flexibility and scalability.
 Ability and willingness of the vendor to evolve to meet the future needs of the
organization.
 Disaster planning and recovery.
33
M. Mogollon – 33
To Probe Further
• [NEW01] Newman, D. PKI: Build, Buy, or Bust. Networkworld Magazine, December 10,
2001. Retrieve on January 6, 2002 from
 http://www.nwfusion.com/research/2001/1210feat.html
• [RFC 2510] Adams, C., Farrell. S. “Internet X.509 Public Key Infrastructure Cer-tificate
Management Protocols.” RFC 2510, March 1999.
• [RFC 2511] Myers, M., Adams, C., Solo, D., Kemp, D. "Internet X.509 Certificate Request
Message Format." RFC 2511, March 1999.
• [RFC 2527] Chokhani, S., Ford, W. “Internet X.509 Public Key Infrastructure Cer-tificate
Policy and Certification Practices Framework.” RFC 2527, March 1999.
• [RFC 2528] Housley, R., Polk, W. “Internet X.509 Public Key Infrastructure Repre-sentation
of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key In-frastructure
Certificates.” RFC 2528, March 1999.
• [RFC 2898] Kaliski, B. “PKCS #5: Password-Based Cryptography Specification Version
2.0.” RFC 2898, September 2000.
• [RFC 2315] Kaliski, B. “PKCS #7: Cryptographic Message Syntax Version 1.5.” RFC 2315,
March 1998.
• [RFC 2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., Adams, C. “X.509 Internet
Public Key Infrastructure Online Certificate Status Protocol - OCSP.” RFC 2560, June 1999.
• [RFC 2585] Housley, R., Hoffman, P. “Internet X.509 Public Key Infrastructure Operational
Protocols: FTP and HTTP.” RFC 2587, May 1999.
• [RFC 2587] Boeyen, S., Howes, T., Richard P. “Internet X.509 Public Key Infra-structure
LDAPv2 Schema.” RFC 2587, June 1999.
34
M. Mogollon – 34
To Probe Further
• [RFC 2985] Nystrom, M., Kaliski, B. “PKCS #9: Selected Object Classes and At-tribute
Types Version 2.0.” RFC 2315, November 2000.
• [RFC 2986] Nystrom, M., Kaliski, B. "PKCS #10: Certification Request Syntax Specification
Version 1.7." RFC 2986, November 2000.
• [RFC 3029] Adams, C., Sylvester, P., Zolotarev, M., Zuccherato, R. “Internet X.509 Public
Key Infrastructure Data Validation and Certification Server Proto-cols.” RFC 3029, February
2001.
• [RFC 3039] Santesson, S., Polk, W., Barzin, P., Nystrom, M. “Internet X.509 Pub-lic Key
Infrastructure Qualified Certificates Profile.” RFC 3039, January 2001.
• [RFC 3161] Adams, C., Cain, P., Pinkas, D., Zuccherato, R. “Internet X.509 Public Key
Infrastructure Time-Stamp Protocol (TSP).”. RFC 3161, August 2001.
• [RFC 3279] Bassham, L., Polk, W., Housley, R. “Algorithms and Identifiers for the Internet
X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.”
Rfc 3279, April 2002.
• [RFC 3280] Housley, R., Polk, W., Ford, W., Solo, D. “Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List (CRL) Profile.” RFC 3280, April
2002.
• [RFC 3447] Jonsson, J., Kaliski B. “Public-Key Cryptography Standards (PKCS) #1: RSA
Cryptography Specifications Version 2.1.” RFC 3447, February 2003.
• [RFC 3494] Zeilenga, K. “Lightweight Directory Access Protocol version 2 (LDAPv2) to
Historic Status.” RFC 3494, March 2003.
• [WH99] Wing, P. O’Higgins, B. Using Public-Key Infrastructure for Security and Risk
Management. IIEE Communications Magazine September 1999.
35
M. Mogollon – 35
Value of Digital Signatures (from VeriSign)
36
M. Mogollon – 36
Value of Digital Signatures (From VeriSign)
37
M. Mogollon – 37
PKI-Enable
Application
List
(From PKI Forum)
38
M. Mogollon – 38
PKI-Enable
Application List
(From PKI Forum)
39
M. Mogollon – 39

Chapter 9 Certificates and PKI

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter 9 Certificates and PKI

Uploaded by

Copyright:

Available Formats

Cryptography and Security Services:

Mechanisms and Applications

public key certificate / n. Information provided by

Alice I am Alice. This is my

ASN1: Abstract Syntax One Notation

public-key infrastructure / n. (abbr. PKI) (1) a mechanism

PKI is about managing certificates and keys

• When public-key is used, it is necessary to have a

Publish CRL Certificate Revocation Certificate Out-of-band

Certificate Key Certificate

Key Recovery Certificate

Certificate Certificate Certificate

 Identity of the end-entity is established and verified. Registration

the RA, or by the CA. In some environments, a

• Certificate and Key-pair Dissemination

Level n Level n Level n Level n

End End End End End End End End

Advantage: Relatively simple to implement

Characteristics Hierarchical Mesh Trust-List (Web)

Trust paths Chain of parent-child Mesh of bi-directional Pre-ordered certificate list.

Cross-certification May be supported. Basis of PKI No direct capability.

End Entity Certificate

You might also like