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

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
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 Franklins work in 2001, no
  efficient encryption mechanism existed
• Sender can encrypt a message to a recipient
  without having to retrieve the recipients public
  key

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
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
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
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
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
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
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
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
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
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
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