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

RE: Draft Charter



Draft 02 of the charter captures these, which I will distribute after some
more discussion on the TA definition.

>-----Original Message-----
>From: owner-ietf-trust-anchor@xxxxxxxxxxxxx 
>[mailto:owner-ietf-trust-anchor@xxxxxxxxxxxxx] On Behalf Of 
>Paul Hoffman
>Sent: Friday, August 10, 2007 10:51 AM
>To: ietf-trust-anchor@xxxxxxxx
>Subject: 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
>