RE: Multiple TAAs

[Russ Housley <housley@xxxxxxxxxxxx>]

I strongly support Carl's point.  In performing delegation, it might
be very useful to apply limits to the delegation.  X.509 already has
a very good set of certification path validation constraints that will
work nicely.  However, there seems to be one missing in this
context.  It would be very useful to constrain the applications that
the delegated-to trust anchor could impact.

Russ

Carl Wallace wrote:

>   
> <snip> 
> > > At 12:11 PM 8/17/2007, Black_David@xxxxxxx
> wrote: 
> > > >My preference is that managing different
> privileges for 
> > multiple TAAs 
> > > >administering the same trust anchor store
> ought to be out 
> > of scope, 
> > > >unless someone has a compelling use case with
> which to argue 
> > > >otherwise. 
>
> Requiring separate trust stores to accommodate multiple
> trust anchor managers with different privileges is one approach, but it
> might not be the easiest to manage.  Depending on how it is
> supported, routine rekey may be one example for allowing multiple TAAs
> with different privileges.  For example, a TA that is authoritative
> for namespace X could generate a management message that could be used to
> add its new key to a trust store and remove its old key.  Assuming
> the trust store has multiple TAs for different namespaces, there would be
> multiple TAAs with different privileges.
>
> <snip> 
> > > So, I can imagine the enterprise holding an
> all-powerful 
> > TA, and using 
> > > this to add and delete TA administration
> privileges for the trust 
> > > anchor stores in the devices and software packages
> that are used in 
> > > the enterprise.  The TA administration
> privilege must not be 
> > > sufficient to become the all-powerful TA.
> > 
> > All of the TAs in the above paragraph are the anchors
> for the 
> > trust stores which in turn contain trust anchors for
> use by 
> > applications. 
> > 
> > For clarity, let's use the term Trust Store Anchor
> (TSA) to 
> > refer to an anchor that confers the ability to manage
> > application trust anchors in a trust store, and use the
> term 
> > Application Trust Anchors 
> > (ATAs) if/as necessary for clarity. 
> > 
> > Using this terminology, the scenario that Russ is
> concerned 
> > about boils down to controlling which TSAs can manage
> the 
> > TSAs for a trust store.  Both TSAs can manage all
> the 
> > application TAs, as the enterprise presumably trusts
> the 
> > contracted service to correctly manage the 
> > enterprise-specific ATAs (and if the enterprise
> doesn't, I 
> > strongly suggest that it should resort to the
> "send all your 
> > updates through me" solution described for
> Microsoft updates 
> > in earlier messages). 
>
> Why limit the arrangement such that the contracted service
> can manage everything?  It doesn't seem like much of a stretch to
> use constraints similar to those we've discussed for application TAs,
> i.e., name constraints or usage constraints.
>
>   
> <snip> 
> > One more item.  Russ wrote: 
> > 
> > > I see no reason for there to me more than one
> all-powerful 
> > TA as long 
> > > as the all-powerful TA can be used to make updates
> to the 
> > all-powerful 
> > > TA, say when two enterprises merge. 
> > 
> > The reason may be dealing with private key compromise
> in a 
> > tractable fashion - if an all-powerful TA needs to be
> revoked 
> > (e.g., via a CRL), it would be more than convenient to
> have 
> > another one to use.  Two should be enough.
>
> This suggests we need to be able to represent: a pair all
> powerful TSAs, if for no other reason than recovery from compromise or
> loss; one or more(?) less-powerful TSAs; and a set of
> ATAs.