RE: I-D Action:draft-ietf-pkix-tamp-01.txt

["Carl Wallace" <[e-mail]>]

<snip>
> The latest [TAF] document appear to move away from specifically
categorizing Apex, Management and Identity trust 
> anchors. I agree with this change. The [TAMP] draft still indicates
these three types though and I no longer see how 
> they are distinguished. I do see that [TAMP, Section 1.3.2] indicates
that:
>   o  The trust anchor store MUST support the secure storage of exactly
>     one apex trust anchor.  The trust anchor store SHOULD support the
>     secure storage of at least one additional trust anchor. 
> but not how it is identified as the Apex. Or as a management trust
anchor, or identity trust anchor. Is it expected that > this information
would be encoded into the TAF extensions field[s]? For example TAMP
would specify a specific extension > with these types indicated?

The terms describe the function of a trust anchor, not necessarily its
composition.

A trust anchor is identified as the apex by placement, similar to a
certificate that is recognized as a trust anchor by placing it in a
trust anchor store.  The presence of a Apex trust anchor info
certificate extension is a clue, but placement is what makes a trust
anchor an apex.  This will be clarified in the next draft.

An identity TA must be able to validate certification paths, so it must
have name.  In an environment using the CCC spec for authorization, a
management trust anchor would contain a CCC extension.  Other
authorization mechanisms may have different hallmarks.

<snip>

> I like the idea of a TAF which can store information specific to
particular applications, various management protocols 
> such as CMS, and other things moving forward. TAMP apparently then
specifies specific authorizations and their meanings 
> but this doesn't limit or impact other uses? And importantly this type
of construct results in a TAF which may be either 
> Apex, Management, or Identity or any combination thereof including new
types in the future?

Right.  TAs can be any combination of TA types (except that an apex is
by definition a management TA) and could address various management
protocols (like CMS) are defined.

> This line of thought leads to some reflection on the [TAMP] discussion
illustrated by Figure 4-1 might be even further > 
> refined. I appreciate the update from "Crypto Module" to "Trust Anchor
Store" -- or maybe even a combination of the two 
> of them (this echoes my comment above about how the 802.1AR module
sounds like a combination of both of these elements). 
> Perhaps my confusion is that in my mind a Trust Anchor Manager is
communicating via TAMP with a TAMP service which is 
> then accessing the Trust Anchor Store. A picture is worth a thousand
words:


(my apologies if mail messes this up)
      +---------+      +----------+
      |         |      |          |
      |         |      |          |
      |         |      |          |
      |         | TAMP |          |
      | Trust   |<---->| TAMP     |
      | Anchor  |      | Process  | OS & Application
      | Manager |      |          | Service Interface
      |         |      |          |      +----------+
      |         |      |          |<---->|TAFs in a |
      |         |      |          |      |Crypto    |
      |         |      |          |      |Module    |
      |         |      |          |      |& Store   |
      +---------+      +----------+      +----------+


> I haven't seen a discussion that the "OS & Application Service
Interface" as being in scope. Drawing the diagram like > 
> this clarifies my impression that the TAF might be used by other
applications and that those applications might benefit 
> from the TAF standardization. Given the recent changes to [TAF] I
suspect things are moving in this direction?

The diagram above is an accurate representation.  You are correct that
the specs do not address the interface between the TA store and the
applications.  Not shown in the diagram is how the TA is actually used
(i.e., what an application does with a trust anchor once it retrieves it
from the store).  There will be another short specification submitted
soon that describes how to use TA-based constraints during certification
path validation.