Trust Anchor Management Problem Statement 69 th IETF Trust Anchor Management BOF Carl Wallace

What are trust anchors? Trust anchors (TAs) are trusted public keys with with associated information –Used for signature verification –Associated information varies with TA purpose RFC3280 requires issuer name, public key algorithm, public key and optionally, the public key parameters associated with the public key to support certification path validation TAs are used for various purposes –Certification path validation –Verification of signed objects, including firmware, timestamps, OCSP responses, keys, etc. TAs are maintained in trust anchor stores, which are sets of one or more trust anchors

Problem statement There is currently no standard mechanism for managing trust anchor stores –Proprietary means abound –Remote management can be difficult (and is generally beyond the reach of PKI policy authorities) –Some application-specific standards are being developed (draft- ietf-dnsext-trustupdate-timers) No standard representation for trust anchors –Self-signed certificates are a de facto means of installing names and keys for use with PKI However, self-signed certificates do not provide hooks for TA management –Uniform representation may not be necessary even if common management means are used

General Proposal Define a protocol for managing trust anchor stores –Generic trust anchor representation requirements include trust anchor name, public key information and trust anchor usage –Enable add/remove/query operations on trust anchor stores Primary aim is to reduce reliance on out-of-band trust mechanisms –After initial trust anchors have been installed, out-of- band means should not be necessary

Functional properties Transport independent –Applicable to push or pull contexts –Applicable to session-oriented or store-and-forward contexts Support limited recognition of a trust anchor –Contrast with cross-certificates that establish relationships that impact all of a PKI’s relying parties –Ability to limit recognition to a single device, application or community would be useful in some contexts Enable secure transfer of authority over a trust anchor store from one owner to another –Re-key or transition from one TA manager to another –Transfer requires consent and cooperation Reduce the number of public keys that require out-of-band verification –Ideally, out-of-band verification (i.e., verifying trust anchor fingerprint with a trust source) occurs only during TA store initialization

Functional properties (continued) Define standard format for reporting trust anchor store contents –Simply generating a report of the contents of some trust anchor stores is difficult –Support authentication of store associated with the report Support disaster recovery (i.e., loss or compromise of trust anchor private key) –Including recovery from compromise of keys verified via out-of-band means and keys used to generate trust anchor management messages Enable representation of a trust anchor’s authority –Minimally, represent authority to conduct trust anchor management operations –Namespaces, policies, etc. in certification path validation context Enable delegation of authority –A trust anchor should be able to delegate all, some or none of its authority (including authority to conduct trust anchor management operations) Assuming a trust anchor manager is represented as a trust anchor

Functional properties (continued) Enable usage of trust anchors to verify certification paths in accord with RFC3280 –For path validation purposes, trust anchor representation must include public key, distinguished name, etc. –Other certificate extensions may be useful as well, i.e., SIA, name constraints, key usage, certificate policies Enable usage of trust anchors to verify signatures on objects other than certificates and CRLs –Firmware packages, trust anchor management messages, etc. Enable representation of trust anchors that cannot be used to verify certification paths –Some trust anchors may only be authorized to produce particular types of objects, such as firmware packages Guard against replay of old trust anchor management messages

Security Considerations No need for confidentiality Transaction integrity is required Clear subordination rules are required Requires at least one key to be installed during TA store initialization –Verified using out-of-band means –Could then be used to manage trust store contents