RE: Asessment of TAMP with vendor hat on

["Reddy, Raksha P." <r.reddy@xxxxxxxxxxxxxxx>]

I am in favor of TAM as a PKIX WG item to develop a standard format for TAs
as well as a protocol to define an interoperable, in-bound mechanism to
remotely manage them.  Having such a protocol that enables either
session-oriented or store-and-forward mechanisms and is agnostic to
operating systems does not exist today.

The need for TAs exists in order to provide cert path validation as well as
to provide source authentication for delivery of signed objects such as
firmware and key material.  The need for TAM exists out of wanting a
non-proprietary in-bound means of managing trust anchors for various
applications, thus reducing the burden on TA Administrators and increasing
operational efficiency.  The need also exists to establish delegation of
authority and have a means to ensure that any given object is signed by the
appropriate constrained authority.  For example, a device may have multiple
applications that each require different types of firmware developed by
different sources.  The device can have constrained authorities so that each
firmware type can be validated from each respective source.  Furthermore,
having the flexibility to target TA configurations to a specific group of
devices is beneficial if changes need to be made to a particular TA that is
applicable to a specific set of devices.

Although TAMP and CCC are two drafts that were proposed to provide a
solution for TAM, I am not opposed to other solutions that also meet the
goals of the problem statement.  I do agree with Steve's comments that the
PKIX WG should use the last iteration of the problem statement as a starting
point in order to further define TAM requirements.  

Raksha Reddy
National Security Agency







-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On
Behalf Of Stephen Kent
Sent: Monday, December 17, 2007 1:56 PM
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