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

[max pritikin <[e-mail]>]

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, [e-mail] wrote:

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