At 7:49 AM -0700 8/24/07, Paul Hoffman wrote:
At 7:30 AM -0400 8/24/07, Turner, Sean P. wrote:As for the TAA definition, how about: A Trust Anchor Administrator (TAA) is the entity represented by the trust anchor. The TAA controls the private key of the trust anchor.A public key with associated crypto parameters and associated restrictions do not "represent" anyone.
In many cases a TAA does represent an entity, e.g., an organization, though perhaps not always. For example, in the home context the user may be a TAA, in the enterprise context the IT organization for the enterprise may be a TAA, etc.
Further, this definition breaks the model we have been discussing, where a TAA gives the client one or more TAs for the client to install. This definition causes the client to now have many TAAs, one for each TA they installed.
Sorry, I guess I missed this part of our discussion. I don't tend to think of a TAA providing TAs that may or may not be installed, at the whim of a client, unless the client is a TAA with greater privilege.
Going back to the definition presented in Chicago:A Trust Anchor Administrator (TAA) is an entity which gives trust anchor instructions to clients.
I don't think this is a good definition, to the extent that it suggests the client may or may not act on the instructions. At least in some contexts with which I am familiar, the client does not have a say in this matter. That's why I would feel more comfortable with a definition that didn't suggest that the client has the last word here.
This says that anyone can be a TAA, although obviously a particular client will only listen to one or a small number of TAAs.
For a TA we have always said that it is up to an RP to decide whether a given entity who purports to be a TA IS accepted as a TA by the RP. The problem here is that we're talking about managing TAs, and acknowledging that the user of a computer or device may not have total control over the TAs installed in it, in all cases.
Steve