1. Determining Equivalence between Certificate Policies for Purposes of Cross-Certification
Jimmy C. Tseng
Assistant Professor of Electronic Commerce
Rotterdam School of Management
Erasmus University Rotterdam
Tel: Fax:
Thank you Chair and Good morning Ladies and Gentlemen.
I am very glad to be here today, and listen to the National Education and Research Networks report on their PKI initiatives. The reason we are here today is presumably to discuss how to coordinate our PKI initiatives so that this community could at some point cross-certify our respective PKIs, and allow interoperation across PKI domains for specific applications.
I have been investigating the issue of PKI interoperation since March 1999, and in my short presentation today, I would like to say a little about the research approach we are taking in the LSE Fiducia project, and I hope to show you some of the tools we have developed along that way, that could be useful for the TERENA community.

2. I. Cross-certification
The certification of one CA by another in order for a verifier to construct and verify certification paths across PKI domains
Construction of certification paths
Level of directory support
Scalability across organisations
Harmonise certificate policies
Trust models based on X.509v3 relies on construction and verification of certification paths.
Cross-certification is almost always assumed when more than one PKI hierarchy is involved.
I will quickly re-cap the various trust models in use today, taken from John Linn’s paper using the following criteria:
Construction of certification paths
Level of directory support (cross-certs held in LDAP server)
Scalability across organisational boundaries
TERENA PKI-COORD Meeting, Amsterdam, 26 Nov, 2001

3. Sub-ordinated Hierarchies
Top-down from Root CA
Simple path construction
Low directory dependency
Weak scalability across organisations
TERENA PKI-COORD Meeting, Amsterdam, 26 Nov, 2001

4. Cross-certified meshes
Pair-wise between CAs
Difficult path construction
High directory dependency
Medium scalability across organisations
TERENA PKI-COORD Meeting, Amsterdam, 26 Nov, 2001

5. TERENA PKI-COORD Meeting, Amsterdam, 26 Nov, 2001
Hybrid model
Top-down or pair-wise
Multiple paths may exist, but simple path known
Moderate directory dependency
Medium scalability across organisations
TERENA PKI-COORD Meeting, Amsterdam, 26 Nov, 2001

6. TERENA PKI-COORD Meeting, Amsterdam, 26 Nov, 2001
Bridge CA
Pairwise with Bridge CA
Simple, all non-local paths traverse bridge
Medium directory dependency
Scaleable across organisations
TERENA PKI-COORD Meeting, Amsterdam, 26 Nov, 2001

7. TERENA PKI-COORD Meeting, Amsterdam, 26 Nov, 2001
Trust list
Recognition by verifiers
Simple but limited to paths that begin within the trust list
Low directory dependency
Fair scalability, requires intensive management
TERENA PKI-COORD Meeting, Amsterdam, 26 Nov, 2001

8. TERENA PKI-COORD Meeting, Amsterdam, 26 Nov, 2001
II. Certificate Policy
CP defines “applicability of a certificate to a particular community and/or class of application with common security requirements”
CP used by “certificate users to decide whether or not to trust a certificate for a particular purpose”
“Any one certificate will typically declare a single certificate policy or, possibly, be issued consistent with a small number of different policies.” – RFC2527
Most PKI discussions assume single domain, or single certificate policy (policy authority)
Can relying parties be expected to construct and validate certification paths?
Automation through common CP and OIDs
TERENA PKI-COORD Meeting, Amsterdam, 26 Nov, 2001

9. TERENA PKI-COORD Meeting, Amsterdam, 26 Nov, 2001
Object Identifiers
“A certificate policy, which needs to be recognized by both the issuer and user of a certificate, is represented in a certificate by a unique, registered Object Identifier. The registration process follows the procedures specified in ISO/IEC and ITU standards.” – RFC2527
No formal procedures, no accepted OID identifiers
TERENA PKI-COORD Meeting, Amsterdam, 26 Nov, 2001

10. Looking up a Certificate Policy
Currently no standard means of looking up an OID
How to use OIDs to represent different policy dimensions?
“The party that registers the Object Identifier also publishes a textual specification of the certificate policy, for examination by certificate users.”
Is the certificate user forced to revert back to the CPS?
Prof. Chadwick understands
How can OIDs be used if there are no common mechanisms for lookup?
TERENA PKI-COORD Meeting, Amsterdam, 26 Nov, 2001

11. III. PKI Interoperation
Component-level Interoperation (standards)
Application-level Interoperation (cross platform compatibility)
Inter-domain Interoperation (harmonise certificate policies)
CA A
Domain A
Entity A
Application A
CA B
Domain B
Entity B
Application B
Trust
(1)
(2)
(3)
But cross-certification is not just a matter of certificate path validation, within each cross-certified community, there is still the assumption of common certification standards and practices, hence the notion of certificate policy, and policy authority
For cross-certification to work, we also need to establish ways of determining the equivalence between CP/CPS across PKI domains, hence the focus on Inter-domain interoperation.
Component-level - conformance to technical standards on one platform
Application-level - compatibility across platforms
Inter-domain level - common security requirements and harmonised certificate policies
---
We can distinguish between
Technical -Platforms and formats compatible between vendor products
Institutional - Policy and procedures of individual TTPs
- National legal and regulatory frameworks
On the one hand we have the Technical issue. Roughly speaking the issue is can my computer system accept and read your digital token? This is quintessentially a matter of technology and touches upon debates about proprietary and open systems. Fortunately a lot of work is under way on this aspect.
On the other hand there is what I refer to as the Institutional aspect. This is to do with agreement about what the meaning of the certificate is . In legal, commercial and even organisational terms. More precisely it refers to those matters that allow the relying parties to assess the degree of riskiness before accepting the certificate. And the factors hinge on internal running of the TTP/CA the regulatory framework and context of the TTP/CA.
TERENA PKI-COORD Meeting, Amsterdam, 26 Nov, 2001

12. PKI Interdomain Interoperation
Interworking of CAs across different administrative and trust domains
Requires common or equivalent certificate policies (CP) and certification practices (CPS)
Harmonising CP and CPS are fraught with difficulties (e.g. cross-certification, policy constraints, certificate path validation)
CAs operate from different jurisdictions
Technical
PKI Forum - Consortium
PKI Challenge (EEMA)
Open Group (APKI)
Institutional
PAG (ABA)
APEC (Asia-Pacific Economic Cooperation)
Subject of the this conference
TERENA PKI-COORD Meeting, Amsterdam, 26 Nov, 2001

13. IV. The Fiducia Project
Modelling the risks in interoperable public key infrastructures
Working Together
Spreading Trust
Securing Value
Started working on Fiducia in March 1999/ April 2000 at LSE, I joined the faculty of RSM in Sept 2000
LSE CSRC lead party, about social science approach to information security
Erasmus research on EDI, e-commerce, e-auctions, collaborative commerce
Academic partners funded by ESRC
Commercial partners funded by DTI
DLR Interclear
Presideo
BT Labs

14. Modelling Contractual Risk in PKI Relationships
Modelling Business Risk in Electronic Transacting
Modelling Contractual Obligations and Liability in PKI
Non-legislative standards governing provision and use of PKI
Subject A
Subject B
RP A
Good and services
Payment
CA B
CPS B
CA A
CPS A
Goverance
Structure
Contractual arrangements
Subscriber
Agreement A
Relying Party
Agreement B
Interoperability
Agreement
TERENA PKI-COORD Meeting, Amsterdam, 26 Nov, 2001

15. TERENA PKI-COORD Meeting, Amsterdam, 26 Nov, 2001
CA Database
Database of 110 public facing CAs from 33 countries in 16 languages
TERENA PKI-COORD Meeting, Amsterdam, 26 Nov, 2001

16. TERENA PKI-COORD Meeting, Amsterdam, 26 Nov, 2001
CPS Database
Full-text collection of CPs and CPSs
TERENA PKI-COORD Meeting, Amsterdam, 26 Nov, 2001

17. TERENA PKI-COORD Meeting, Amsterdam, 26 Nov, 2001
Legal Analysis
Legal and Semantic Analysis
Clarifying Roles, Obligations and Liabilities of all parties in PKI
Model Framework
Legislation
CPS1
CPS2
Semantic Schema - entities and rules
Semantic elements
Substantive
rules
Procedural rules
Coding scheme
Specification language
Support for retrieval, query, and modelling
CPS3
TERENA PKI-COORD Meeting, Amsterdam, 26 Nov, 2001

18. TERENA PKI-COORD Meeting, Amsterdam, 26 Nov, 2001
Semantic Analysis
Ontology of affordances (possible behaviours)
Norms (that trigger actual behaviours)
State#
Subject#
TTP #
Digital Certificate #
Person#
Corporate#
Server#
CA#
RA#
IA#
(certificate holder)
Issued to
(public key)
assigned
pair#
vets
cryptographic key#
(private key)
(verified subject)
(subscriber certificate)
contains
Ontology chart- which encompasses all the PKI actors and behaviour. Using our CPS database and our industrial partner (De La Rue) as resources
Norms- deriving from analysis of CA regulation/electronic signature act
TERENA PKI-COORD Meeting, Amsterdam, 26 Nov, 2001

19. Tools for Determining Equivalence between Certificate Policies
From certificate path validation to determining certificate policy equivalence
Textual database of certificate policy dimensions
Specification of similarities and differences across certificate policy dimensions
Basis for policy mapping and cross-certification
TERENA PKI-COORD Meeting, Amsterdam, 26 Nov, 2001