[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Revised draft charter (redux)
It's been brought to my attention that I messed up the scope items. Here's
an updated draft.
--------------------------------------------
Strawman charter for trust anchor management (tam)
Version: 03, August 21st 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.
A trust anchor represents an authoritative entity represented by a public
key and associated data. Trust anchors are comprised of a public key and
associated data. The public key is used to verify digital signatures and
the associated data is used to constrain the types of information for which
the trust anchor is authoritative. Relying parties use trust anchors to
determine if digitally signed information objects are valid by verifying
digital signatures using the trust anchor's public key and by enforcing the
constraints expressed in the associated data.
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:
- Supporting a single trust anchor administrator, such as in a typical
enterprise, who may be administering multiple trust anchors in her domain
- Supporting multiple trust anchor administrators, each of whom is
independant
- 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 (e.g., physical delivery)
- 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 were suggested as out of scope:
- Management of non-anchor signature validation objects such as intermediate
certificates in a validation path.
- 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.