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

From: "Denis Pinkas" <[email-masked]>
Date: Tue, 19 Feb 2008 14:03:52 +0100

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.

The whole document is focusing on trust anchors, but the basic notion 
that is being used is flawed.

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

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. 

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

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

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.

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.

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

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.

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. 

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

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.

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

 - the fact that constraints that influence certification path validation 
   may be understood either as constraints that allow to build 
   a 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.

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.

RFC 3379 and RFC 5055 should be added to the informative references.

Denis

>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.
>
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-pkix-ta-mgmt-problem-statement-01.txt

---

From: "Carl Wallace" <[email-masked]>
Date: Tue, 19 Feb 2008 17:43:05 -0500

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:

It also states:

This draft states:

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.    

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

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.

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

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.

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.

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.

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.

The content of a Trust Anchor Store should be formatted while being
transferred, so that it can be locally interpreted without any
ambiguity. 

[CRW] Agree.

So I am challenging the fact that the following requirement should
apply:

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

So I am challenging the fact that the following requirement should
apply:

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:

The document states:

[CRW] The trust anchor definition in the draft does include the
constraints.

 - the fact that constraints that influence certification path
validation 
   may be understood either as constraints that allow to build 
   a certification path or also as constraints that allow to make sure 
   that none of the certificates from the certification path are revoked

[CRW] I'm not sure what this means.

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.

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