Re: Draft Charter

[Yoav Nir <ynir@xxxxxxxxxxxxxx>]

In Chicago there was some controversy about whether multiple  
administrators should be in scope. This charter draft says that  
they're in. I'm not saying they shouldn't be, but it does add  
complexity.

If they're in, we need to answer big questions:
- If TAA1 adds a TA, can TAA2 delete it?
- If no, should there be "hard-delete" where it does delete it?
- If TAA1 adds a TA, and then TAA2 adds it again, and then TAA1  
deletes it, is it there or not?
- Should TAA2 be able to query TAs added by TAA1?
- Should we have a delete-all command (I think that's necessary for  
the store-and-forward scenario)
- How does delete-all interact with multiple TAAs? Do we need a hard- 
delete-all?

I would answer these questions no, yes, yes, yes, yes and yes, but  
these are far from trivial.

I think these and other issues suggest we should split the TAMP  
protocol deliverables into two documents: one to deal with the  
protocol, formats, encoding (XML/ASN.1) and the online/offline case.
The other document should deal with trust anchor store operations:  
how the database is structured and what it does with the various  
commands.

Yoav


> 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.
>
> 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>>
> - 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
>
> The following are out of scope of this work:
>
> <<list to be developed in Chicago>>
> - TBD
>
> 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.