1 / 20

Communications-Electronics Security Group

Communications-Electronics Security Group. PKI interoperability issues for UK Government. Richard Lampard Richard.Lampard@cesg.gsi.gov.uk. Structure. 1. What is CLOUD COVER? 2. Interoperability testing 3. Trust models 4. Wish list 5. Summary. 1. What is CLOUD COVER?.

miya
Download Presentation

Communications-Electronics Security Group

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Communications-Electronics Security Group

  2. PKI interoperability issues for UK Government Richard Lampard Richard.Lampard@cesg.gsi.gov.uk

  3. Structure 1. What is CLOUD COVER? 2. Interoperability testing 3. Trust models 4. Wish list 5. Summary

  4. 1. What is CLOUD COVER? CLOUD COVER aims to ensure that government departments have access to the widest possible range of secure, interoperable and cost effective PKI solutions.

  5. 2. Interoperability testing CA CA CA

  6. 2. Interoperability testing PCA PCA PCA CA CA

  7. 2. Interoperability testing • COAST system is very, very simple … • … but it took a lot of work to achieve interoperability!

  8. 2. Interoperability testing • Experiences in COAST • misinterpretations of standards e.g. wrong version • encoding problems e.g. DER versus BER, GeneralizedTime vs UTCTime, DN ordering • problems with tools e.g. ASN.1 compiler bugs • dealing with incorrect behaviour e.g. processing certification requests • missing functionality e.g. ARLs • mistakes e.g. keyUsage & basicConstraints • invalid assumptions e.g. populating keyIdentifier • implementation limitations e.g. serial number length

  9. 2. Interoperability testing Very hard! Simple,interoperablesolution Fully functional,interoperablesolution Very, veryhard indeed! Fully functional, non-interoperablesolution Requirement

  10. CA CA CA Repository CA CA CA CA CA CA CA CA 2. Interoperability testing

  11. 2. Interoperability testing HMG Root CA (Baltimore) Ministry of Ministry of Ministry of Ministry of Ministry of Works Transport Education Plenty Truth (Entegrity) (Entrust) (Spyrus) (NIST) (Baltimore)

  12. 2. Interoperability testing • Conclusion? • It doesn’t work!

  13. 2. Interoperability testing • Experiences with testbed: • on-line cross certification relies upon proprietary protocol exchanges, procedures and token standards • certificate extensions not processed • directory schema e.g. same OID representing different object classes • inability to use same Directory • name encoding e.g PrintableString vs TeletextString, RFC 822 address included in DN

  14. 2. Interoperability testing • Manual cross certification between different products is limited • achieved between other products and Notary • using Entegrity PKIBench toolkit • pre-certificate imported to Notary CA • Entegrity token created for it • could develop similar toolkits for all other products

  15. 2. Interoperability testing • What is happening to the IETF!? • divergent working groups (PKIX, SPKI, OpenPGP) • competing PKIX standards (CMC versus CMP) • massive proliferation of standards ...

  16. 2. Interoperability testing • Representation of elliptic curve DSA (ECDSA) keys and signatures in Internet X.509 PKI certificates • Certificate management message formats (CMMF) • Certificate management messages over CMS (CMC) • Caching on-line certificate status protocol • Web based certificate access protocol (WebCAP/1.0) • Enhanced CRL distribution options(OCDP) • Time stamp protocols • Data validation and certification server protocols • PKIX roadmap • Qualified certificates • Diffie-Hellman proof of possession algorithms • An Internet attribute certificate profile for authorisation • Basic event representation token v1 • Extending trust in non-repudiation tokens in time • Simple certificate validation protocol (SCVP) • Using HTTP as a transport protocol for CMP • Limited attribute acquisition protocol • RFC 2459 - Certificate and CRL profile • RFC 2510 - Certificate management protocols (CMP) • RFC 2511 – Certificate request message format (CRMF) • RFC 2527 - Certificate policy and certificate practices framework • RFC 2528 – Representation of key exchange algorithm (KEA) keys in Internet X.509 PKI certificates • RFC 2559 – Operational protocols: LDAPv2 • RFC 2560 – Online certificate status protocol (OCSP) • RFC 2585 – Operational protocols: FTP and HTTP • RFC 2587 – LDAPv2 schema • Operational protocols: LDAPv3 • Limited attribute certificate acquisition protocol • OCSP extensions • Using HTTP as a transport protocol for CMP • Using TCP as a transport protocol for CMP • A string representation of general name – allows representation of GeneralName when not using ASN.1 encoded protocol (e.g. configuration file) • Technical requirements for a non-repudiation service • PKIX profile for IKE – allows use of PKIX certificates with IPSec.

  17. R B 3. Trust models We would like to use all three in Government ... … but we are generally stuck with hierarchies

  18. 4. Wish list • PKI Forum should feed into IETF PKIX WG • Don’t forget client interoperability and Directory issues • Interoperability should not be exclusive among Forum members • Testing service or reference implementation • Liaise with other initiatives e.g. ECAF, TIE, Identrus

  19. 5. Summary • Lack of interoperability will be a major problem for UK Government • PKI Forum efforts are very welcome • Ensure that the work is coordinated with other international efforts

  20. Communications-Electronics Security Group

More Related