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: +31-10-408-2854 Fax: +31-10-408-9010 Email: jtseng@fbk.eur.nl 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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