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

["Santosh Chokhani" <[e-mail]>]

Would it be more accurate to say that signer of TAMP messages must be a
management TA or the signer's certification path must terminate at a
management TA. 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Carl Wallace
> Sent: Wednesday, March 11, 2009 3:48 PM
> To: max pritikin; [e-mail]
> Subject: RE: I-D Action:draft-ietf-pkix-tamp-01.txt 
> 
> 
> <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.
> 
>