RE: Asessment of TAMP with vendor hat on

[Stefan Santesson <stefans@xxxxxxxxxxxxx>]

Steve,

I think we are mainly in agreement on all points.

Let me recap my major points:

1) I support the TAM work in PKIX as a problem area to work on
2) I object to accepting the current protocol proposal as the starting point of this effort.

We seem to agree on both.

In finding a good basis for doing this work, I think it is important to notice and acknowledge what problems we are facing today, as developers and as users and match that to how we approach this problem today in absence of any standard so migration into a common standard becomes feasible and likely to happen. To just look at what could be nice in theory often leads down a slippery slope and tends to produce an overly complex protocol solution after 5-10 years that is detached from real problems and therefore fails wide deployment.

I would stress that we must not forget that TA management is a support function to other security protocols, and that it is in the basic security assumptions of these security protocols where the actual security requirements for TA management can be understood.
The challenge of this group is to consider both the management model of a central function with complete authority over local TA stores on distributed Hosts and the model where the TA distributing environment merely support the hosts with a reliable source of TAs. Both models can be managed, one directly and the other indirectly.

I'm not convinced yet the directly managed model is needed, but that can be saved for future debate.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: Stephen Kent [mailto:kent@xxxxxxx]
> Sent: den 17 december 2007 19:56
> To: Stefan Santesson
> Cc: ietf-pkix@xxxxxxx
> Subject: RE: Asessment of TAMP with vendor hat on
>
> Stefan,
>
> A few of observations about you TAM comments, many of which may have
> been stated by others, since I am late in responding:
>
>         - you are right that the presentation we saw in Vancouver
> focused on a solution, not a problem statement. PKIX will need to
> start with a problem statement (or a requirements I-D) that the WG
> agrees upon.  There was considerable discussion of the problem
> statement on the TAM mailing list. I think we can start from the most
> recent iteration there, but this will need to be developed in the
> context of PKIX, i.e., we are not rubber stamping what was done
> before.
>
>         - we need an interoperable solution, in typical IETF style,
> so whatever Microsoft or other vendors have done may be useful as
> input, but it probably is not a substitute for a IETF standard.
>
>         - there were suggestions on the TAM list that offline
> management was needed. So any solution that relies on live
> connectivity is not sufficient, IF the WG agrees with this as a
> requirement.
>
>         - the TAM list also indicated a desire to have a flexible
> management capability, in which one TA, with ultimate responsibility
> for the managed object, can delegate authority to other entities to
> manage TAs with constrained scope. My quick read of what you
> described as the MS management capability did not seem to accommodate
> this sort of delegation. Again, if PKIX decides this is a real
> requirement, that motivates developed of a more sophisticated
> management framework.
>
>         - in certain contexts the receipt capability seems useful, as
> does the ability to query a managed device to determine which TAs are
> installed, etc. Again, we'll have to see whether these are features
> that the WG agrees are needed.  If so, then they motivate a
> request/response protocol model.
>
>         - the secure TA replacement function defined in TAMP seems to
> be attractive, and hopefully not patent encumbered, and would be a
> nice feature for PKIs to have, although I agree that it could be
> accommodated as a cert extension without the rest of TAMP.
>
> Steve