Subject: Comments on the TA requirements document

From: Stefan Santesson <[email-masked]>
Date: Thu, 23 Oct 2008 15:24:27 +0100

Commenting on draft-ietf-pkix-ta-mgmt-reqs-01, both in general and as response to Denis Detailed comments.
http://tools.ietf.org/html/draft-ietf-pkix-ta-mgmt-reqs-01

I thought I better post this comment as a separate e-mail to keep it clear from other threads.

On the general issue I am, as I have stated before,  not overly enthusiastic about the TA management protocol. The main reason is that I can't see that I need one.

TA management is just another aspect of policy management and modern complex  IT environments already have systems and tools to deal with policy management. It may not be pretty, and it may not be generic, but it's there and we can't pretend it's not.

TA management is also subordinate to the larger security management aspects of an IT environment. If we can't manage user access, policy distribution and policy enforcement in a large IT network, all bets are off. The most genius TA management protocol in the world won't save us. And since we already depend on the current security management for success, we night as well allow it to manage the policies concerning trust in TAs.

I believe more in a TA management solution where clients "retrieve" the TA they have been instructed to use by the overall policy management infrastructure (whatever it is), rather than a model where a TA Manager push this information onto the client and actively manages the TA stores in the client and server hosts.

Denis comments:

I want to address Denis comments in principle rather than detailed in depth at this point.

I agree in principle with Denis observation that the current approach is structured as a push model over a pull model. This is a disconnect from how most systems and current protocols work today. I strongly encourage the pull model to be the main and default principle for TA management.

I disagree that a TA Management structure need to be structured around the root cross certification scheme of CMP (old with new and new with old signing). It should be possible, but this is seldom implemented in reality.

I disagree with Denis on the issue of including validation policies into the requirements of this protocol.

The reasons are again that trust policy management is a lot larger than what we possibly can define in the PKIX working group. Whatever we would come up with other than standardized protocol elements to be used by other protocols, we will end up guessing and most likely miss the target, or just serve a few corner cases with a complex protocol.

Comments on the TA req document:

I think there is one fundamental flaw in the general assumptions of the document:

>From 1.1

   Trust relationships between PKIs are negotiated by policy
   authorities.  Negotiations frequently require significant time to
   ensure all participating parties' requirements are satisfied.  These
   requirements are expressed, to some extent, in public key
   certificates via policy constraints, name constraints and etc.  In
   order for these requirements to be enforced, trust anchor stores must
   be managed in accord with policy authority intentions and avoid
   circumventing constraints defined in a cross-certificate by
   recognizing the subject of the cross certificate as a trust anchor.

I find this assumption wrong as management of trust anchors is a matter of local policy only.

The whole path processing logic is designed so that the statements made by each CA will be enforced appropriately in accordance with the TA that the local relying party has chosen as a result of local policy only.

This defeats a substantial part of the rationale for having a push model rather than a pull model.

Conclusion

The working group has already decided to adopt this work, and it is not my intention to try to block its progress.

I'm just expressing the rationale why I doubt its usefulness in its current form and why I have problems providing detailed comments on the requirements document.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

---

From: "Carl Wallace" <[email-masked]>
Date: Thu, 23 Oct 2008 11:02:31 -0400

inline...

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Stefan Santesson
	Sent: Thursday, October 23, 2008 10:24 AM
	To: [email-masked]
	Subject: Comments on the TA requirements document

	Commenting on draft-ietf-pkix-ta-mgmt-reqs-01, both in general
and as response to Denis Detailed comments.

	I thought I better post this comment as a separate e-mail to
keep it clear from other threads.

	On the general issue I am, as I have stated before,  not overly
enthusiastic about the TA management protocol. The main reason is that I
can't see that I need one.

	TA management is just another aspect of policy management and
modern complex  IT environments already have systems and tools to deal
with policy management. It may not be pretty, and it may not be generic,
but it's there and we can't pretend it's not. 

	[CRW] There is no pretending that mechanisms do not exist.  This
draft simply defines a set of requirements for these mechanisms with an
aim of establishing an interoperable solution.  If existing mechanisms
meet the requirements or can be modified to do so, great.  Right now,
we're just trying to define the set of requirements.

	TA management is also subordinate to the larger security
management aspects of an IT environment. If we can't manage user access,
policy distribution and policy enforcement in a large IT network, all
bets are off. The most genius TA management protocol in the world won't
save us. And since we already depend on the current security management
for success, we night as well allow it to manage the policies concerning
trust in TAs.

	I believe more in a TA management solution where clients
"retrieve" the TA they have been instructed to use by the overall policy
management infrastructure (whatever it is), rather than a model where a
TA Manager push this information onto the client and actively manages
the TA stores in the client and server hosts. 

	[CRW] I don't see the confusion w.r.t push/pull.  There is no
intent to require a push model exclusively or even favor a push model.
What text is creating this impression?

	Denis comments:

	I want to address Denis comments in principle rather than
detailed in depth at this point.

	I agree in principle with Denis observation that the current
approach is structured as a push model over a pull model. This is a
disconnect from how most systems and current protocols work today. I
strongly encourage the pull model to be the main and default principle
for TA management. 

	[CRW] See above re: push/pull. 

	I disagree that a TA Management structure need to be structured
around the root cross certification scheme of CMP (old with new and new
with old signing). It should be possible, but this is seldom implemented
in reality.

	I disagree with Denis on the issue of including validation
policies into the requirements of this protocol.

	The reasons are again that trust policy management is a lot
larger than what we possibly can define in the PKIX working group.
Whatever we would come up with other than standardized protocol elements
to be used by other protocols, we will end up guessing and most likely
miss the target, or just serve a few corner cases with a complex
protocol. 

	I think there is one fundamental flaw in the general assumptions
of the document: 

	From 1.1

	   Trust relationships between PKIs are negotiated by policy
	   authorities.  Negotiations frequently require significant
time to
	   ensure all participating parties' requirements are satisfied.
These
	   requirements are expressed, to some extent, in public key
	   certificates via policy constraints, name constraints and
etc.  In
	   order for these requirements to be enforced, trust anchor
stores must
	   be managed in accord with policy authority intentions and
avoid
	   circumventing constraints defined in a cross-certificate by
	   recognizing the subject of the cross certificate as a trust
anchor.

	I find this assumption wrong as management of trust anchors is a
matter of local policy only.

	The whole path processing logic is designed so that the
statements made by each CA will be enforced appropriately in accordance
with the TA that the local relying party has chosen as a result of local
policy only. 

	[CRW] I can see where this text is confusing.  The policy
authority referenced here is the local policy authority.  The point of
the requirement is that when a local policy authority issues a cross
certificate to an external enterprise root, it should not be possible to
avoid the constraints included in the cross-cert by installing the
self-signed certificate issued to the subject of the cross-certificate.
The trust anchor stores subject to the local policy authority must be
managed in accord with the policy authority's intentions or all bets are
off. 

	This defeats a substantial part of the rationale for having a
push model rather than a pull model. 

	[CRW] See above re: push/pull. 

	Conclusion

	The working group has already decided to adopt this work, and it
is not my intention to try to block its progress.

	I'm just expressing the rationale why I doubt its usefulness in
its current form and why I have problems providing detailed comments on
the requirements document. 

	[CRW] Assuming the language is clarified such that push is not
the focus, what remaining concerns do you have?  

	 

	Stefan Santesson

	Senior Program Manager

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 23 Oct 2008 16:23:48 +0100

Carl,

[CRW] I don't see the confusion w.r.t push/pull. There is no intent to require a push model exclusively or even favor a push model.  What text is creating this impression?

This is clearly requirements for an active push protocol. For example:

3.3.1.  Functional Requirements

   A protocol for TA management must allow a TA management transaction
   to be directed to:

      All TA stores for which the manager is responsible
      An enumerated list of one or more groups of trust anchor stores
      An individual trust anchor store

This is only relevant requirement for a push model. And it goes on and on throughout the requirements.
And that is fine.  I'd rather have it saying that it is requirements for a specific type of TA management protocol out of many possible management models.

[CRW] There is no pretending that mechanisms do not exist.  This draft simply defines a set of requirements for these mechanisms with an aim of establishing an interoperable solution.  If existing mechanisms meet the requirements or can be modified to do so, great.  Right now, we're just trying to define the set of requirements.

My point is that these requirements does not fit the policy management model that is used in the systems I know of. The main reason is that the current document describes requirements for active direct management of TA stores instead of a pull model as a result of a separate policy enforcement solution.

[CRW] Assuming the language is clarified such that push is not the focus, what remaining concerns do you have?

I don't think that is a language issue. I would rather accept that this is a requirements document for a push oriented protocol, but to clarify that other models may be used where this protocol may be redundant.
It would also be great to position this document among possible TA management models.

If I could wish for something more, then that would be to separate out the requirements for standardizing the syntax of a TA list form the requirements on a TA management protocol.
The reason is that we agreed to run these specifications separately.

Stefan Santesson
Senior Program Manager

From: Carl Wallace [mailto:[email-masked]]
Sent: den 23 oktober 2008 17:03
To: Stefan Santesson; [email-masked]
Subject: RE: Comments on the TA requirements document

inline...

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Santesson

[CRW] There is no pretending that mechanisms do not exist.  This draft simply defines a set of requirements for these mechanisms with an aim of establishing an interoperable solution.  If existing mechanisms meet the requirements or can be modified to do so, great.  Right now, we're just trying to define the set of requirements.

[CRW] I don't see the confusion w.r.t push/pull. There is no intent to require a push model exclusively or even favor a push model.  What text is creating this impression?

Denis comments:

[CRW] I can see where this text is confusing.  The policy authority referenced here is the local policy authority.  The point of the requirement is that when a local policy authority issues a cross certificate to an external enterprise root, it should not be possible to avoid the constraints included in the cross-cert by installing the self-signed certificate issued to the subject of the cross-certificate.  The trust anchor stores subject to the local policy authority must be managed in accord with the policy authority's intentions or all bets are off.

Conclusion

[CRW] Assuming the language is clarified such that push is not the focus, what remaining concerns do you have?

Stefan Santesson
Senior Program Manager

---

From: "Carl Wallace" <[email-masked]>
Date: Thu, 23 Oct 2008 11:34:39 -0400

What about this requirement could not be met by a TA mgmt message
addressed to all TA stores for which a manager is responsible and pulled
from a directory?  This does not require push.

	From: Stefan Santesson [mailto:[email-masked]] 
	Sent: Thursday, October 23, 2008 11:24 AM
	To: Carl Wallace; [email-masked]
	Subject: RE: Comments on the TA requirements document

	Carl,

	This is clearly requirements for an active push protocol. For
example:

	   A protocol for TA management must allow a TA management
transaction

	   to be directed to:

	      An enumerated list of one or more groups of trust anchor
stores

	 

	This is only relevant requirement for a push model. And it goes
on and on throughout the requirements.

	And that is fine.  I'd rather have it saying that it is
requirements for a specific type of TA management protocol out of many
possible management models.

	My point is that these requirements does not fit the policy
management model that is used in the systems I know of. The main reason
is that the current document describes requirements for active direct
management of TA stores instead of a pull model as a result of a
separate policy enforcement solution.

	I don't think that is a language issue. I would rather accept
that this is a requirements document for a push oriented protocol, but
to clarify that other models may be used where this protocol may be
redundant.

	It would also be great to position this document among possible
TA management models.

	If I could wish for something more, then that would be to
separate out the requirements for standardizing the syntax of a TA list
form the requirements on a TA management protocol.

	The reason is that we agreed to run these specifications
separately.

	Stefan Santesson

	Senior Program Manager

	inline...

		Commenting on draft-ietf-pkix-ta-mgmt-reqs-01, both in
general and as response to Denis Detailed comments.

		I thought I better post this comment as a separate
e-mail to keep it clear from other threads.

		On the general issue I am, as I have stated before,  not
overly enthusiastic about the TA management protocol. The main reason is
that I can't see that I need one.

		TA management is just another aspect of policy
management and modern complex  IT environments already have systems and
tools to deal with policy management. It may not be pretty, and it may
not be generic, but it's there and we can't pretend it's not. 

		[CRW] There is no pretending that mechanisms do not
exist.  This draft simply defines a set of requirements for these
mechanisms with an aim of establishing an interoperable solution.  If
existing mechanisms meet the requirements or can be modified to do so,
great.  Right now, we're just trying to define the set of requirements.

		[CRW] I don't see the confusion w.r.t push/pull. There
is no intent to require a push model exclusively or even favor a push
model.  What text is creating this impression?

		Denis comments:

		I want to address Denis comments in principle rather
than detailed in depth at this point.

		I agree in principle with Denis observation that the
current approach is structured as a push model over a pull model. This
is a disconnect from how most systems and current protocols work today.
I strongly encourage the pull model to be the main and default principle
for TA management. 

		I disagree that a TA Management structure need to be
structured around the root cross certification scheme of CMP (old with
new and new with old signing). It should be possible, but this is seldom
implemented in reality.

		I disagree with Denis on the issue of including
validation policies into the requirements of this protocol.

		The reasons are again that trust policy management is a
lot larger than what we possibly can define in the PKIX working group.
Whatever we would come up with other than standardized protocol elements
to be used by other protocols, we will end up guessing and most likely
miss the target, or just serve a few corner cases with a complex
protocol. 

		I think there is one fundamental flaw in the general
assumptions of the document: 

		From 1.1

		   Trust relationships between PKIs are negotiated by
policy
		   authorities.  Negotiations frequently require
significant time to
		   ensure all participating parties' requirements are
satisfied.  These
		   requirements are expressed, to some extent, in public
key
		   certificates via policy constraints, name constraints
and etc.  In
		   order for these requirements to be enforced, trust
anchor stores must
		   be managed in accord with policy authority intentions
and avoid
		   circumventing constraints defined in a
cross-certificate by
		   recognizing the subject of the cross certificate as a
trust anchor.

		I find this assumption wrong as management of trust
anchors is a matter of local policy only.

		[CRW] I can see where this text is confusing.  The
policy authority referenced here is the local policy authority.  The
point of the requirement is that when a local policy authority issues a
cross certificate to an external enterprise root, it should not be
possible to avoid the constraints included in the cross-cert by
installing the self-signed certificate issued to the subject of the
cross-certificate.  The trust anchor stores subject to the local policy
authority must be managed in accord with the policy authority's
intentions or all bets are off. 

		This defeats a substantial part of the rationale for
having a push model rather than a pull model. 

		 

		Conclusion

		The working group has already decided to adopt this
work, and it is not my intention to try to block its progress.

		I'm just expressing the rationale why I doubt its
usefulness in its current form and why I have problems providing
detailed comments on the requirements document. 

		[CRW] Assuming the language is clarified such that push
is not the focus, what remaining concerns do you have?  

		 

		Stefan Santesson

		Senior Program Manager

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 23 Oct 2008 17:01:36 -0400

Stefan,

Is there ever a distinction to be made at the application layer between
push and pull?  Like picking TCP vs UDP, there are performance reasons
for choosing one transport vs. another, but at the Functional
Requirements level, the goal is for recipients to remain up-to-date
regardless of who initiates a connection.   Is messaging push or pull?
(Sending email via SMTP is push, receiving email via IMAP is pull, who
knows how to characterize IM transport over XMPP or text transport over
SMS; in all cases the user's desired end result is simply to see
messages shortly after they are written).    Push vs. pull makes even
less sense in simplex transport scenarios - is receiving a pager message
or a stock quote over FM radio subcarrier a push or pull transaction? 

As Carl says, I don't see how anything in the TA requirements favors
either management station initiated (snmp?) or client initiated (imap?
http?) transport.

Dave

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Carl Wallace
Sent: Thursday, October 23, 2008 11:35 AM
To: Stefan Santesson; [email-masked]
Subject: RE: Comments on the TA requirements document

  _____  

Carl,

[CRW] I don't see the confusion w.r.t push/pull. There is no intent to
require a push model exclusively or even favor a push model.  What text
is creating this impression?

   to be directed to:

 

This is only relevant requirement for a push model. And it goes on and
on throughout the requirements.

And that is fine.  I'd rather have it saying that it is requirements for
a specific type of TA management protocol out of many possible
management models.

[CRW] There is no pretending that mechanisms do not exist.  This draft
simply defines a set of requirements for these mechanisms with an aim of
establishing an interoperable solution.  If existing mechanisms meet the
requirements or can be modified to do so, great.  Right now, we're just
trying to define the set of requirements.

My point is that these requirements does not fit the policy management
model that is used in the systems I know of. The main reason is that the
current document describes requirements for active direct management of
TA stores instead of a pull model as a result of a separate policy
enforcement solution.

[CRW] Assuming the language is clarified such that push is not the
focus, what remaining concerns do you have?  

I don't think that is a language issue. I would rather accept that this
is a requirements document for a push oriented protocol, but to clarify
that other models may be used where this protocol may be redundant.

It would also be great to position this document among possible TA
management models.

If I could wish for something more, then that would be to separate out
the requirements for standardizing the syntax of a TA list form the
requirements on a TA management protocol.

 

Stefan Santesson

Senior Program Manager

inline...

  _____  

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Thursday, October 23, 2008 10:24 AM
To: [email-masked]
Subject: Comments on the TA requirements document

Commenting on draft-ietf-pkix-ta-mgmt-reqs-01, both in general and as
response to Denis Detailed comments.

I thought I better post this comment as a separate e-mail to keep it
clear from other threads.

TA management is just another aspect of policy management and modern
complex  IT environments already have systems and tools to deal with
policy management. It may not be pretty, and it may not be generic, but
it's there and we can't pretend it's not. 

[CRW] There is no pretending that mechanisms do not exist.  This draft
simply defines a set of requirements for these mechanisms with an aim of
establishing an interoperable solution.  If existing mechanisms meet the
requirements or can be modified to do so, great.  Right now, we're just
trying to define the set of requirements.

TA management is also subordinate to the larger security management
aspects of an IT environment. If we can't manage user access, policy
distribution and policy enforcement in a large IT network, all bets are
off. The most genius TA management protocol in the world won't save us.
And since we already depend on the current security management for
success, we night as well allow it to manage the policies concerning
trust in TAs.

I believe more in a TA management solution where clients "retrieve" the
TA they have been instructed to use by the overall policy management
infrastructure (whatever it is), rather than a model where a TA Manager
push this information onto the client and actively manages the TA stores
in the client and server hosts. 

[CRW] I don't see the confusion w.r.t push/pull. There is no intent to
require a push model exclusively or even favor a push model.  What text
is creating this impression?

Denis comments:

I want to address Denis comments in principle rather than detailed in
depth at this point.

I agree in principle with Denis observation that the current approach is
structured as a push model over a pull model. This is a disconnect from
how most systems and current protocols work today. I strongly encourage
the pull model to be the main and default principle for TA management. 

I disagree that a TA Management structure need to be structured around
the root cross certification scheme of CMP (old with new and new with
old signing). It should be possible, but this is seldom implemented in
reality.

I disagree with Denis on the issue of including validation policies into
the requirements of this protocol.

The reasons are again that trust policy management is a lot larger than
what we possibly can define in the PKIX working group. Whatever we would
come up with other than standardized protocol elements to be used by
other protocols, we will end up guessing and most likely miss the
target, or just serve a few corner cases with a complex protocol. 

I think there is one fundamental flaw in the general assumptions of the

 

I find this assumption wrong as management of trust anchors is a matter
of local policy only.

The whole path processing logic is designed so that the statements made
by each CA will be enforced appropriately in accordance with the TA that
the local relying party has chosen as a result of local policy only. 

[CRW] I can see where this text is confusing.  The policy authority
referenced here is the local policy authority.  The point of the
requirement is that when a local policy authority issues a cross
certificate to an external enterprise root, it should not be possible to
avoid the constraints included in the cross-cert by installing the
self-signed certificate issued to the subject of the cross-certificate.
The trust anchor stores subject to the local policy authority must be
managed in accord with the policy authority's intentions or all bets are
off. 

This defeats a substantial part of the rationale for having a push model
rather than a pull model. 

 

Conclusion

The working group has already decided to adopt this work, and it is not
my intention to try to block its progress.

I'm just expressing the rationale why I doubt its usefulness in its
current form and why I have problems providing detailed comments on the
requirements document. 

[CRW] Assuming the language is clarified such that push is not the
focus, what remaining concerns do you have?  

 

Stefan Santesson

Senior Program Manager

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 25 Oct 2008 03:47:45 +0100

Dave

This is not a matter of transport protocol. This is a matter of how you manage policies and what protocols you need to support both management and execution of these policies.

The current requirement document mix together policy management and policy execution in one bucket for TA management.

The policy management part deals with ensuring that all hosts knows what keys they are allowed to trust.
The policy execution part deals with obtaining the keys and parameters associated with managed policies and to put them in use in a compliant manner.

Policy management is always initiated and managed centrally and pushed down to users/hosts, or at least enforced upon users/hosts in some way or another. There are many ways to do this, but it always involves some kind of central management. One way to do this that is very common in my world, is to use a directory as the central mechanism to publish policies combined with other functions (like system health checks) to make sure hat policies has been downloaded and implemented. In these common cases, there is no need for any new protocol.

Policy execution is something that is carried out by the user/host, based on the centrally distributed policy. One part of policy execution in this case is to obtain/download the TAs that are considered trustworthy by the distributed policy. Since the user/host is in control and thus responsible for policy execution, they can also "pull" down any key data associated with the TA policy. The only thing they would need in order to do that, is a common data format for TA keys and their parameters, signed by some kind of "master" TA policy management key. That common data format for TA key information is all I currently need.
We may convince ourselves that we can make a central manager in control of policy execution on behalf of users/hosts if we write a super smart protocol (like PKIX TAM), but that would be an illusion. To some extent we will always need to trust the user/host to carry out the policy in an appropriate manner.

This is the world I'm coming from when approaching this subject. When I read the req document for TA management I do not recognize any protocol that fit the needs of my environment.
This is why I have problems providing constructive feedback on it.

Stefan Santesson
Senior Program Manager

From: [email-masked] [mailto:[email-masked]] On Behalf Of Kemp, David P.
Sent: den 23 oktober 2008 23:02
To: [email-masked]
Subject: RE: Comments on the TA requirements document

Stefan,

Is there ever a distinction to be made at the application layer between push and pull?  Like picking TCP vs UDP, there are performance reasons for choosing one transport vs. another, but at the Functional Requirements level, the goal is for recipients to remain up-to-date regardless of who initiates a connection.   Is messaging push or pull?  (Sending email via SMTP is push, receiving email via IMAP is pull, who knows how to characterize IM transport over XMPP or text transport over SMS; in all cases the user's desired end result is simply to see messages shortly after they are written).    Push vs. pull makes even less sense in simplex transport scenarios - is receiving a pager message or a stock quote over FM radio subcarrier a push or pull transaction?

As Carl says, I don't see how anything in the TA requirements favors either management station initiated (snmp?) or client initiated (imap? http?) transport.

Dave

From: [email-masked] [mailto:[email-masked]] On Behalf Of Carl Wallace
Sent: Thursday, October 23, 2008 11:35 AM
To: Stefan Santesson; [email-masked]
Subject: RE: Comments on the TA requirements document

What about this requirement could not be met by a TA mgmt message addressed to all TA stores for which a manager is responsible and pulled from a directory?  This does not require push.

Stefan Santesson
Senior Program Manager

inline...

Denis comments:

Conclusion

Stefan Santesson
Senior Program Manager

---

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 25 Oct 2008 10:13:02 +0200

Irrespective of what we think about TA and TAM, I would (if I were
one of the advocates), consider other ways of establishing the goal than
[immediately] going through an IETF process.

So what to do then?  Create an Open Source project where you
in addition to specification also provide code for the platforms
you primarily target.  IF the concept gets traction, you MAY one
day create an RFC but then based on working (proven) code.
This process is probably twice as fast in calendar time.

As an example of a PKI(X)-related standardardization target that
would go nowhere in IETF is the concept of signing data on the web
in a browser session.  Why wouldn't such a thing go nowhere in the
IETF one may wonder?  Because a standards process would most
likely target the traditional view of signatures (a document with an
embedded signature), which in practical terms means supporting
native PDF, ODF, and OOXML formats in the signature "plug-in".
This principle however is based on a lack of understanding how
the web actually works today and even more how user attestations
actually are dealt with in information systems.  Due to that I am
in the processes of creating an Open Source project that is based
on "frozen" document views and detached signatures which is about
1/100 as complex the "right" solution.

A related initiative of mine that wouldn't get any support in PKIX
( http://www.imc.org/ietf-pkix/old-archive-03/msg01663.html )
is challenging schemes like Microsoft's CertEnroll and Mozilla's
generateCRMFRequest () in spite of the fact that they are only
supported by a single vendor respectively.

Anders Rundgren
http://WebPKI.org

---

From: "Carl Wallace" <[email-masked]>
Date: Sat, 25 Oct 2008 14:25:40 -0400

responses inline...

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Stefan Santesson
	Sent: Friday, October 24, 2008 10:48 PM
	To: Kemp, David P.; [email-masked]
	Subject: RE: Comments on the TA requirements document

	Dave

	This is not a matter of transport protocol. This is a matter of
how you manage policies and what protocols you need to support both
management and execution of these policies.

	The current requirement document mix together policy management
and policy execution in one bucket for TA management.

	The policy management part deals with ensuring that all hosts
knows what keys they are allowed to trust.

	The policy execution part deals with obtaining the keys and
parameters associated with managed policies and to put them in use in a
compliant manner.

	Policy management is always initiated and managed centrally and
pushed down to users/hosts, or at least enforced upon users/hosts in
some way or another. There are many ways to do this, but it always
involves some kind of central management. One way to do this that is
very common in my world, is to use a directory as the central mechanism
to publish policies combined with other functions (like system health
checks) to make sure hat policies has been downloaded and implemented.
In these common cases, there is no need for any new protocol.

	Policy execution is something that is carried out by the
user/host, based on the centrally distributed policy. One part of policy
execution in this case is to obtain/download the TAs that are considered
trustworthy by the distributed policy. Since the user/host is in control
and thus responsible for policy execution, they can also "pull" down any
key data associated with the TA policy. The only thing they would need
in order to do that, is a common data format for TA keys and their
parameters, signed by some kind of "master" TA policy management key.
That common data format for TA key information is all I currently need. 

	[CRW] Section 3.2.1 allows for this, i.e.,  a message to replace
an entire trust anchor store.   This sort of message is essentially a
common data format for TA key information.  Most of the requirements in
the draft are quite fundamental - replay detection, integrity, source
authentication, intended purposes, basic format requirements, etc. - and
would be required by pretty much any TA key information format that
could be defined.

	We may convince ourselves that we can make a central manager in
control of policy execution on behalf of users/hosts if we write a super
smart protocol (like PKIX TAM), but that would be an illusion. To some
extent we will always need to trust the user/host to carry out the
policy in an appropriate manner.

	This is the world I'm coming from when approaching this subject.
When I read the req document for TA management I do not recognize any
protocol that fit the needs of my environment.  

	[CRW] You should recognize lots in common with protocols in your
environment, namely certificates and certificate revocation lists.
Messages to add trust anchors are very similar to certificates.
Messages to remove certificates are very similar to certificate
revocation lists.  Most of the difficulty comes from limiting the
applicability/scope of the trust anchor keys.   

	This is why I have problems providing constructive feedback on
it.

	Stefan Santesson

	Senior Program Manager

	  <snip>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sun, 26 Oct 2008 18:42:44 -0400

Stefan,

I also do not see the I-D as favoring "push" over "pull".

Can you recommend what specific changes you want to make to the I-D?
That may get there faster.

My reading of the requirements document is that your model of publishing
policies and pulling them by clients is supported by the I-D provided
other security related requirements for authentication, integrity, and
replay protection are met.

Why do you think your approach does not meet the requirements I-D?
Again, if you suggest specific changes, that are at requirements level
(vice implementation), we are liable to get there and get there faster.

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Carl Wallace
Sent: Saturday, October 25, 2008 2:26 PM
To: [email-masked]
Subject: RE: Comments on the TA requirements document

responses inline...

Dave

This is not a matter of transport protocol. This is a matter of how you
manage policies and what protocols you need to support both management
and execution of these policies.

The current requirement document mix together policy management and
policy execution in one bucket for TA management.

The policy management part deals with ensuring that all hosts knows what
keys they are allowed to trust.

The policy execution part deals with obtaining the keys and parameters
associated with managed policies and to put them in use in a compliant
manner.

Policy management is always initiated and managed centrally and pushed
down to users/hosts, or at least enforced upon users/hosts in some way
or another. There are many ways to do this, but it always involves some
kind of central management. One way to do this that is very common in my
world, is to use a directory as the central mechanism to publish
policies combined with other functions (like system health checks) to
make sure hat policies has been downloaded and implemented. In these
common cases, there is no need for any new protocol.

Policy execution is something that is carried out by the user/host,
based on the centrally distributed policy. One part of policy execution
in this case is to obtain/download the TAs that are considered
trustworthy by the distributed policy. Since the user/host is in control
and thus responsible for policy execution, they can also "pull" down any
key data associated with the TA policy. The only thing they would need
in order to do that, is a common data format for TA keys and their
parameters, signed by some kind of "master" TA policy management key.
That common data format for TA key information is all I currently need. 

[CRW] Section 3.2.1 allows for this, i.e.,  a message to replace an
entire trust anchor store.   This sort of message is essentially a
common data format for TA key information.  Most of the requirements in
the draft are quite fundamental - replay detection, integrity, source
authentication, intended purposes, basic format requirements, etc. - and
would be required by pretty much any TA key information format that
could be defined.

We may convince ourselves that we can make a central manager in control
of policy execution on behalf of users/hosts if we write a super smart
protocol (like PKIX TAM), but that would be an illusion. To some extent
we will always need to trust the user/host to carry out the policy in an
appropriate manner.

This is the world I'm coming from when approaching this subject. When I
read the req document for TA management I do not recognize any protocol
that fit the needs of my environment.  

Stefan Santesson

Senior Program Manager

 <snip>

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 29 Oct 2008 14:27:15 +0000

Santosh,

I did read the requirements I-D in a very different manner than you, and for that reason I stopped pretty quickly noticing what specific things that could change in order for it to support both approaches.
I will give this one more go and try to come up with a reasonable response to your request.

Stefan Santesson
Senior Program Manager

From: [email-masked] [mailto:[email-masked]] On Behalf Of Santosh Chokhani
Sent: den 26 oktober 2008 23:43
To: [email-masked]
Subject: RE: Comments on the TA requirements document

Stefan,

Can you recommend what specific changes you want to make to the I-D?  That may get there faster.

My reading of the requirements document is that your model of publishing policies and pulling them by clients is supported by the I-D provided other security related requirements for authentication, integrity, and replay protection are met.

Why do you think your approach does not meet the requirements I-D?  Again, if you suggest specific changes, that are at requirements level (vice implementation), we are liable to get there and get there faster.

responses inline...

[CRW] Section 3.2.1 allows for this, i.e.,  a message to replace an entire trust anchor store.   This sort of message is essentially a common data format for TA key information.  Most of the requirements in the draft are quite fundamental - replay detection, integrity, source authentication, intended purposes, basic format requirements, etc. - and would be required by pretty much any TA key information format that could be defined.

[CRW] You should recognize lots in common with protocols in your environment, namely certificates and certificate revocation lists.   Messages to add trust anchors are very similar to certificates.  Messages to remove certificates are very similar to certificate revocation lists.  Most of the difficulty comes from limiting the applicability/scope of the trust anchor keys.

Stefan Santesson
Senior Program Manager