RE: Assessment of TAMP with vendor hat on

[Russ Housley <housley@xxxxxxxxxxxx>]

Stefan:

First, the problem statement was posted many months before a 
protocol.  That problem statement lead to a long discussion on the 
mail list that was set up for the TAM BOF.  That lead to people 
asking whether a protocol existed to address the problem.  So, the 
protocol was posted as a strawman.  Unencumbered alternatives that 
address some or all of the problem space are welcome.

Second, the problem statement is the primary rationale. Individual 
design decisions can be discussed as this work moves forward.

Third, there are hardware module vendors that have express interest 
in TAMP.  Obviously, interest was not expressed by a large operating 
system vendor.  An Microsoft Update-based or Active Directory-based 
solution is not appropriate in many environments.  However, there is 
a need, and interoperability is vital.

In terms of compromise, I can see the value in separating the trust 
anchor structure from the query/response protocol.  This allows 
proprietary protocol environments to make use of it, but it does not 
diminish the need for the query/response protocol.

Finally, I agree with your call for input from the whole 
community.  I do not want to put a lot of effort into this structure 
and protocol unless it will be widely implemented.  Some folks have 
spoken up.  I'd like to hear from more.  Don't be bullied.  Speak your mind.

Russ

________________________________

From: Stefan Santesson <stefans@xxxxxxxxxxxxx>
Sent: Thursday, December 13, 2007 3:02 PM
To: ietf-pkix@xxxxxxx
Subject: Asessment of TAMP with vendor hat on
	
	When it was requested that the TAM work would present at PKIX, it
was advertised as a presentation of a problem statement.

	However, what I saw was more a presentation of a protocol with a
clear direction, but not much of the rationales behind this solution.

	An important factor of whether to adopt this work is not only if the
area as such is of importance, it is even more important to make an
assessment of how this fits into our current IT infrastructures. E.g. if
there are any Vendors interested in implementing this and for what problems
they see this as a preferred solution.

	I'm here taking my pkix-chair hat of and my vendor hat on to provide
an assessment of how this fits into Microsoft product infrastructure and
what problems I see. However, this is still a personal contribution,
expressing my personal view.

	Background.

	Microsoft already has a solution for distribution and management of
trust anchors. As soon as a host or device enters as a member of a network
it becomes member of a security infrastructure based on some primary
credentials. Vital data and security relationships are managed through
common repositories, e.g. the Active Directory. The domain joined
environment adds refined management capability of trust anchors /root keys.

	In the global environment, trust anchors/roots are managed through
Microsoft update. Both infrastructures share common architectural
principles. In no case is this a query/response protocol. Clients are
pulling status information from a trusted source protected by a basic
pre-configured and later upgraded security infrastructure. Based on this
information the client/host/device pulls down and authenticates necessary
TAs to appropriate TA stores on the local host, such as stores on machine,
user and application levels.

	Need

	The need I see in this area is primary focused on a standardized
data structure for TAs that is not provided in the form of a self signed
root. A second void area could be a standard structure for a main repository
to store a list available TAs and their applicability. For the first issue
we have no solution today, for the second we do have a proprietary format
for a signed root list.

	Need for a query and response protocol.

	I can't see any need for this type of protocol. The query and
response protocol provide quite an amount of unnecessary overhead and
redundancy in term of infrastructure, protocols and security infrastructure
and is a lot less flexible than incorporating this into an existing data
management and security infrastructure. A query and response protocol to a
central function with signed response also comes with scaling issues. There
are significant advantages to have a dumb repository containing pre-signed
objects over an active protocol with signed requests and responses. The sum
of this is that the query and response protocol aspects of the TAM proposal
brings significant complexity that does not solve any current problems.

	Scope

	Some may claim that the proposed protocol is needed for other
architectures than the private hosts on the internet or the enterprise
environment, but if that is the case, the scope of this protocol should be
clearly defined. If this is developed as the IETF protocol for TA management
for all environments, then this is a big problem as it clearly does not fit
well with many current infrastructures.

	Call for opinions from supporters and implementers

	If you support this protocol as the direction for this work, I would
like to know what problem it solves for you and if you are prepared to
implement this.

	Conclusion

	I support TAM as work item in PKIX as a general problem area. I
reject the current protocol proposal as the basis for doing this work in
PKIX.

	If TAM is accepted, I propose that the work focus on a common data
format for storing TAs both in the form of self signed root certificates and
as key+paramenters. If more work needs to be done, it should first be
preceded with a requirements document (or problem statement) where we all
can agree of the scope of the protocol to be defined.

	
	Stefan Santesson
	Senior Program Manager
	Windows Security, Standards