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

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

3. 30th June 2005 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?

4. 30th June 2005 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

5. 30th June 2005 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

6. 30th June 2005 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

7. 30th June 2005 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

8. 30th June 2005 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

9. 30th June 2005 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

10. 30th June 2005 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

11. 30th June 2005 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

12. 30th June 2005 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

13. 30th June 2005 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

14. 30th June 2005 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

15. 30th June 2005 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