[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Draft Charter
At 9:46 AM -0400 8/13/07, Stephen Kent wrote:
You raise an important issue of perspective. If a TAA is an
"authority" then it can try to do anything (e.g., issue any command
in a protocol), but the effects of what it does are constrained by
the authority granted to it. That authority may be defined by the
user, or by some other TAA.
Exactly right. Our format/protocol gives TAAs the ability to state
what they want, but it is up to the receiving system to decide what
to do with that statement.
However, we do need to be very careful about the complexity of
polices that can be expressed here. We have lots of experience in
the security environment that suggest users, even sys admins, are
not very good at managing policies once the level of complexity
grows beyond a certain point. Our requirements development process
needs to be mindful of this issue, and not assume that users will
suddenly become much better at this crucial task.
Fully agree. My view on this is that:
- We need to make the single-TAA scenario work just as expected: the
end user will follow that TAA's instructions exactly.
- We need to make the multi-TAA scenario be simple. If we do not
allow deletes, then there is problem, but I think we need to allow
deletes. Given that, we should specify the simplest way to handle
deletes.
At 4:50 PM +0300 8/13/07, Yoav Nir wrote:
This just gave me a mental image of the next generation Internet
Explorer scary pop-up with the DN of the TAA and the DN of the new
TAA, a warning about possible exploits and data corruption, with the
final question "Do you accept this trust anchor?"
If the hierarchy is defined as the user adds TAAs, then no such
interaction is ever needed. I understand your desire for the
single-TAA model, but please don't say that the multi-TAA model is
more complicated than it needs to be.
For example, assume that the user has the setting "TAA1 is more
important than TAA2". Then, in your examples:
- If TAA1 adds a TA, can TAA2 delete it?
No.
What if TAA2 knows for a fact that the private key of the TA has
been compromised? The example I have in my head is TAA1 is
Microsoft (or Mozilla - the browser vendor), while TAA2 is your
company. I can't say that one is more important than the other.
If you cannot create a hierarchy, then you are forcing the user to
make decisions for every addition or removal of any TA. There was
strong pushback against that in Chicago. That leaves us with two
options: go with the single-TAA model, or go with a multi-TAA model
that does not require user interaction when new TAs are added or
current TAs are removed. I favor the latter.
--Paul Hoffman, Director
--VPN Consortium