[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Draft Charter


At 6:55 PM -0400 8/9/07, Turner, Sean P. wrote:

Strawman charter for trust anchor management (tam) BoF

Version: 01, July 9th 2007

Chair(s)

TBD

Security Area Director(s):

-  Tim Polk <tim.polk@xxxxxxxx>
-  Sam Hartman <hartmans-ietf@xxxxxxx>

Security Area Advisor:

TBD

Mailing Lists:

General Discussion: ietf-trust-anchor@xxxxxxxx
To Subscribe: http://www.vpnc.org/ietf-trust-anchor/
Archive: http://www.vpnc.org/ietf-trust-anchor/mail-archive/

Description of Working Group:

The need for a standard protocol for trust anchor management has been
recognized for some time.  Many groups within the IETF, including PKIX,
Kerberos, TLS and SIDR have a dependency on trust anchors, yet provide no
generic mechanism for the their management.


Editorial nit: a comma is needed after "SIDR".




A trust anchor is a public key and associated data used by a relying party to
begin the process of validating a signature on a signed object. Associated data 
is used to define the scope of the use of the trust anchor for validating
signatures; for example, associated data might limit the types of identifiers
in certificates that a trust anchor is allowed to validate.

Despite the wide-spread use of trust anchors, there is no standard means for
managing these security-critical data.  This Working Group will develop a
specification to fill this gap.

The initial problem statement for this work is to be based on:

- draft-wallace-ta-mgmt-problem-statement

The scope of the work is to include:

<<list to be developed in Chicago>>


Chicago is now in the past; elide that.


- Supporting a single trust anchor administrator, such as in a typical
  enterprise, who may be administering multiple trust anchors in her domain,
  where those trust anchors can be either local or "foreign"
- Supporting multiple trust anchor administrators, such as is typical for home
  users
- Supporting devices with limited or no user interface that may or may not have 
  connected to the Internet
Some of the questions at the mic made it clear that people had issues with user interface. It might be better to separate that out into two bullet items: 

- Supporting systems with limited or no user interface
- Supporting devices that may or many not be connected to the Internet at the time of management 



The following are out of scope of this work:

<<list to be developed in Chicago>>
- TBD


I think this is non-controversial for out-of-scope:
- Management of non-anchor signature validation objects such as intermediate certificates in a validation path. 

This might be more controversial, but should be considered as out-of-scope:
- Mandating whether the recipient of trust anchors from a trust anchor manager will use those anchors 



The deliverables will be:

- An informational problem statement/requirements specification
  for a trust anchor management protocol
- A standards track trust anchor management protocol
  specification

Goals and Milestones:

+6 months                 WG last call on problem statement/requirements
+9 months                 Adoption of WG draft protocol spec.
+15 months                WG last call for protocol spec.




--Paul Hoffman, Director
--VPN Consortium