Subject: RE: Comments on the TA requirements document

From: "Kemp, David P." <[email-masked]>
Date: Mon, 3 Nov 2008 17:39:13 -0500

Stefan,

I can understand a distinction between "what must be done" and "how to
do it".  I can also draw a correlation between the XCCDF language that
specifies security configuration checklists and the OVAL language that
supports platform-dependent execution and reporting for checklist items
(http://scap.nist.gov).  What I don't understand is how:

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

would be considered to favor combined specification/execution over
separate specification of what to keys to trust and how to obtain them.
Would it help if it said "A protocol *suite* for TA management ..." to
encompass the possibility of multiple languages / stages of execution?

(It may not be immediately obvious that PKIX is the correct WG to
develop a TAM suite if the end product would be implemented under SCAP,
but the TA-specific expertise is undeniably in this group.)

Dave

From: Stefan Santesson [mailto:[email-masked]] 
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.

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

Windows Security, Standards