Re: Draft Charter

[Yoav Nir <ynir@xxxxxxxxxxxxxx>]

Inline...

On Aug 12, 2007, at 7:55 PM, Paul Hoffman wrote:

> At 9:18 AM +0300 8/12/07, Yoav Nir wrote:
> > 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.
>
> Indeed. But the complexity might be able to be contained with very  
> different assumptions than the ones you made.
<snip>
> This takes the view that the TAAs "add" and "delete" TAs. A very  
> different view, one that makes things a lot simpler, is that TAAs  
> propose additions and deletions, and the software for the recipient  
> of those proposals chooses whether or not to act on those  
> proposals. As I said at the mic in Chicago, I'm not suggesting that  
> end users need to think about each TAA action; they can just make  
> policy decisions and let the software act accordingly.

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?"

> 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 no, should there be "hard-delete" where it does delete it?
>
> No. I would be against having various strengths of "add" and  
> "delete"; no one will be able to figure them out.

Again, I think there should be a distinction between "I don't use  
this CA any more" and "this CA is no longer trustworthy"

> > - If TAA1 adds a TA, and then TAA2 adds it again, and then TAA1  
> > deletes it, is it there or not?
>
> It is not.

IMO this should depend on why TAA1 deleted it.  There's a difference  
between "we've switched to Verisign" and "NetLock has been compromised"

> > - Should TAA2 be able to query TAs added by TAA1?
>
> Yes. A simpler and more general mechanism is that any TAA can query  
> the TA store, and that store says which TAA added each TA.
>
> > - Should we have a delete-all command (I think that's necessary  
> > for the store-and-forward scenario)
>
> No. That would leave the user with no one to trust, including the  
> party that issued the delete-all. The TAM software should never  
> leave the user with no TAs except under dire circumstances.

I have two issues with this:
1. I don't think the TAM anchor should be in the same store that it  
is managing. I don't even thing TAM should be administered with TAM.
2. If Microsoft (as TAA1) wants to give the users a whole new set of  
anchors, it makes sense to send in a single message, a "delete-all"  
command and several "add" commands. this works even better if we make  
a separation between anchors added by different TAAs.

> > - How does delete-all interact with multiple TAAs? Do we need a  
> > hard-delete-all?
>
> Moot; see above.
>
> I believe that most users who have multiple TAAs could set an order  
> for precedence to them. I also think writing software to act on the  
> precedence is quite straightforward: the two rules are "only allow  
> delete proposals from TAAs at the same level or higher as the TAA  
> who added this TA" and "if a TA has been deleted, only allow it to  
> be re-added by a TAA at the same level or higher than the one who  
> deleted it".
>
> Does this simplification seem like a good one?

I would rather have a system where each TAA manages the TAs that it  
has added, with provisions for multiple additions and deletions. I  
don't think precedence is a good simplification.

Yoav