Interoperation Between a Conventional PKI and an ID-Based Infrastructure

1. Interoperation Between a Conventional PKI and an ID-Based Infrastructure Geraint Price Royal Holloway University of London joint work with Chris Mitchell

2. Overview • Introduction • Technical Background • A Simple Certificate-Based Solution • Extending Our Analysis • Lessons Learnt and Future Work • Conclusions EuroPKI 2005

3. Introduction • Our analysis focuses on the following scenario: • Domain A uses a certificate-based PKI • Domain B uses an ID-based PKI • Users in domains A & B wish to interact securely • We consider issues such as: • What are the specific issues arising for interoperation in either direction? • What are the security implications of interoperation? • What lessons can we learn, and where do we go from here? EuroPKI 2005

4. Technical Background • Certificate management in a conventional PKI adds a significant overhead • In 1984 Shamir proposed Identity-based cryptography, where the public-private key pair is generated from public information • Until Boneh and Franklin’s work in 2001, no efficient encryption mechanism existed • Sender can encrypt a message to a recipient without having to retrieve the recipient’s public key EuroPKI 2005

5. Technical Background (II) • Main operational differences: • Trusted Authority (analogous to the CA) generates all private keys using a domain secret • Private decryption keys only need to be generated when they are required for decryption • There is no explicit means of revocation, but there are similar associated problems • Very little prior work that studies the interaction: • Chen et al [2002] and Smetters and Durfee [2003] propose a tiered approach EuroPKI 2005

6. A Simple Certificate-Based Solution • We consider the “obvious” solution: • Cross-certification between the two domains • How does cross-certification work natively? • In the certificate-based world, there is already plenty of work done in this area • In the ID-based world, no prior work uses ID-based cryptography to secure inter-domain communication • It appears that ID-based cryptography is not suitable for supporting inter-domain credentials EuroPKI 2005

7. The Certificate-Based User • How the scheme would work: • CA for domain A generates a cross-certificate for the TA in domain B • The cross-certificate could contain policy information for domain B that is of relevance to domain A • The user in domain A validates the cross-certificate and checks the policy for acceptability • There will typically be a need for a certificate status check, and possibly some additional path validation EuroPKI 2005

8. The Certificate-Based User (II) • We now note some potential difficulties • Certificate content and type: • Identity certificate or attribute certificate? • We believe that an identity certificate would be preferable in practice • CP and CPS: • Cert-based PKIs rely heavily on CPs and CPSs • ID-Based environments allow the offloading of policy creation onto the user EuroPKI 2005

9. The Certificate-Based User (III) • How does the cert-based user assure themselves that the private keys in domain B conform to the desired policy? • Two possible solutions: • The TA in domain B could release a set of policy statements in an similar manner to a CP • The sender in domain A generates a new identity-based key with a reference to the appropriate policy EuroPKI 2005

10. The ID-Based User • How the scheme would work: • The TA for domain B generates a cross-certificate for the public key of the CA in domain A • This cross-certificate could contain policy information for domain A of relevance to a user in domain B • The user in domain B validates the cross-certificate and checks the policy for acceptability • There will typically be a need for a certificate status check and possibly some additional path validation • While this gives the functionality we require, it is a rather inelegant solution EuroPKI 2005

11. The ID-Based User (II) • An alternative would be to have the TA in domain B issue an identity-based signing key to the CA within domain A • This approach is unlikely to be used in practice • CP and CPS – two candidate approaches: • Users in domain B would be required to parse the certificate policies of domain A • The TA within domain B could identify suitable CPs from domain A • The second option provides for a cleaner approach EuroPKI 2005

12. The ID-Based User (III) • Revocation: A “pure” identity-based implementation relies on key re-issuance • Three candidate mechanisms for users in domain B to validate domain A certificates: • The CA could issue new certificates at the same rate as the TA would issue identity-based keys • The TA could act as a filter for user requests • The user could be required to interrogate the CRL and OCSP servers directly • Application level considerations are likely to impact on this design decision EuroPKI 2005

13. Extending Our Analysis • Potential Alternative Solutions: • Reversal of the burden of work onto the recipient using an identity-based key • Using a trusted intermediary to decrypt and re-encrypt the flow of messages • Less complexity in signature based solution • Additional Technologies: • Certificateless Public Key Cryptography (Al-Riyami and Paterson [2003]) • Certificate Chaining EuroPKI 2005

14. Lessons Learnt and Future Work • What are the main differences that impact on interoperation? • How the policy setting and validation is performed • Where and how the policy matching takes place • The difference in what is being certified and what is the content of the identifier • What additional work is needed? • An assessment of policy handling in light of actual security requirements • Potential for attribute certificates in cross-certification EuroPKI 2005

15. Conclusions • Existing technical solutions are far from ideal for the users in an identity-based environment • Candidate solutions either force identity-based clients to make use of certificates, or they require the use of trusted intermediaries • Building mechanisms to limit the impact at the user level is likely to require additional intermediary services EuroPKI 2005