RE: Assessment of TAMP with vendor hat on

[Stefan Santesson <stefans@xxxxxxxxxxxxx>]

Russ:

> In terms of compromise, I can see the value in separating the trust
> anchor structure from the query/response protocol.  This allows
> proprietary protocol environments to make use of it, but it does not
> diminish the need for the query/response protocol.

I totally agree that the Trust anchor information structures should be defined separately so they can be used in both the directory/retrieval environment and the query/response environment.

I don't rule out the need for a query/response protocol in some environments. What I don't want to see happen is IETF creating a direct or indirect requirement for query/response solutions in all environments. One size does not fit all here.

Just as a side note. I would not classify the directory (or central repository) environment as proprietary. TA updates in this environment can AFAIK be fully based on open standards if amended with the TA information structures. Possibly with the exception of locally defined but easily configured directory schemas.


Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: Russ Housley [mailto:housley@xxxxxxxxxxxx]
> Sent: den 18 december 2007 23:33
> To: Stefan Santesson
> Cc: ietf-pkix@xxxxxxx
> Subject: RE: Assessment of TAMP with vendor hat on
>
> Stefan:
>
> First, the problem statement was posted many months before a
> protocol.  That problem statement lead to a long discussion on the
> mail list that was set up for the TAM BOF.  That lead to people
> asking whether a protocol existed to address the problem.  So, the
> protocol was posted as a strawman.  Unencumbered alternatives that
> address some or all of the problem space are welcome.
>
> Second, the problem statement is the primary rationale. Individual
> design decisions can be discussed as this work moves forward.
>
> Third, there are hardware module vendors that have express interest
> in TAMP.  Obviously, interest was not expressed by a large operating
> system vendor.  An Microsoft Update-based or Active Directory-based
> solution is not appropriate in many environments.  However, there is
> a need, and interoperability is vital.
>
> In terms of compromise, I can see the value in separating the trust
> anchor structure from the query/response protocol.  This allows
> proprietary protocol environments to make use of it, but it does not
> diminish the need for the query/response protocol.
>
> Finally, I agree with your call for input from the whole
> community.  I do not want to put a lot of effort into this structure
> and protocol unless it will be widely implemented.  Some folks have
> spoken up.  I'd like to hear from more.  Don't be bullied.  Speak your
> mind.
>
> Russ
>
> ________________________________
>
> From: Stefan Santesson <stefans@xxxxxxxxxxxxx>
> 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