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.
[CRW]
The problem statement is still very much available and could be used as the
basis for discussion here.
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.
[CRW]
Part of the aim is vendor interop. An aim, as described in the problem
statement, is to vet new TAs in terms of a key that was installed out of band
in a trusted manner, while supporting in-band replacement of the initial
key.
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.
[CRW]
Disconnected devices require TA management as well.
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.
[CRW]
An aim is to make the trusted source be common across
applications. Placing the trusted source in the control of PKI
operators instead of domain administrators would be a good thing to enable as
well.
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.
[CRW]
There are aspects of existing solutions that are problematicthat are addressed
by TAMP, i.e., in-band updates and TA usage. The
request/response nature of TAMP is certainly not central to
its functionality. A signed TrustAnchorUpdate message verified
using a previously installed trust anchor can be used without the production of
a receipt.
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.
[CRW]
There is plenty of common ground. You've noted the potential utility
of signed TA information and non-self-signed structures for TAs.
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.
[CRW]
There is a problem statement from the TAM BOF.
Stefan Santesson
Senior Program Manager
Windows Security, Standards