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

From: [email-masked]
Date: Wed, 4 Mar 2009 08:15:02 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title           : Trust Anchor Management Protocol (TAMP)
	Author(s)       : R. Housley, et al.
	Filename        : draft-ietf-pkix-tamp-01.txt
	Pages           : 84
	Date            : 2009-03-04

This document describes a transport independent protocol for the
management of trust anchors and community identifiers stored in a
trust anchor store.  The protocol makes use of the Cryptographic
Message Syntax (CMS), and a digital signature is used to provide
integrity protection and data origin authentication.  The protocol
can be used to manage trust anchor stores containing trust anchors
represented as Certificate, TBSCertificate or TrustAnchorInfo
objects.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-tamp-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: max pritikin <[email-masked]>
Date: Thu, 5 Mar 2009 11:30:43 -0600

The following questions concern the [TAMP], [TAF] and [TAMR] drafts  
(versions indicated below). I've been reading these documents to see  
how they line-up or conflict with the IEEE 802.1AR (Device Identity)  
draft that I am the editor for. This perspective colors my comments.

Broadly IEEE 802.1AR concerns itself with the shipping of a device  
complete with an X.509 certificate issued by the manufacturer. This  
may be accompanied by the manufacturer's certificate chain. Storage  
and use of associated private key material are within the module.  
802.1AR defines mechanisms for insertion and management of additional  
identity certificates issued by a local CA.

In this context I think the 802.1AR module is loosely analogous to a  
'trust anchor store' as described in [TAMR, Section 1] combined with  
the Cryptographic Module discussed in [TAMP, Section 1.3.1]. The 'TA  
manager' would use the 802.1AR defined service interface to interact  
with the module; and of course no 802.1AR limitations are made that  
prohibit additional service interface functionalities specific to TAMP  
(or any other management application) are defined.

The use of local CA issued certificates within 802.1AR appears  
consistent with the 'identity trust anchors'. The manufacturer  
installed certificate and certificate chain on the other hand could be  
described as some combination of the 'apex', 'management' and even  
'identity' trust anchors depending on future use. This is where my  
questions about these drafts arise. I'm like to know more about how  
you envision pre-installed credentials being catagorized.

On the subject of categorization reading these document has raised the  
following questions for me:

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?

(I continue to be unsure how to relate this to the 802.1AR concepts of  
an 'initial device identity' installed during manufacturing vs a  
'local device identity' installed later.  But if these types are TAMP  
specific vs TAF specific perhaps that is less of a concern.)

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?

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?

Thanks for any clarifications,

- Max Pritikin

referenced documents:
[TAF] draft-ietf-pkix-ta-format-01
[TAMP] draft-ietf-pkix-tamp-01
[TAMR] draft-ietf-pkix-ta-mgmt-reqs-02

On Mar 4, 2009, at 10:15 AM, [email-masked] wrote:

> <mime-attachment>

---

From: "Carl Wallace" <[email-masked]>
Date: Wed, 11 Mar 2009 15:47:50 -0400

<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
> 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 
words:

> 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.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 11 Mar 2009 16:56:24 -0400

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