Cross Certification p37 v03

Design of International Cross Certification
Model using Cross Certificate
Dr. Jaejung Kim
(jjkim@signgate.com)
Contents
Comparing Models
PKI Entities
PKI analysis
Proposed CC Model
Conclusions
Copyright 2012@KICA Inc. All rights reserved
Comparing Models
Comparing Models
CTL
Cross-certification
Cross-recognition
Advantage/Disadvantage
Model Comparison
CR: Cross Recognition
An interoperability arrangement in which a replying party in one
PKI domain can use authority information in another domain to
authenticate a subject in the other PKI domain, and vice versa.
CTL: Certificate Trust List
A CTL is a signed PKCS#7 data structure that can contain, among
other things, a list of trusted CAs. A trusted CA is identified
within the CTL by a hash of the public key certificate of the
subject CA.
CC: Cross Certification
A certification authority may be the subject of a certificate issued
by another certification authority.
Reliability
Standards
Cross Certificate
Stability
CTL Model
A CTL is a signed PKCS#7 data structure that can contain
hash list of trusted CAs.
Use for interoperability of National PKI and Government PKI in
Korea.
CTL
CTL
CTL
RootCA Bs
Hash
RootCA A
Certificate Path
A_RootCA Cert
RootCA B
RootCA As
Hash
CTL issued by RootCA A

B_RootCA Cert
CA A
CA B
B_CA Cert
B_User Cert
USER A
PKI A
USER B
PKI B
4
CTL Verification Procedure

CTL verification is followed below.
pkiCTL
certificateTrustList;binay
Content Type
Content
version
digestAlgorithms
encapContentInfo
certificates
crls
signerInfos
SignedData(PKCS#7)
version
Subject Usage
List Identifier
Sequence Number
This Update
Next Update
Subject Algorithm
Trusted Subjects
Type Criticality Value
Extensions
Type Criticality Value
CA Signature
CTL
Cross Certification Model

In the case of mutual cross-certification, a reciprocal relationship
is established between the CAs one CA issues a cross certificate
fro the other, and vice versa. The cross certificate issued by the
local CA for a remote CA is referred to as a reverse certificate. The
cross certificate issued by the remote CA for local CA is referred to
as the forward cross certificate.
CC
PKCF #10 of CRMF
Cross Certification
A-B Cross
Certificate
RootCA A
Certificate Path
A_RootCA Cert
RootCA B
B-ACross
Certificate
A-B Cross Certificate
B_RootCA Cert
CA A
B-A Cross
Certificate
CA B
B_CA Cert
A-B Cross
Certificate
B_User Cert
PKI A
USER A
USER B
PKI B
6
CC Certificate Path Validation

A A_USER in A domain verify a certificate AB_USER in B PKI
domain.
A-CAs Cert
Serial number:1
Issuer : A-CA
Subject : A-CA
Validity : .
PublicKey : PA-CA
Extensions
SA-CA
A-B Crosss Cert
Serial number:2
Issuer : A-CA
Subject : B-CA
Validity: .
PublicKey : PB-CA
Extensions
SA-CA
12
15
user
11
13
ARL
Issuer: A-CA
thisUpdate:
nextUpdate:
revokedCertificates
3
Serial number:07
Issuer : B CA
Subject: AB user
Validity: .
PublicKey: P AB
Extensions
SB-CA
AB Users Cert
CRL
A-CAs ARL
Issuer : B-CA
thisUpdate:
nextUpdate:
revokedCertificates
2,4,30, ..
B-CAs CRL
14
Trust Anchor : A
7
CTL Advantages/Disadvantage
Category
Relative
Advantages
Description
No single point of failure.
Issuer of CTL can produce ARL to revoke a trusted CA, or can
issue new CTL with revoked CA omitted.
Path needs ti be established between sender and a CA in CTL.

Similar processing requirements to other systems though greater
choice of final trust point which may make paths quicker to find.
Potential
Disadvantages
There are some (yet to be quantified) level of system management

workload associated with the management of multiple trusts
points.
Not clear how client obtains CTL. Level of support in products
unclear.
CC Advantages/Disadvantage
Category
Relative
Advantages
Potential
Disadvantages
Description
Effect of compromise is limited to EEs subordinate to the
compromised CA.
EEs can trust a local (well-known) CA.
Trusted point rollover affects only local EEs.
Certificate paths are short between local users.
Revocation of single trusted point is straightforward.
Certificate paths can be very long between distant EEs.
Revocation of multiple trusted points (if applicable) must be
supported.
Path construction may be complex must be able to navigate
multiple paths and find a path (not necessarily the optimal one)
linking sender to relying partys trust point.
Level of flexibility required for path construction and validation is
not currently supported in all client products.
Need access to revocation information from the cross-certified
domain (implies repository connectivity or import of CRLs from
other domain).
CR Advantages/Disadvantage
Category
Relative
Advantages
Potential
Disadvantages
Description
Cross-certification agreements are not required.
Relying party expected to make trust decisions.

Likely insufficient mechanism for high assurance transactions.
If remote trust gained through licensing regime, presumably
revocation of trust must be achieved through similar means.
Criteria for establishing cross-recognition not universally agree
at present.
Method to convey necessary information to relying party not yet
defined.
10
PKI Entities
PKI Entities
PKI Entities
PKI Components
11
PKI Entities
End entity
PKI Users
Cert / CRL
Repository
Initial registration
Certification
Key pair recovery
Key pair update
Certificate update
Revocation request
PKI Management
entities
Certificate
Publish
RA
certificate Publish
CRL Publish
OP
MP
CA
cross certification
CA-2
12
PKI Components
CA
Certificate Authority
Issues or distributes the certificate for other CA, End Entity, RA.
handles revocation request from the owner of certificate or RA.
publishes certificate and CRL to directory server
issues the cross-certificate and manages
RA
Registration Authority
Identifies the user and register the user information

Transmits certificate request to CA.
Searches certificate and CRLs from directory server.
Requests the certificate revocation
DS
Directory System
Stores certificates (End Entity, RA, CA) and CRLs

Supports LDAP (Lightweight Directory Access Protocol)
EE
End User
Manages certificates with certificate management software published by CA.

Creates and verifies digital signatures.
13
PKI Analysis
PKI Analysis
NPKI Problems and Solutions

Man-in-the-middle-attack
in CRL
PSE interoperability problem

Application interoperability
problem
14
Current PKI Analysis

Standard of NPKI Interoperability
User Interface
Specification for
Accredited CAs
Mark
Specification
for
accredited
Certificate
Subscriber Identification
Base on virtual ID
Interoperability
Certificate and
CRL Profile
OCSP
Certificate Import/
Export(PKCS#12)
15
NPKI Problem and Solution

Certificate and CRL Profile
Man-in-the-Middle-Attack of CRL
Solution)
when a CA makes a CRL, IDP in the CRL must be created and set
critical. After that, verifier must compare CRL DP in a certificate to
IDP in the CRL.
User interface specification

PSE Interoperability Problem
Solution)
use standard functions (PKCS#11)
Application Program Interoperability Problem

Solution)
define the API Specifications each other.
16
Man-in-the-Middle-Attack in CRL
An IDP field in the current CRL profile is optional.
If the IDP field is not created or the criticality sets noncritical, this attack may happens.
1. In case of searching CRLs from a directory server, an attacker switches the other valid CRLs.
2. In case of caching CRLs in a server, an administrator switches the CRL with malicious
intension
CRL1 search request

Cached CRLs
Cert Serial
1-100
101-200
201-300
LDAP
CRL Name
Crl1.crl
Crl2.crl
Crl3.crl
Crln.crl
DS
Server
Copy
CRL 3
Server
Administrator
CRL1
Attacker
CRL: Certificate Revocation List
IDP: issuing Distribution Point
17
PSE Interoperability Problem

User interface specification defined a name of folder to
store certificate and key.
Every security developers have to make it.
If a new CA insert or remove, new media to store insert
developers make rebuild and republish it.
In case of smart card, PC/SC uses and their card map is
defined, but USB is not.
EE B S/W
EE A S/W
Hard Disk : C:\Program Files\NPKI

Floppy Disk : A:\NPKI
Smar
t
Card
A Smartcard
Licensed CA
Certificate Chain
Certificate for KM
Private Key from KM
Certificate for Sign
Private Key for Sign
Bs USB
Token
B Smartcard
PSE: Personal Security Environment

PC/SC: Personal Computer/Smart Card
[PSE of NPKI at present]

18
Application Interoperability Problem

Item
Description
Solution
IPS, acquisition of certificate chain

CRL issuing period, CRL, OCSP
Storage media for certificate (SW / HW)
Drive version, HW interface (USB/COM)
class of algorithm (RSA, ECDSA, 3DES)
standard version (PKCS#1 v1.5, v2.0)
Key parameter, size, IV etc,.
AIA field in OCSP

CRL DP
PKCS#12
PKCS#11
MS CryptoAPI, CDSA
defined APIs by local
define API
Specifications
Development
Platform
Program languages (C, C++, JAVA),

browsers
setup files (REG, INF file)
C,JAVA
IE, Netscape
Message and
Encoding Rules
Data encoding rules

(BASE64, DER, UTF8)
PKCS#7, XML, low signature value.
Communication Protocols
(HTTP, TCP/IP (IP, port)
SSL, TLS
Certificate policy
PSE
Cryptography
Algorithm
Program
Interface
(API)
Transmission
Protocol
common algorithms
Negotiation
XML signature
CMS
19
Proposed cross-certification Model

Item
Certificate/CRL Profile
Directory Schema
Proposal
Analyze the current NPKI profile and make a new
profile for cross-certification.
Define new object classes with attributes in standard.
Use referral object class and make a new CRL DP class.
Certificate Transport
Method
Define the PKCS#12 format for import/export the

certificate, key, certificate chain.
PSE Interoperability
Use the PKCS#11 and choose the basic function in there.
Certificate Verification
Design the detail scenario to make certificate chain

based on RFC 3280.
Issuing method for CC
PKCS#10 or CMP
Issuing method for

USER
Depend on each country situation. (PKCS#10, CMP,

PKCS#12)
Storing Standard for

Private Key
Make keys by RSA(PKCS#1), encrypted by PKCS#5,

saved by PKCS#8.
20
Proposed CC Model
Proposed CC Model
Cross certification model
Certificate profile
CRL profile
Directory Schema
PKCS#12
PSE interoperability
Certificate verification
scenario
21
Cross-certification Model
CA, CrossCertificates,
User Certificates,
ARL, CRL
Referral
Cross Certification
LDAP
PKCS#10
DS
CA_A
DS
CA_B
CMP/
PKCS#10
PKCS#12
EE
EE A
S/W
PKCS#11
PKCS#12
EE B S/W
PKCS#11
PSE
PKCS#5/
PKCS#8
Cert A
Cert BA
Cert AB
Cert B
22
Certificate - V3 Extensions
X.509 v3 extension
Authority Key Identifier
Subject Key Identifier

Key Usage
Certificate Policies
Description
Provides a means of identifying the public key corresponding to the
private key used to sign a certificate.
Provides a means of identifying certificates that contain a particular
public key.
Defines the purpose (e.g., encipherment, signature, certificate signing)
of the key contained in the certificate.
Contain a sequence of one or more policy information terms, each of
which consists of an object identifier (OID) and optional qualifiers.
Policy Mappings
Indicate the issuing CA considers its issuerDomainPolicy equivalent to

the subject CA's subjectDomainPolicy.
Subject Alt Name
Allows additional identities to be bound to the subject of the certificate.
Issuer Alt Name
Used to associate Internet style identities with the certificate issuer.
Basic Constraints
Name Constraints
Policy Constraints
Identify whether the subject of the certificate is a CA and the maximum

depth of valid certification paths that include this certificate.
Indicate a name space within which all subject names in subsequent
certificates in a certification path MUST be located.
Used to prohibit policy mapping or require that each certificate in a
path contain an acceptable policy identifier.
CRL Distribution Points
Identify how CRL information is obtained.
Authority Information
Access
indicates how to access CA information and services for the issuer of

the certificate in which the extension appears.
23
Certificate Profile
Field
Self
Cross
EE
ASN.1 Type
NC
NC
NC
Subject Key Identifier
NC
NC
NC
OCTET STRING
Key Usage
BIT STRING
Certificate Policies
NC
Policy Mappings
NC
Subject Alt Name
NC
Issuer Alt Name
NC
Basic Constraints
Name Constraints
Policy Constraints
CRL Distribution Points
Distribution Point
NC
Full Name
Authority Info Access
NC
NC
NC
M
NC
DirectoryName, URI
NC
NC
M: Mandatory, O: Optional, C: Critical, NC: Non-Critical

24
CRL - V2 Extensions & Profile

X.509 v3 extension
Description
Issuer Alt Name
Allows additional identities to be associated with the issuer of the CRL.
Authority Key
Identifier
Provides a means of identifying the public key corresponding to the

private key used to sign a CRL.
CRL Number
Conveys a monotonically increasing sequence number for a given CRL

scope and CRL issuer.
Delta CRL Indicator
Identifies a CRL as being a delta CRL.
Issuing Distribution
Point
Identifies the CRL distribution point and scope for a particular CRL.
Field
CRL
Issuer Alt Name
Key Identifier
CRL Number
Delta CRL Indicator
Issuing Distribution Point
ARL
ASN.1 TYPE
NC
NC
M
M
M
NC
NC
OCTET STRING
INTEGER
M: Mandatory, O: Optional, C: Critical, NC: Non-Critical

25
Directory Schema
Entity
Object class
Attribute
person
organizationalPerson
inetOrgPerson
certificateAuthority
commonName
surName
cACertificate
crossCertificatePair
certificateRevocationList
authorityRevocationList
End
Entity
person
inetOrgPerson
commonName
surName
userCertificate
CRL
DP
cRLDistributionPoint
ou
country
referral
country
ref
CA
referral
26
Object Class
Name
OID
Description
Basic object class.
person
2.5.6.6
2.5.6.7
Object inherited by Person.
2.16.840.1.113730.3.2.2
Object inherited by
organizationalPerson.
include certificate attribute.
inetOrgPerson
certificationAuthority
2.5.6.16
Object class for CA.

Save CA certificate, crosscertificate, CRL. ARL.
country
2.5.6.2
Object class for country name.
referral
2.16.840.1.113730.3.2.6
Object class for referral defined

by Netscape Directory Server.
cRLDistributionPoint
Not defined
Object class for CRL DP.

Include CRL attribute.
27
Attributes
Attribute Name
OID
Description
User Name.
commonName
2.5.4.3
surName
2.5.4.4
userCertificate
2.5.4.36
cACertificate
2.5.4.37
CAs Certificate.
crossCertificatePair
2.5.4.40
Cross-certificate.
Certificate issued by each other.
( A [forward] B )
( A [reverse] B )
2.5.4.39
CRL.
authorityRevocationList
2.5.4.38
ARL.
countryName
2.5.4.6
Country Name.
ref
2.16.840.1.113730.3.1.34
A family name.
Users Certificate.
Store directory host and port to

Referral.
28
Certificate Transfer Method PKCS#12

Certificate Transfer Method
PKCS12 includes the Encrypted Private Key, user Certificate,
Certificate Chain( Root CA ).
The number of private key data in PKCS#12 must be one.
It must be use PKCS#5(3DES)/PKCS#8.
Recommend to use pbeWithSHA1And3-KeyTripleDES-CBC.
Contained the Certificate Chain(User Cert->Root CA).
In case that CRL data exists in PKCS#12, the CRL data shall
not be registered.
Can Import Internet Explorer or Netscape Browser.
The LocalKeyID attribute allocated to private key data in
PKCS#12 and paired EE certificates must be the same values.
The same password must be used for validating and
deciphering the signature of PKCS#12 data and deciphering
private key data, should be encrypted.
29
PSE Interoperability
Common Module (CryptoAPI, GSM or CDSA)
Download
Module
Pre-installed
Module
Very suitable for application requirement and

accepts each domain requirement.
Difficult implementations.
Lots of constraints (language, platform etc)
Good method for a new project.
Common Token (PKCS#11)*

A
Comparatively small constraints. (media, service

method, compatibility)
Provide user convenience, easy implementation.
Certificate
Storage
Key Exchange (PKCS#12)

A
Use other application programs.

Hard to use because user know each application
programs.
If new domains create, CA have to develop it
(difficult expansion)
30
PSE PKCS#11
PKCS#11 was intended from the beginning to be an interface
between applications and all kinds of portable cryptographic
devices, such as those based on smart cards, PCMCIA cards, and
smart diskettes.
Client (MS Windows)
Download Module
Web Server
Web Server
Applications(A)
Applications(B)
Local API
(Active-X Wrapper)
Local API
(Java Wrapper, JNI)
Standard
Java
Active-X
Local API
(Active-X Wrapper)
Local API
(Java Wrapper, JNI)
Downloaded via Internet
Downloaded via Internet
Internet
PKCS#11 API
(developed by A)
Pre-installed
Module
Pre-Installed
PKCS#11 Driver
(Domain A)
PSE(A)
PKCS#11 API
(developed by B)
Pre-installed
Module
Pre-Installed
PKCS#11 Driver
(Domain B)
PSE(B)
31
PKCS#11 Functions
Cryptokis logical view of a token is a device that stores
objects and can perform cryptographic functions.
Item
API flowchart
Init
C_Initialize
Slot
C_GetSlotList
Session
C_OpenSession
Login
C_Login
Object
C_Finalize
C_GetTokenInfo
C_CloseSession
C_Logout
C_FindObjectsInit
Sign
C_CreateObject
C_SignInit
Verify
C_VerifyInit
C_GetFunctionList
C_FindObjects
C_GetAttributeValue
C_FindObjectsFinal
C_DestroyObject
C_Sign
C_Verify
32
Certificate Validation Scenario

This scenario is that user B using user cert sign AB, AApplication verify it.
AB User Cert issued by CA_B for cross certification.
verification the Certificate
and Digital Signature
by RFC 3280
Trust Anchor: A
Get CRL by CRL DP

in User Cert.
A-Apps
DS B
CRL
A-B Cross Cert, A-CA Cert
ARL
DS A
send result
transmit
XML-signature or
CMS signedData
PKCS#11 or
PKCS#12 Import
generate digital
signature
Trust Anchor: B
AB
A-CA Cert,
B-A Cross Cert,
A-B Cross Cert,
CRL, ARL
A-CA Cert,
A-B Cross Cert,
B-A Cross Cert,
CRL, ARL
get A-B cross-certificate in A-DS

from trust anchor information (DS, issuer)
get A-CA cert from CRL DP info in
cross-cert and issuer DN.
get ARL from CRL DP info in A-CA
User AB
33
Conclusions
Conclusions
34
Conclusions
CC is most reliable and safe model among CR,
CTL, CC.
As NPKI at present solve the problem and
proposed the new cross-certification model.
Provided convenience of PSE because of
PKCS#11.
Provided interoperability of key exchange using
PKCS#12.
Give guideline for certification path construction
by detail scenario.
Improve current NPKI to international cross
certification.
Define model based on standard
Give a easy implementation.
35

Cross Certification p37 v03

Uploaded by

Copyright:

Available Formats

Cross Certification p37 v03

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

Cross Certification p37 v03

Uploaded by

Copyright:

Available Formats

Design of International Cross Certification

Model using Cross Certificate

Dr. Jaejung Kim

Copyright 2012@KICA Inc. All rights reserved

Copyright 2012@KICA Inc. All rights reserved

CTL issued by RootCA A

CTL Verification Procedure

Type Criticality Value

Copyright 2012@KICA Inc. All rights reserved

Cross Certification Model

A-B Cross Certificate

Copyright 2012@KICA Inc. All rights reserved

CC Certificate Path Validation

A-B Crosss Cert

Path needs ti be established between sender and a CA in CTL.

There are some (yet to be quantified) level of system management

Copyright 2012@KICA Inc. All rights reserved

Copyright 2012@KICA Inc. All rights reserved

Cross-certification agreements are not required.

Relying party expected to make trust decisions.

Copyright 2012@KICA Inc. All rights reserved

Copyright 2012@KICA Inc. All rights reserved

Identifies the user and register the user information

Stores certificates (End Entity, RA, CA) and CRLs

Manages certificates with certificate management software published by CA.

Copyright 2012@KICA Inc. All rights reserved

NPKI Problems and Solutions

PSE interoperability problem

Copyright 2012@KICA Inc. All rights reserved

Current PKI Analysis

Copyright 2012@KICA Inc. All rights reserved

NPKI Problem and Solution

User interface specification

Application Program Interoperability Problem

Copyright 2012@KICA Inc. All rights reserved

CRL1 search request

PSE Interoperability Problem

Hard Disk : C:\Program Files\NPKI

PSE: Personal Security Environment

[PSE of NPKI at present]

Application Interoperability Problem

IPS, acquisition of certificate chain

AIA field in OCSP

Program languages (C, C++, JAVA),

Data encoding rules

Copyright 2012@KICA Inc. All rights reserved

Proposed cross-certification Model

Define the PKCS#12 format for import/export the

Use the PKCS#11 and choose the basic function in there.

Design the detail scenario to make certificate chain

Issuing method for CC

Issuing method for

Depend on each country situation. (PKCS#10, CMP,

Storing Standard for

Make keys by RSA(PKCS#1), encrypted by PKCS#5,

Copyright 2012@KICA Inc. All rights reserved

Copyright 2012@KICA Inc. All rights reserved

Subject Key Identifier

Indicate the issuing CA considers its issuerDomainPolicy equivalent to

Subject Alt Name