Subject: I-D Action:draft-ietf-pkix-ta-mgmt-problem-statement-01.txt

From: [email-masked]
Date: Mon, 18 Feb 2008 07:15:01 -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 Problem Statement
	Author(s)       : R. Reddy, C. Wallace
	Filename        : draft-ietf-pkix-ta-mgmt-problem-statement-01.txt
	Pages           : 15
	Date            : 2008-02-18

A trust anchor is an authoritative entity represented via a public
key and associated data.  The public key is used to verify digital
signatures and the associated data is used to constrain the types of
information for which the trust anchor is authoritative.  A relying
party uses trust anchors to determine if a digitally signed object is
valid by verifying a digital signature using the trust anchor's
public key, and by enforcing the constraints expressed in the
associated data for the trust anchor.  This document describes some
of the problems associated with the lack of a standard trust anchor
management mechanism as well as problems that must be addressed by
such a mechanism.  This document discusses only public keys as trust
anchors; symmetric key trust anchors are not considered.

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

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-pkix-ta-mgmt-problem-statement-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ta-mgmt-problem-statement-01.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

---

From: "Denis Pinkas" <[email-masked]>
Date: Mon, 25 Feb 2008 16:37:32 +0100

Carl,

Comments are in line.

>comments inline... 

><snip>
>
>We both agree that specifying the format is the major goal. 
>However the current text does not say it yet.
>
>The concept of TA is defined in RFC 3280 and since 3280bis will be soon
>issued, it will not be changed before many years.
>
>[CRW] The current draft requires compatibility with RFC3280.  
>
>It is not possible to use the same name, i.e. TA, with two different
>meanings.
>
>So you should use a different name for a "TA with associated data".
>For the time being let us call it TAAD.   

>[CRW] I don't see the need for this distinction.  There have been two TA
>structures posted so far (the definitions in 3125 and TAMP).  Both are
>similar and could be viewed as a "TA with associated data".  RFC3280bis
>does not include the inputs to path validation in its TA definition, so
>that information would be associated data.  

[DP] I am puzzled. On one hand you say the two concepts are different and 
on the other hand you say "I don't see the need for this distinction". 

In order to understand eachother, we need to speak using the same words 
for the same concepts. At this time, we have not yet acheived that goal.

>A TA Store is not simply an addition of TAADs. 
>Some additional data may apply for all TAADs present in given TAS (TA
>Store).
>Let us call it for the time being: TASAD.
>
>The content of a TAS may then be modelized as: TASAD + sigma (TAAD)
>
>With this model in mind, I would agree that it is possible to add or
>remove a TAAD as a whole.
>
>We will have to identify what kind of data can be associated with a TAS
>and what kind of data can be associated with a TA. 
>
>Do you agree with the above concepts
>(leaving aside the terminology that can be changed) ? 
>
>[CRW] The idea of TA store data independent of TA data is interesting
>and ought to be considered.

[DP] Thanks. There are however further ideas there. So I restate my question:
     Do you agree with the above concepts
     (leaving aside the terminology that can be changed) ?

><snip>
>
>Would you be able to elaborate, or provide an example for pull ?
>
>[CRW] The language in the 2nd paragraph of section 3 aims to support the
>generation of a TA mgmt message that is targeted such that unintended
>trust anchor stores reject the message.  Whether the message is pushed
>or pulled doesn't matter.  For example, if I generate a TA mgmt message
>that targets one TA store to add a TA and try to use that message to add
>the TA to a different trust store then the operation should fail.

[DP] Undertstood, but this may lead to a large number of ways to do it, 
whether a TA Store simply has a unique name, belongs to a category or 
has a key of its own. Interoperability might be very difficult for that 
requirement. So I would rather consider it as an option.
 
><snip>

Denis

---

From: "Denis Pinkas" <[email-masked]>
Date: Mon, 25 Feb 2008 16:36:01 +0100

Carl,

Some additional comments on this e-mail.
Comments are in line too.

>Comments inline...
>
><snip>
>This draft redefines "trust anchors" in a way that is not compatible
>with RFC 3280. RFC 3280 does not contain a formal definition of a trust
>anchor, but contains the following sentences:
>
>The trust anchor information includes:
>
>   (1)  the trusted issuer name,
>
>   (2)  the trusted public key algorithm,
>
>   (3)  the trusted public key, and
>
>   (4)  optionally, the trusted public key parameters associated
>        with the public key.
>
>It also states:
>
>   Valid paths begin with certificates issued by a trust anchor.
>   The algorithm requires the public key of the CA, the CA's name, 
>   and any constraints upon the set of paths that may be validated 
>   using this key.
>
>This draft states:
>
>   Trust Anchor: A trust anchor is an authoritative entity represented
>   via a public key and associated data. (...) A relying party uses 
>   trust anchors to determine if a digitally signed object is valid 
>   by verifying a digital signature using the trust anchor's public 
>   key, and by enforcing the constraints expressed in the associated 
>   data for the trust anchor. 
>
>This makes a big difference. 
>
>In this draft, the trust anchor would include "constraints expressed in
>the associated data for the trust anchor", whereas RFC 3280 considers
>that these constraints are external to the trust anchor information.
>
>[CRW] This difference is intentional, as RFC3280 is only one context
>addressed for TA mgmt.    

[DP] You recognize that there is a difference, but you still want 
to use the same wording. Once again, two different wordings should be used.

><snip>
>
>Let us start from the beginning: an application needs to validate some
>public key certificates and for doing this will have to use data
>contained in at least one Trust Anchor Store which contains one or more
>sets of trust anchor *and additional data*.
>
>[CRW] A more general starting point would be signature verification,
>since validating public key certificates is only one example.

[DP] No. Signature verification is more complex.

>A "Trust Anchor Store manager" (that is different from the notion of "TA
>manager" as defined in the draft) may need to change or update the
>content of a given Trust Anchor Store. 
>
>[CRW] Perhaps the "TA Manager" definition in the draft should be "TA
>Store Manager" since they are referring to the same role.

[DP] The roles are different, but I would be happy if you drop the term "TA manager". 

>The content of a Trust Anchor Store equals to a validation policy. 
>Validation policies may be rather complex, so the very first requirement
>is to be able to define or change the content of a Trust Anchor Store
>*as a whole*.

>[CRW] I could see this either way but replacing an entire store to
>change one bit in one TA may be too inefficient in some scenarios.
>Maybe there's an additional requirement to support whole store
>replacement, but that doesn't seem appropriate as the only mechanism.

What you use a signature policy, you cannot updrade or downgrade it, 
you must replace it as a whole and assign it a new OID or URN.

>It is very doubtful that *updates* to a Trust Anchor Store would be
>feasible. 
>The current draft makes the assumption that it would. 

>[CRW] Why is this so?  Current means don't require replacing an entire
>store to add or remove a single TA.

[DP] This would only be feasible for the use with an authentication service.

When you have a signature policy, you must keep track of the conditions 
that were used and thus a signature policy cannot be modified.

When you have a confidentiality policy, it may be important to know 
what were the rules when a document was encrypted. In the same way, 
these policies may need to be archived.

>So I am challenging the fact that the following requirement should
>apply:
>
>    At a minimum, it [a general-purpose solution] must enable 
>    a trust anchor manager to discovery which TA stores are present, 
>    to add trust anchors to, remove trust anchors from, and determine 
>    which trust anchors are installed in a particular trust anchor
>    store.

>A Trust Anchor Store manager may need to change data in the Trust Anchor
>Store that is not associated with one TA itself. For example, it may
>decide that OCSP responses shall be used, or that CRLs shall be used, or
>that a new CRL shall be fetched if a CRL in the cache is older that 2
>hours, or that delta-CRLs shall be used, etc ... This requirement may be
>different for every level of the certification tree or in the
>certification forest. 
>This kind of requirement is fully missing in the current draft.
>
>[CRW] Revocation sources could be an additional form of constraint.
>That seems reasonable.

[DP] Fine.

>Whatever the certification tree is, a Trust Anchor Store manager may
>also decide to use leaf certificates that contain a particular
>extension, e.g.
>which mentions that it is a qualified certificate. This kind of concept
>is a property associated data contained in a Trust Anchor Store.
>
>[CRW] OK.
>
>The draft considers that each trust anchor is associated with a "scope
>of authority" "(e.g., a trust anchor public key may be limited to
>verification of firmware updates only), or more general (such as to
>validate certification paths for certificates issued to users or
>devices)", whereas the picture is fully inversed: a given "scope of
>authority" will accept one or more trust anchors *and additional data*.
>
>So I am challenging the fact that the following requirement should
>apply:
>
> Trust anchors may be explicitly authorized for a limited set of
>purposes.
>
>The major problem with this draft is that it places Trust Anchors at the
>top of the hierarchy, whereas Trust Anchor Stores are at the top. 
>
>[CRW] This relates to a discussion on the TAM list regarding requiring
>different trust anchor store managers with different privileges to
>manage different trust anchor stores.  Addressing that requirement may
>solve the hierarchy problem you are citing.

[DP] I am unsure it would, unless the concept of "TA manager" vanishes. 

>Using the vocabulary defined in RFC 5055, each Trust Anchor Store
>contains one "validation policy".
>
>This means that it is the responsibility of the Trust Anchor Store
>manager to define which trust anchors shall be used and which additional
>data shall be associated with it.
>
>The current draft is mandating the existence of a *single* protocol to
>"push" 
>information to the Trust Anchor Stores. It is much more important to
>specify the format of the information that will be pushed and to leave
>the details for pushing it to the local OS or to a management
>application.
>
>[CRW] Specifying the format is the goal.  The draft mandates neither
>push nor pull.

[DP] I am glad that you agree "Specifying the format is the goal". 
The draft should be modified to acknowledge it.

>The content of a Trust Anchor Store should be formatted while being
>transferred, so that it can be locally interpreted without any
>ambiguity. 
>
>This allows pulling the formatted data.
>
>[CRW] Agree.
>
>So I am challenging the fact that the following requirement should
>apply:
>
>   A protocol for TA management must allow a TA management 
>   transaction, to be directed to all TA stores for which the manager 
>   is responsible, targeted to an enumerated list of one or more
>   groups of trust anchor stores, or targeted to an individual trust
>   anchor store. 
>
>[CRW] This requirement does not relate to push or pull.  The language
>should be improved to indicate the intent is to limit the intended
>recipients (i.e., target trust stores).

>"Discovering which trust anchors installed in a particular trust anchor
>store" is not an interesting requirement. Knowing that a given store contains
>four trust anchors does not help, since the additional data that places
>constraints both on the way to build the certification tree and *the way
>to check that none of the certificates from the certification tree is
>revoked* are not part of the information placed in a trust anchor.
>
>[CRW] TAs are defined as including the additional data (see your earlier
>objection).  Including revocation mechanism as a constraint seems fine
>to me.  

[DP] Fine.

>So I am challenging the fact that the following requirement should
>apply:
>
>   Despite the prevalent use of trust anchors, there is neither a
>   standard means for discovering which trust anchors installed in a
>   particular trust anchor store nor a standard means of managing those
>   trust anchors.
>
>The current draft is mandating the existence of a *single* protocol to
>"pull" information from Trust Anchor Stores. It is more important to specify
>the format of the information that will be pulled and to leave the
>details for pulling it from the local OS or from a management
>application.
>
>[CRW] Specifying the format is the goal.  The draft mandates neither
>push nor pull.
>
>So I am challenging the fact that the following requirement should
>apply:
>
>   A trust anchor manager must be able to authenticate which device
>   produced a report listing the contents of a trust anchor store and,
>   be able to confirm the contents of the report have not been
>   subsequently altered.
>
>The document states:
>
>   A trust anchor definition should enable the representation of
>   constraints that influence certification path validation or otherwise
>   establish the scope of usage of the trust anchor public key.
>
>There are two problems with that sentence:
>
> - a vocabulary problem, since the current trust anchor definition 
>   does not include the constraints, and
>
>[CRW] The trust anchor definition in the draft does include the
>constraints.

[DP] In this case the draft is not consistent because it does 
at some point of time and at some other it does not.
In addition, your reply does not address the concern that is raised.

> - the fact that constraints that influence certification path
>   validation may be understood either as constraints that allow to 
>   builda certification path or also as constraints that allow to make 
>   sure that none of the certificates from the certification path are revoked
>
>   using some timeliness indicators.
>
>[CRW] I'm not sure what this means.

[DP] This point has been responded in an earlier e-mail.

     Denis

>Finally the security considerations section contains additional
>requirements (e.g. "it must be possible to authenticate the originator
>of a TA management transaction and confirm the authorization of the
>originator for that transaction", whereas it should only highlight some
>security issues.

>[CRW] This is going to be fixed.  The plan is to replace this draft with
>a requirements draft.  A problem statement isn't needed since this isn't
>a BOF.  We started to late to get a new -00 draft submitted before the
>deadline.
>
>RFC 3379 and RFC 5055 should be added to the informative references.
>
>[CRW] OK.
>
>Denis
>
>>This draft is a work item of the Public-Key Infrastructure (X.509) 
>>Working
>Group of the IETF.
>>
>>
>>	Filename        :
>>  draft-ietf-pkix-ta-mgmt-problem-statement-01.txt
>>	Pages           : 15
>>	Date            : 2008-02-18
>>
>>A trust anchor is an authoritative entity represented via a public key 
>>and associated data.  The public key is used to verify digital 
>>valid by verifying a digital signature using the trust anchor's public 
>>key, and by enforcing the constraints expressed in the associated data 
>>for the trust anchor.  This document describes some of the problems 
>>associated with the lack of a standard trust anchor management 
>>mechanism as well as problems that must be addressed by such a 
>>mechanism.  This document discusses only public keys as trust anchors; 
>>symmetric key trust anchors are not considered.
>>
>>http://www.ietf.org/shadow.html or 
>>ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>	"FILE
>/internet-drafts/draft-ietf-pkix-ta-mgmt-problem-statement-01.txt".
>>
>>Content-Type: text/plain
>>Content-ID:     <[email-masked]>
>>
>>ENCODING mime
>>FILE /internet-drafts/draft-ietf-pkix-ta-mgmt-problem-statement-01.txt