Update on PKI Activities in the Spanish Academic Network

1. Update on PKI Activities in the Spanish Academic Network PKI-COORD November 26, 2001. Amsterdam

2. Outline • IRIS-PCA • New members and evolution • Policy update • Integration into EuroPKI • PKCS#11 libraries • UmPKCS11 • E-mail timestamp server • Development just started • PAPI • Current status • PAPI v1.1 • The pilot PAPI mesh • The case for BCAs in Europe

3. IRIS-PCA • Four new candidate organizations • Expected to be fully integrated before the end of the year • Problems for already established PKIs • Contacts with other Spanish initiatives in PKIs • Governmental: CERES • Private: ACE (has become VeriSign) • Still looking for the PKI killer application

4. IRIS-PCA: Policy update • New version of the policy document • OID: 1.3.6.1.4.1.7547.2.2.1.1.3 http://www.rediris.es/cert/proyectos/iris-pca/docs/politica.html • An English translation is available http://www.rediris.es/cert/proyectos/iris-pca/docs/politica-pca-ingles.rtf • Submitted to EuroPKI for acceptance

5. PKCS#11 Library • Developed by the University of Murcia for their internal PKI project • Available for Unix/Linux and Windows • Thoroughly tested in an operational environment • More than 15,000 users • Acces control, clock-in, facility reservation,... • Available under GPL • http://umpkcs11.sourceforge.net/ • Source and RPM formats • Full documentation under development

6. PAPI • Current version available is 1.0.2 • http://www.rediris.es/app/papi/dist.en.html • Point of Access based on Apache mod_perl • Configurable using Apache directives inside httpd.conf • Authentication hooks for • Internal database • POP-3 • LDAP • Includes a set of enhanced documentation • FAQ • Guide for Beginners

7. PAPIVersion 1.1.0 is under test • Problem: PoAs using the same policy must load different tokens to the user’s browser • Lack of scalability for large services • Solution: PoAs with the same policy are grouped into a GPoA • Tokens are assigned hierarchically • Better managenent of tokens • Registered by the PoA once all contents are received by the user’s browser • Simplified installation and operation

8. Authentication 302 + data GPoA PoA 302+ Hcook PAPIV1.1 implementation of GPoAs Authentication Server Keys Browser Hcook- Lcook GPoA Hcook- LcookPoA

9. The PAPI pilot mesh • Using PAPI ASs and PoAs • Remote access to restricted services • Inter-institutional trust relationships • A fairly complete cocktail • Three universities (one virtual) • Two commercial information providers • One library consortium • A public content provider • More organizations to join in the near future • So we can erase the “pilot” • PAPI is under test in other academic networks • We now about three of you

10. Bridge CAs • Integrate existing PKIs which may implement different architectures, security policies, and cryptographic suites • Address the shortcomings of the two basic PKI integration methods: mesh and hierarchical • Are not root CAs • Connect trust domains through cross certificate pairs creating a “bridge of trust” • Do not issue certificates directly to users • Are not used as a trust point by the users of the PKIs involved • User keep their natural trust point • Based on the PKIX standards

11. Principal CA Principal CA Bridge Bridge of trust Bridge CA Architecture

12. The Federal Bridge CA • Principal CAs cross-certificate with the FBCA membrane • The FBCA is built using several cross-certified commercial CAs • The membrane offers a common boundary for them • Certification Policy mapping • OID@certificatePolicies extension • Directory Services • All certificates issued by any node of the FBCA • All certificates issued to any node of the FBCA • All cross certificates pairs containing certificates held or issued by the FBCA • A CARL from each node of the FBCA covering certificates issued by that node • Libraries for certificate path discovery and validation

13. The experience at RedIRISProblems in a bottom-up approach • Theoretically, hierarchical PKIs are scalable... • Found problems when testing the integration of the RedIRIS PKI directly under another root CA • < openssl 0.9.6 • The first certificate whose subject name matched the issuer of the current certificate was assumed to be the issuer certificate • >= openssl 0.9.6 • All certificates whose subject name matches the issuer name of the current certiticate are subject to further tests • One of these tests (applied to the Authority Key Identifier) fails when a new CA is introduced at the top of the hierarchy • Solution: cross-certification • Why not at a BCA?

14. Bridge CAsPros and cons • More flexible and extensible than either mesh or hierarchical structures • Support a bottom-up approach • Integration of already existing PKIs • Maintain policy independence • Require certificate path discovery and validation software • There is a (public) library available • Put stress on directory services • Other approaches possible • Not much tested (scalability, performance,...) • More experiments are required