olnes pki interoperability

Category: Entertainment

Presentation Description

No description available.


Presentation Transcript

PKI Interoperability by an Independent, Trusted Validation Authority: 

PKI Interoperability by an Independent, Trusted Validation Authority 5th Annual PKI R&D Workshop NIST, Gaithersburg, Maryland, USA Jon Ølnes, DNV Research, Norway 04.04.2006

DNV – an independent foundation: 

DNV – an independent foundation Objective: To “Safeguard life, property, and the environment” Established in 1864 in Norway (purpose: independent assessment of quality of ships to aid insurance tasks)

DNV worldwide: 

DNV worldwide > 6000 employees, about 300 offices in about 100 countries

DNV and digital value chains: 

DNV and digital value chains DNV has existed as an independent, trusted party for 140 years Ship and process industry classification and certification Certification to ISO 9000, ISO 14000, BS 7799 etc. Carry on this position to new areas Digital value chains / processes between actors Which trusted roles are needed for such processes? Which roles may be of interest for DNV to take? ”Safeguarding life, property, and the environment” applied on digital value chains PKI and digital signatures are key elements in securing such processes


Reshaping own business processes (e-processes) Strong need for signatures, e.g. issuing ship certificates Role as PKI Relying Party, e.g. receiving documentation from actors DNV’s own PKI requirements (example) Global PKI interoperability is required for these e-processes built in Finland to DNV Class equipment from Germany steel from South Korea USA based ship owner Bahamas registered Insured in UK, calls port in Singapore, …. Signed documents must be verified by other parties than those involved in the signing process

Example: e-Procurement in EU public sector : 

Example: e-Procurement in EU public sector “Directives oblige any public purchaser in the EU to effectively recognize, receive and process tenders submitted, if required, with a qualified signature and their accompanying certificates, regardless of their origin within the EU or their technical characteristics” “The existing significant differences between qualified signatures …. should therefore be reason for great concern. The interoperability problems detected despite the existence of standards …. pose a real and possibly persistent obstacle to cross-border e-procurement.”

Need for PKI interoperability: 

Need for PKI interoperability = eService providers

The challenges to the Relying Party: 

The challenges to the Relying Party Is the certificate valid? Check the CA’s signature Verify content Verify timestamps Verify that the certificate is not revoked Is the quality of the certificate sufficient for the purpose at hand? Legal status (qualified etc.)? Quality as described by certificate policy and other documents? Compliance with claimed quality level? Shall I trust the CA? High quality, but it is located in Iraq … What happens if anything goes wrong? What liability does the CA take on? What recourse do I have to claim this liability? An RP needs different trusted services than a Certificate Holder

What about trust structures?: 

What about trust structures? Start with your own CA to obtain a trusted copy of remote CA’s public key May indicate quality (policy mapping, hierarchy base policies) Revocation checking must still be done towards remote CA May be a software integration and efficiency problem Liability still resides with remote CA Check the CA’s policy Path processing (especially discovery) can be very complex

Risk management requires agreements: 

Risk management requires agreements Relying on general statements in policies is too risky Written in Russian, referring to Russian law … An RP cannot enter agreements with all CAs Cannot by itself judge quality and liability Unknown risk situation A CA cannot have agreements with all possible RPs Europe: In principle unlimited liability for issuers of qualified certificates Unknown risk situation for the CAs

DNV’s approach – the VA: 

DNV’s approach – the VA = eService providers VA service

“One stop shopping” for Relying Parties: 

“One stop shopping” for Relying Parties The VA is an independent trust anchor, trust is not delegated from the CAs Challenges the PKI axiom that only a CA may be a trust anchor The VA handles each CA individually Must be independent from any CA – treat all CAs on equal terms Eliminates need for certificate path discovery and validation One agreement for processing of certificates, irrespective of origin One point of contact and billing Proper management of risk and liability Removal of complexity Classification and assurance of quality Acceptance of liability (agreement RP/VA) Transfer of liability (agreements VA/CAs) One software integration Web Service interface proposed for the VA service Scalability Acceptance of new customers, with certificates from “new” CAs

The business case – win * 4: 

The business case – win * 4 The Relying Party One stop shopping and proper risk management The Certificate Holder Possibly better reuse of the certificate The Certificate Authority Better reuse of certificates – more relying parties Agreements with RPs through VA – improved risk management The VA is not visible and shall not jeopardise CAs’ business models CAs tend to react positively to the idea of a VA … The Validation Authority On-line services that customers are willing to pay for(?) There should be a competitive market for VA services Open specifications, in the end preferably standardised

Authentication is not trust: 

Authentication is not trust A certificate provides Authentication – knowing “with certainty” the name of the counterpart “Proof” of this authentication Mechanisms for secure communication This is not sufficient to trust the counterpart Knowing the name of the crook does not make him honest Naming is an issue Does the name in the certificate make sense to the relying party? Or can it be translated into a meaningful name? A VA service can provide (or support) identity management services Trading between unknown parties requires other trust anchors Notary services, brokers, marketplaces, trusted semantic web etc.

VA services: 

VA services

Classification (ongoing development work): 

Classification (ongoing development work) Objective criteria for certificate classification must be derived Base on existing work (FBCA, EU qualified level, ETSI, ABA, research etc.) A CA is classed based on policy and other documentation (CPS etc.) May include other information on CA and owners (customer base, credit rating, income versus expenses etc.) Classification for a VA may be less stringent than policy mapping for x-cert Level of compliance must be assessed Study of documents, self-assessment, surveillance, third party audit report, certifications etc. Indicate quality as numerical value or profile (structure) VA matches customer (RP) requirements with CA quality Criteria may be turned into standards And be used as basis for third party certification (DNV business area)

VA services architecture: 

Interface to CAs and info providers Interface to RPs VA services architecture Certificate validation engine Signature verification service CA info db Auxiliary info service Auxiliary info db CRL pre-fetch component Cert revocation status cache LDAP or other interface to CA OCSP client towards CAs LDAP or WS client to info provider Certificate directory access Web Service component SOAP

Some implementation issues: 

Some implementation issues Interface/integration towards relying parties Web Services / SOAP preferred Based on the XKISS part of XKMS Security and authentication by SSL, and/or XML-DSIG and XML-Encryption Interface towards CAs (and other information providers) CRL pre-fetch to VA preferred – polling, not only on schedules OCSP client towards CA must be supported LDAP or other to fetch certificates when only reference given Information stored locally Enables historical validation, according to time-stamp parameter in request or time-stamp in old, signed document For audit purposes and to prove reason for answers DNV’s development partner is Ascertia Ltd. (UK and Pakistan) http://www.ascertia.com

Prerequisites and challenges: 

Prerequisites and challenges PKIs must be sufficiently ”open” Some PKIs require each relying party to install particular software The CAs’ business models must support a VA service Privacy Do not track use of certificates across RPs! Sufficient security of logs and other information VA services and relying party preferences A VA service may be ”one size fits all” (base validation policy issued by VA) Or configured to the needs of the individual VA customer E.g. specify particular rules for CAs that shall/shall not be trusted Customer specific validation policies Availability of the VA (single point of failure) Distributed architecture needed Replication for performance and availability Localisation “close” to customers may be required Legal challenges in some countries?


Conclusions VA services proposed as approach to PKI interoperability Reuse of certificates Agreements-based model No path processing VA as trust anchor for the RP One contract partner and one integration VA answers for “any” CA Separate trust anchors for CH and RP may be a better trust model First version of DNV’s VA service available for pilot customers summer 2006


Thank you for your attention! Jon.Olnes@dnv.com +47 47846094

authorStream Live Help