[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Asessment of TAMP with vendor hat on
Sean,
I've seen many cases where starting from a proposal that has already done some fundamental choices of direction is harmful to the process. Especially if those fundamental choices of directions is not agreed upon.
I do not "Reject" the draft. I just don't want it to be used as a starting point for the design work until we have sorted out those fundamental choices of directions.
I've tried my best to describe why I think this protocol proposal has left out a viable alternative. An alternative architecture that is deployed and working.
I don't want to hold off the work, but I think we need to structure it first.
Stefan Santesson
Senior Program Manager
Windows Security, Standards
> -----Original Message-----
> From: Turner, Sean P. [mailto:turners@xxxxxxxx]
> Sent: den 18 december 2007 21:45
> To: Stefan Santesson; ietf-pkix@xxxxxxx
> Subject: RE: Asessment of TAMP with vendor hat on
>
> 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
>
>
>