|
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 |