Trust me Policy and Practices in PKI

“Trust me …” Policy and Practices in PKI David L. Wasley Fall 2006 PKI Workshop

Topics l l l l What is a CP and CPS What is in a CP and CPS Levels of Assurance HEPKI ‘generic’ CP PKI-lite CP/CPS Commercial CPs PKI and Federations 2

x. 509 Section 8. 1. 1 l l [The x. 509] framework contains three types of entity: the certificate user, the certification authority and the certificate subject (or endentity). Each entity operates under obligations to the other two entities and, in return, enjoys limited warranties offered by them. These obligations and warranties are defined in a certificate policy. Definition of the policy [is] performed by a policy authority. The set of policies administered by a policy authority is called a policy domain. Each entity may be bound to its obligations under the certificate policy in various ways such as by the act of importing an authority public key and using it as a trust anchor, by issuing a certificate that includes the associated policy identifier, or by accepting a certificate that includes the associated policy identifier and using the corresponding private key. A certification authority may place limitations on the use of its certificates, in order to control the risk that it assumes as a result of issuing certificates. 3

IETF RFC 3647 l l When a CA issues a certificate, it is providing a statement to a relying party that a particular public key is bound to the some attribute of a particular entity, shown as the certificate subject. The extent to which the relying party should rely on that statement by the CA, however, needs to be assessed by the relying party applications using certificates. Different certificates are issued following different practices and procedures, and may be suitable for different applications and/or purposes. CPs also constitute a basis for an audit or other assessment of a CA. When one CA issues a CA-certificate for another CA, the issuing CA must assess the set of certificate policies for which it trusts the subject CA. The appropriate set of certificate policies is then indicated by the issuing CA in the CA-certificate. The X. 509 certification path processing logic employs these CP indications in its defined trust model. 4

Certification Policy l l An attempt to reassure a Relying Party of the trustworthiness of the certificate signature and the binding between the public key and the entity represented in the Subject fields Should be appropriate for the intended uses of issued certificates - not more burdensome Is an implied contract … Should be used in validating a certification path but few applications do so (yet). 5

What’s in a CP l CA Organization, purpose, community l l Information repositories l l Published certificates and other info. Identification of certificate subjects l l PA, OA, RA, Subjects, appropriate uses ID verification required, DN’s allowed, etc. Certificate lifecycle management l Issuing, changing, revoking, renewing, . . . 6

What’s in a CP (cont. ) l CA facility management l l Technical security controls l l CA key gen, key sizes, archive, system, . . . Certificate, CRL, OCSP profiles l l Physical, procedural, personnel, audit logs, . . . Defines what’s in a cert and CRL Compliance audit, changes, etc. l Ensuring trust and continuity 7

What’s in a CPS l l l How the specifications in the CP are implemented May contain important information for Relying Parties or cross certification evaluation The CPS is made public at the cps. URI l l Points to the CP Some information, e. g. location of the CA or security measures, is in a non-public doc. 8

CP Contents (RFC 3647) 1. INTRODUCTION & OVERVIEW 2. PUBLICATION AND REPOSITORY RESPONSIBILITIES 3. IDENTIFICATION AND AUTHENTICATION OF SUBJECTS 4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS 5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS 6. TECHNICAL SECURITY CONTROLS 7. CERTIFICATE, CRL, AND OCSP PROFILES 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS 9. OTHER BUSINESS AND LEGAL MATTERS 9

Levels of Assurance l l The certificate CP OID may refer to a subset of the CP document that defines a particular “level of assurance” for the certificate Based on operational and technical requirements Intended to accommodate varying use cases Federal PKI defines at least four l Rudimentary, Basic, Medium, High 10

HEPKI “generic” CP l l Circa 2002 Based on the FPKI CP at the time l l Intended to be (fairly) easily adopted by HE campuses Needs to be converted to RFC 3647 format l l Same 4+ initial levels of assurance Should enable cross-certification with the FBCA Will be done if/when there is sufficient interest See http: //middleware. internet 2. edu/certpolicies/ 11

PKI-lite CP/CPS l Pragmatic approach to PKI policy framework l l Should be good enough for a lot of H. E. apps l l l Basically “whatever you do now to issue on-line IDs” S/MIME Better on-line credentials for internal campus apps Proof of concept for advanced apps USHER is based on this model (more later) Intended to alleviate a perceived roadblock to broader PKI use 12

PKI Domains & Trust Anchors l l A PKI Domain is a set of CAs conforming to the same policy A Trust Anchor is the highest level CA in a hierarchy that implements that policy l l Trust is based on understanding the policy Applications may be configured to look for a LOA Your browser contains 100+ Trust Anchors The PKI trust model is based on accepting certificates that are issued under a policy that the Relying Party understands - i. e. “trusts” 13

Commercial PKI CPs l Commercial PKI vendors have CPs that protect their business interests l l May be very different than RFC 3647 l l Thus hard to compare … Applications are beginning to care l l You may or may not be comfortable with them How do they pre-configure for 100+ CPs? ! Read them carefully before you sign up 14

PKI and Identity Federations l PKI is complementary to Federations l l l Therefore, Federations need “policy” too l l PKI provides the credential Federation provides the identity information We’re just beginning to understand this implication Federation operators could serve as trust brokers, in much the same way as PKI bridges 15

Questions? l dlwasley@earthlink. net 16