RE: Asessment of TAMP with vendor hat on

["Turner, Sean P." <turners@xxxxxxxx>]

Stefan,
 
I guess I think your conclusion "reject the current protocol proposal" is a
bit harsh. I've found that it's always better to have something to throw
darts at, spill beer on, and talk about rather than starting from scratch. I
don't see the harm in starting with something that's documented.
 
spt


________________________________

	From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Stefan Santesson
	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