|
Stefan, You have not explained how Microsoft
securely, automatically, provides and refreshes the trust anchors. How
are Microsoft updates secured on the client? Let us say that they are
secured using trust anchors. In that case, how are those trust anchors
provided to clients securely initially, updated securely, and how do you update
them securely in-band in case of compromise. Separately, I thought TAMP (not the
protocol), but the problem statement was:
From:
owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Stefan Santesson 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 |