[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Asessment of TAMP with vendor hat on
Stefan,
I agree with you on many points. See my comments embedded.
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.
I got the same feeling.
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.
Not everybody is using MS update. So, in addition, to what you say,
every time you download a new version of IE, you also get new trust anchors.
Here again there is no client server protocol, but the (hopefully
secure) downloading of information.
Note: One major problem with the MS model is nearly a single validation
policy, whatever job is being done by a client or an application.
*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.
The fact is that a validation policy is much more complex that simply
defining one trust anchor.
Hence why simply managing trust anchors is insufficient, ... besides the
fact that we already
have a protocol for doing this (defined in RFC 2510).
*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.
I agree in principle.
*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.
As you implicitly say, we have a solution, ... but it is unclear what
the problem it solves is.
:-)
*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.
You are right to say that the requirements should first be clarified,
otherwise the work would be started with fairly different understandings.
:-(
Denis
*Stefan Santesson*
Senior Program Manager
*Windows Security, Standards*