Trust Anchor Management Problem Statement

1
Trust Anchor Management Problem Statement

• 69th IETF
• Trust Anchor Management BOF
• Carl Wallace

2
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

3
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

4
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

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

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

7
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

8
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