Subject: Asessment of TAMP with vendor hat on

From: Stefan Santesson <[email-masked]>
Date: Thu, 13 Dec 2007 20:01:40 +0000

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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 13 Dec 2007 15:41:19 -0800

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:

1.	How to provide trust anchors securely to the relying parties.
2.	How to update trust anchors securely, even if the current trust
anchor is compromised.

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Thursday, December 13, 2007 3:02 PM
To: [email-masked]
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.

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.

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

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 14 Dec 2007 00:22:00 +0000

In the public space it follows the same security mechanisms as software updates and code signing chaining to a Microsoft root. A first set of root keys are provided with the OS.

In the enterprise environment it uses the security infrastructure deployed by the organization. This currently offer adequate security for the integrity protection of TAs.

Stefan Santesson
Senior Program Manager

From: Santosh Chokhani [mailto:[email-masked]]
Sent: den 13 december 2007 15:41
To: Stefan Santesson; [email-masked]
Subject: RE: Asessment of TAMP with vendor hat on

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:

 1.  How to provide trust anchors securely to the relying parties.
 2.  How to update trust anchors securely, even if the current trust anchor is compromised.

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Santesson
Sent: Thursday, December 13, 2007 3:02 PM
To: [email-masked]
Subject: Asessment of TAMP with vendor hat on

Background.

Need

Scope

Conclusion

Stefan Santesson
Senior Program Manager

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sun, 16 Dec 2007 05:30:43 -0800

Stefan,

TAMP is supposed to solve the problem of how to provide the first set of
key and how to refresh those keys in-band in general as well as when the
original key is compromised.

Does Microsoft protocol provide for securely refreshing the keys
in-band?  If yes, the data structures and associated protocols are a
good candidate as solution to the trust anchor problem.

Also, does the Microsoft protocol provide for securely refreshing the
keys in-band even if the original trust anchor is compromised?  If yes,
that aspect can become part of the solution.

From: Stefan Santesson [mailto:[email-masked]] 
Sent: Thursday, December 13, 2007 7:22 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: Asessment of TAMP with vendor hat on

In the public space it follows the same security mechanisms as software
updates and code signing chaining to a Microsoft root. A first set of
root keys are provided with the OS.

In the enterprise environment it uses the security infrastructure
deployed by the organization. This currently offer adequate security for
the integrity protection of TAs.

Stefan Santesson

Senior Program Manager

Stefan,

Background.

Need

Scope

Conclusion

 

Stefan Santesson

Senior Program Manager

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 17 Dec 2007 13:03:08 +0000

Santosh,

I can't see that the TAM proposal solves the problem of providing the first set of keys. Any security protocol using cryptography need some keys to be in place before the protocol can work.
So essentially the TAM protocol is a key management protocol for obtaining public keys that can be configured as trust anchors.

An interesting distinction is whether it is the host/device that obtains the TA or if it is provided (pushed) on to the host/device. If you want to actively push something to the host, then that may require some query/response protocol that is initiated from a central source. However. If the TA is obtained by the host, then no new protocol is needed over existing infrastructure and protocols.

There are several ways the host can come to a conclusion that it needs to do a TA update.

1)      An unresolved cert chain is being validated, chaining to an unknown TA

2)      A scheduled process on the host periodically downloads TA policy and TAs from a central directory.

The only protocols used to obtain data are standard protocols for directory usage or standard web protocols in combination with security and authentication protocols such as IPsec and Kerberos. Standard signature schemes can be used to sign data for authenticity and integrity protection.

The only amendment of standards this environment  would benefit from are signed data structures for TA information.

Microsoft's way to push information to clients and hosts is through group policy updates. This is however not a protocol. This is a function that can be configured in the host OS which pulls policy information from a central directory. The only thing you have to do to manage host updates is to update policy data in the central directory. Group policy is activated when a host is domain joined.

You can add all sorts of protection to this process, but this can be done locally by available protocols and doesn't require any TA specific protocol to be secure.

My problem is that I can't see how TAMP fits into this information and key management model and why TAMP is needed instead of, or in addition to this.

Stefan Santesson
Senior Program Manager

From: Santosh Chokhani [mailto:[email-masked]]
Sent: den 16 december 2007 14:31
To: Stefan Santesson; [email-masked]
Subject: RE: Asessment of TAMP with vendor hat on

Stefan,

TAMP is supposed to solve the problem of how to provide the first set of key and how to refresh those keys in-band in general as well as when the original key is compromised.

Does Microsoft protocol provide for securely refreshing the keys in-band?  If yes, the data structures and associated protocols are a good candidate as solution to the trust anchor problem.

Also, does the Microsoft protocol provide for securely refreshing the keys in-band even if the original trust anchor is compromised?  If yes, that aspect can become part of the solution.

Stefan Santesson
Senior Program Manager

Stefan,

Background.

Need

Scope

Conclusion

Stefan Santesson
Senior Program Manager

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 17 Dec 2007 15:30:11 +0100

Stefan,

I agree with you on many points. See my comments embedded.

> direction, but not much of the rationales behind this solution.
I got the same feeling.

> assessment of how this fits into our current IT infrastructures. E.g. 
> if there are any Vendors interested in implementing this and for what 
> 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.*
>
> 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 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*
> 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*
>
As you implicitly say, we have a solution, ... but it is unclear what 
the problem it solves is.

:-)

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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 17 Dec 2007 06:48:52 -0800

Stefan,

We agree that initial trust anchor must be provided using secure out of
band means such as physically secure means.

It is probably ok that the current certificate format with applicable
current or new extension can serve as the trust anchor information.

But, as my post asks (for the nth time), do we need to define data
structures and protocols to replace the trust anchor routinely and/or in
the case of trust anchor compromise.

If the community thinks that all this should be done out-of-band, then
we do not need TAMP.

If the community thinks that there is some value, cost saving and
efficiency and operational security improvement in doing this in-band,
then a protocol should be vetted so that there is interoperability and
the security of the protocol is vetted through the collective wisdom of
IETF/PKIX.

Sent: Monday, December 17, 2007 8:03 AM

Santosh,

I can't see that the TAM proposal solves the problem of providing the
first set of keys. Any security protocol using cryptography need some
keys to be in place before the protocol can work.

So essentially the TAM protocol is a key management protocol for
obtaining public keys that can be configured as trust anchors.

An interesting distinction is whether it is the host/device that obtains
the TA or if it is provided (pushed) on to the host/device. If you want
to actively push something to the host, then that may require some
query/response protocol that is initiated from a central source.
However. If the TA is obtained by the host, then no new protocol is
needed over existing infrastructure and protocols.

There are several ways the host can come to a conclusion that it needs
to do a TA update.

1)      An unresolved cert chain is being validated, chaining to an
unknown TA

2)      A scheduled process on the host periodically downloads TA policy
and TAs from a central directory. 

The only protocols used to obtain data are standard protocols for
directory usage or standard web protocols in combination with security
and authentication protocols such as IPsec and Kerberos. Standard
signature schemes can be used to sign data for authenticity and
integrity protection.

The only amendment of standards this environment  would benefit from are
signed data structures for TA information.

Microsoft's way to push information to clients and hosts is through
group policy updates. This is however not a protocol. This is a function
that can be configured in the host OS which pulls policy information
from a central directory. The only thing you have to do to manage host
updates is to update policy data in the central directory. Group policy
is activated when a host is domain joined. 

You can add all sorts of protection to this process, but this can be
done locally by available protocols and doesn't require any TA specific
protocol to be secure.

My problem is that I can't see how TAMP fits into this information and
key management model and why TAMP is needed instead of, or in addition
to this.

Stefan Santesson

Senior Program Manager

Stefan,

 

Stefan Santesson

Senior Program Manager

Stefan,

Background.

Need

Scope

Conclusion

 

Stefan Santesson

Senior Program Manager

---

From: Massimiliano Pala <[email-masked]>
Date: Mon, 17 Dec 2007 12:50:57 -0500

Hi Stefan,

I do perfectly agree that there are many different ways to manage
TAs. However, for interoperability purposes, I think it is necessary
for PKIX to provide the Internet with a secure and standard method
(free of patents...) that may be implemented by applications and
that can be used across different systems/domains.

After all, isn't that why we need standards (besides the benefits we
get from having the work openly analyzed by experts in the area) ?

Later,
Max

Stefan Santesson wrote:
> Santosh,
> 
>  
> 
> I can’t see that the TAM proposal solves the problem of providing the 
> Microsoft’s way to push information to clients and hosts is through 
> done locally by available protocols and doesn’t require any TA specific 
> protocol to be secure.
> 
>  
> 
> My problem is that I can’t see how TAMP fits into this information and 
> *From:* Santosh Chokhani [mailto:[email-masked]]
> *Sent:* den 16 december 2007 14:31
> *To:* Stefan Santesson; [email-masked]
> *Subject:* RE: Asessment of TAMP with vendor hat on
> 
>  
> 
> Stefan,
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* Stefan Santesson [mailto:[email-masked]]
> *Sent:* Thursday, December 13, 2007 7:22 PM
> *To:* Santosh Chokhani; [email-masked]
> *Subject:* RE: Asessment of TAMP with vendor hat on
> 
>  
> 
> *From:* Santosh Chokhani [mailto:[email-masked]]
> *Sent:* den 13 december 2007 15:41
> *To:* Stefan Santesson; [email-masked]
> *Subject:* RE: Asessment of TAMP with vendor hat on
> 
>  
> 
> Stefan,
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* [email-masked] 
> [mailto:[email-masked]] *On Behalf Of *Stefan Santesson
> *Sent:* Thursday, December 13, 2007 3:02 PM
> *To:* [email-masked]
> *Subject:* Asessment of TAMP with vendor hat on
> 
>  
> 
> I’m here taking my pkix-chair hat of and my vendor hat on to provide an 

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]            [email-masked]
                                                  [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 397-3883
PKI/Trust - Office 063                        Work Phone: +1 (603) 646-9179
--o------------------------------------------------------------------------

---

From: Stephen Kent <[email-masked]>
Date: Mon, 17 Dec 2007 13:55:53 -0500

Stefan,

A few of observations about you TAM comments, many of which may have 
been stated by others, since I am late in responding:

	- you are right that the presentation we saw in Vancouver 
focused on a solution, not a problem statement. PKIX will need to 
start with a problem statement (or a requirements I-D) that the WG 
agrees upon.  There was considerable discussion of the problem 
statement on the TAM mailing list. I think we can start from the most 
recent iteration there, but this will need to be developed in the 
context of PKIX, i.e., we are not rubber stamping what was done 
before.

	- we need an interoperable solution, in typical IETF style, 
so whatever Microsoft or other vendors have done may be useful as 
input, but it probably is not a substitute for a IETF standard.

	- there were suggestions on the TAM list that offline 
management was needed. So any solution that relies on live 
connectivity is not sufficient, IF the WG agrees with this as a 
requirement.

	- the TAM list also indicated a desire to have a flexible 
management capability, in which one TA, with ultimate responsibility 
for the managed object, can delegate authority to other entities to 
manage TAs with constrained scope. My quick read of what you 
described as the MS management capability did not seem to accommodate 
this sort of delegation. Again, if PKIX decides this is a real 
requirement, that motivates developed of a more sophisticated 
management framework.

	- in certain contexts the receipt capability seems useful, as 
does the ability to query a managed device to determine which TAs are 
installed, etc. Again, we'll have to see whether these are features 
that the WG agrees are needed.  If so, then they motivate a 
request/response protocol model.

	- the secure TA replacement function defined in TAMP seems to 
be attractive, and hopefully not patent encumbered, and would be a 
nice feature for PKIs to have, although I agree that it could be 
accommodated as a cert extension without the rest of TAMP.

Steve

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 18 Dec 2007 09:33:31 +0000

Steve,

I think we are mainly in agreement on all points.

Let me recap my major points:

1) I support the TAM work in PKIX as a problem area to work on
2) I object to accepting the current protocol proposal as the starting point of this effort.

We seem to agree on both.

In finding a good basis for doing this work, I think it is important to notice and acknowledge what problems we are facing today, as developers and as users and match that to how we approach this problem today in absence of any standard so migration into a common standard becomes feasible and likely to happen. To just look at what could be nice in theory often leads down a slippery slope and tends to produce an overly complex protocol solution after 5-10 years that is detached from real problems and therefore fails wide deployment.

I would stress that we must not forget that TA management is a support function to other security protocols, and that it is in the basic security assumptions of these security protocols where the actual security requirements for TA management can be understood.
The challenge of this group is to consider both the management model of a central function with complete authority over local TA stores on distributed Hosts and the model where the TA distributing environment merely support the hosts with a reliable source of TAs. Both models can be managed, one directly and the other indirectly.

I'm not convinced yet the directly managed model is needed, but that can be saved for future debate.

Stefan Santesson
Senior Program Manager

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]]
> Sent: den 17 december 2007 19:56
> To: Stefan Santesson
> Cc: [email-masked]

---

From: "Turner, Sean P." <[email-masked]>
Date: Tue, 18 Dec 2007 15:44:52 -0500

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: [email-masked]
[mailto:[email-masked]] On Behalf Of Stefan Santesson
	Sent: Thursday, December 13, 2007 3:02 PM
	To: [email-masked]
	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.

	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.

	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

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 19 Dec 2007 11:10:07 -0500

> From: Stefan Santesson
>
> The challenge of this group is to consider both the management model
of
> a central function with complete authority over local TA stores on
> distributed Hosts and the model where the TA distributing environment
> merely support the hosts with a reliable source of TAs. 

Yes, we are in agreement that this is an important distinction.

> Both models can be managed, one directly and the other indirectly.

As you say, the issue is who has complete authority.  In the case of
Hosts owned and managed by an enterprise but located on employees'
desks, should it be up to the employee to voluntarily make use of
enterprise-managed reliable TA stores, or should the enterprise have a
model that permits it to query and set TAs on Hosts regardless of the
employee's wishes?

I know very few of the technical details about how "my" work machine was
installed and added to an AD domain.  But at some point in the process
it received a TA (an administrator password) that I do not know and can
not change; thus I do not have the technical ability to override my
employer's control of my desktop.

I'm convinced that you believe direct management is not needed because
you do not see "TA" in its full generality.  If you accept that control
of a host is ultimately traced back to a TA of some form and you accept
the need of an enterprise to control its hosts in a way that users
cannot override, then you must believe in direct management.

Dave

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 20 Dec 2007 11:02:49 +0000

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

> From: Turner, Sean P. [mailto:[email-masked]]
> Sent: den 18 december 2007 21:45
> if
> and
> network
> this
> necessary
> repository
> infrastructure
> be
> certificates and

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 20 Dec 2007 18:05:36 +0100

I fully agree with Stefan's conclusions.

Now to the possible query/response protocol.

I don't see why anybody (be it consumer or enterprise) would be interested in opening a hole in the firewall allowing inbound TA-TTP
updates to for example the browser TA store.

This does however not dismiss such a protocol, it just narrows the scope.  IMHO, this may even increase the chances that it
succeeds.

If we rather think of the scope as a set of networked devices (servers, routers etc) centrally managed by an organization, you may
indeed want to have an immediate update rather than waiting for the local "pull" scheme to kick in.

If I were to design such a protocol I would base it on Web Services to not end-up with yet another esoteric protocol that you must
ask IT to support.

But as earlier stated, I'm not going to follow the protocol port of TAM, so please feel free using ASN.1 and registering TCP ports.
It was just a friendly advice from a person who see deployment and adoption as a bigger hurdle than passing a final call in IETF.

Another possibility which I unfortunately has zero knowledge of, could be using SNMP.

Anders Rundgren
With the independent observer hat on

---

From: Stephen Kent <[email-masked]>
Date: Thu, 20 Dec 2007 13:57:16 -0500

At 6:05 PM +0100 12/20/07, Anders Rundgren wrote:
>I don't see why anybody (be it consumer or enterprise) would be 
>interested in opening a hole in the firewall allowing inbound TA-TTP

I do  not recall any comments to suggest that the TA manager needs to 
be outside the firewall.

>This does however not dismiss such a protocol, it just narrows the 
>scope.  IMHO, this may even increase the chances that it
>succeeds.

Since your earlier message said you didn't care about TAM ("Since I 
have no interest in TAM, feel free to ignore my long-winding comment 
:-)"), don't feel compelled to continue contributing to this thread.

Steve