Subject: Comments 14 to 28 - Response to WGLC on TAM: draft-ietf-pkix-ta-mgmt-reqs-01.txt

From: "Denis Pinkas"<[email-masked]>
Date: Thu, 16 Oct 2008 10:10:23 +0200

These comments have been sent twice to the WG list but have not appeared on the list.
The first message was sent on October 10.

These comments have then been sent to the co-chairs for investigation, but there is no result yet.
So I am reposting them, split in two parts, in case the original message was rejected because it was too long.
The first part was about comments 1 to 13.
The second part is about comments 14 to 28.
=============================
14 - The definition of a Trust Anchor (see section 1.1) is not adequate and 
should be changed. 

RFC 3379 states: "A trust anchor is defined as one public key, a CA name, and a 
validity time interval; a trust anchor optionally includes additional 
constraints. The use of a self-signed certificate is one way to specify the 
public key to be used, the issuer name, and the validity period of the public 
key". 

Replacement proposal: 

Trust Anchor: data that includes one public key, a CA name, a validity time 
interval and optionally additional constraints to be used when constructing and 
validating a certification path, *as well as information for updates*. A self- 
signed certificate with or without constraints may be used to specify the root 
key of a trust anchor and additional constraints". 

15 - The current definition of a Trust Anchor Store (see section 1.1) is : 
Trust Anchor Store: A trust anchor store is a set of one or more trust anchors. 
A trust anchor store may be managed by one or more trust anchor managers. A 
device may have more than one trust anchor store. 

Change into: 

“Trust Anchor Store: A trust anchor store is a container which contains one 
trust anchor”. 

Within a validation policy, TAs can be grouped into sets, so that different sets 
can be used for different purposes. For example, within a signature validation 
policy, a set of TAs may be used to validate Attributes Certificates, while 
another one may be used to validate time-stamp tokens. 

RFC 3379 states in section 7: 

   A validation policy is a set of rules against which the validation 
   of the certificate is performed. 
   A validation policy MAY include several trust anchors. (...) 
   Additional constraints for each trust anchor MAY be defined. (...) 
   These constraints MAY also be included in self-signed certificates. 

16 - Additional proposal: 

Validation Policy Store: compartment to place a set of rules, uniquely 
identified, that serve specific purposes against which the validation of a 
certificate or of a signature shall be performed. It includes at least one 
trust anchor associated with constraints, but may include several sets of trust 
anchors associated with other constraints to be used within the policy for a 
specific purpose". 

17 - Instead of a Trust Anchor Manager, a Validation Policy Manager should be 
defined. 

Proposal: 

Validation Policy Manager: A role responsible for managing the full contents of 
a given validation policy store. 

18 - Since a device or a system may support several validation policies, some 
entity should be able to create empty validation policy stores and then tell who 
is able to manage each of them. 

Proposal: "Validation Policy Stores Manager": A role responsible for managing, 
for a given device or system, associations between validation policies stores 
and validation policy managers. 

19 - The requirements in sections 3.X should be on validation policies rather 
than on TAs. 

20 - In section 3.2.1, if would be better to separate the functional 
requirements for validation policy stores managers, validation policy managers 
and the functional requirements for TAs. 

Functional requirement for validation policy stores managers: 
   o List the identifier and the attributes of the validation policies stores 

Functional requirements for validation policy managers: 
   o Determine the content of a validation policy store 
   o Define the content of a validation policy store 
   o Replace the content of a validation policy store 
   o Delete the content of a validation policy store 

Functional requirement for TAs: 
   o Update one or more TAs contained in a validation policy. 

21 - Section 3.5.1 is omitting to mention the revocation conditions that apply 
in RFC 5280 as well as the additional constraints that may exist. 

22 - Section 3.7.1 is about "Trust Anchor Formats". The problem is that a 
validation policy does not simply include TAs, but other information. The 
relationship between the TA formats and the validation policy format should be 
explained. 

23 - Section 3.7.1 is about "Trust Anchor Formats". The texts states: 

   Minimally, a trust anchor management protocol must support management 
   of trust anchors represented as self-signed certificates and trust 
   anchors represented as a distinguished name and public key 
   information. 

This sentence is incorrect since a trust anchor is not simply defined using a 
distinguished name and public key information. Please refer to new proposed 
definition of a Trust anchor. 

There is also the need for a management protocol to support the management of a 
validation policy as a whole. 

The texts states: 

The definition of a trust anchor must include a public key, a public key 
algorithm and, if necessary, public key parameters. 

This is in contradiction with the previous sentence. 

   When the public key is used to validate certification paths, a 
   distinguished name also must be included per [RFC3852]. 

The next sentence attempts to express a requirement, but is not understandable : 

A trust anchor format should enable specification of public key identifier to 
enable other applications of the trust anchor, for example, verification of data 
signed using the Cryptographic Message Syntax (CMS) SignedData structure 
[RFC3852]. 

What is the "specification of public key identifier" ? The conditions that would 
apply to verify data signed using CMS may not be included in the TA format since 
a root CA may not be aware of all the various usages of its root certificate. 

The last sentence states: 

A trust anchor format should also enable the use of constraints that can be 
applied to specify the type/usage of a trust anchor. 

It makes sense to associate additional constraints with TAs. The basic question 
is whether they should be included in the format of the TA or placed outside, 
i.e. in the validation policy. 
Since TAs may be used for different purposes in the same validation policy or in 
different validation policies, it should be allowed to associate different 
constraints. 

   - If the constraints are included in self-signed certificates, then they are 
     set by CA managers. 

   - If the constraints are not included in self-signed certificates, then they 
     are set by validation policy managers (rather than by TA managers). 

The above requirement does not capture these aspects. 

24 - Section 3.8.1. Functional requirements that apply to validation policy 
managers and validation policy stores managers should also be considered 
instead. Proposal: 

A validation policy manager must be able to authenticate which validation policy 
store corresponds to a report listing the contents of a validation policy 
storage and be able to confirm the contents of the report have not been 
subsequently altered. Replay of old reports (from the same device or system) 
must be detectable by a validation policy manager. 

A validation policy manager must be able to authenticate which device or system 
corresponds to a report listing the characteristics of the validation policy 
stores and be able to confirm the contents of the report have not been 
subsequently altered. Replay of old reports (from the same device or system) 
must be detectable by a validation policy stores manager. 

25 - Section 3.9 about source authentication. The functional requirements from 
section 3.9.1 are unrelated to the rationale from section 3.9.2. The rational is 
about authorization while the requirements are about authentication. This 
section needs to be revised. 

26 - Section 3.10 about a reduction of reliance on out-of-bands mechanism. While 
the rationale from section 3.10.2 is roughly correct, the functional 
requirements from section 3.10.1 are unrelated. 

Replace with: 

Out-of-band trust mechanisms should only be required to allow validation policy 
stores managers to manage validation policy stores. 

27 - Section 12 is about disaster recovery. 

This requirement should not be placed in the MUST category but in the SHOULD 
category (it is only a nice-to-have feature). Systems should not be mandated to 
implement it. It is unsure what the editors have in mind behind this 
requirement. Further explanations would be appreciated. 

28 - Section 4. Security considerations section. 

The text states: 

In all scenarios, regardless of the authentication mechanism, at least one trust 
anchor manager must be established for each trust anchor store during the 
initial configuration of the trust anchor store. 

The text should be reworded as follows: 

In all scenarios, regardless of the authentication mechanism, at least one 
validation policy stores manager must be established for each device or system.

---

From: "Carl Wallace" <[email-masked]>
Date: Thu, 16 Oct 2008 16:26:36 -0400

Responses to specific comments are inline below.   I've snipped some
lengthy portions of the comments to avoid exceeding whatever message
length requirement prevented the initial distribution of the comments.

________________________________

 <snip - introductory text>

14 - The definition of a Trust Anchor (see section 1.1) is not adequate
and 
should be changed. 

RFC 3379 states: "A trust anchor is defined as one public key, a CA
name, and a 
validity time interval; a trust anchor optionally includes additional 
constraints. The use of a self-signed certificate is one way to specify
the 
public key to be used, the issuer name, and the validity period of the
public 
key". 

Replacement proposal: 

Trust Anchor: data that includes one public key, a CA name, a validity
time 
interval and optionally additional constraints to be used when
constructing and 
validating a certification path, *as well as information for updates*. A
self- 
signed certificate with or without constraints may be used to specify
the root 
key of a trust anchor and additional constraints". 

[CRW] The current definition was the result of much discussion on the
TAM BOF/PKIX mailing lists.  The current definition accommodates the
suggested scenario if validity period, update information, etc. is
viewed as associated data.  No change resulted from this comment.

15 - The current definition of a Trust Anchor Store (see section 1.1) is
: 
Trust Anchor Store: A trust anchor store is a set of one or more trust
anchors. 
A trust anchor store may be managed by one or more trust anchor
managers. A 
device may have more than one trust anchor store. 

Change into: 

"Trust Anchor Store: A trust anchor store is a container which contains
one 
trust anchor". 

Within a validation policy, TAs can be grouped into sets, so that
different sets 
can be used for different purposes. For example, within a signature
validation 
policy, a set of TAs may be used to validate Attributes Certificates,
while 
another one may be used to validate time-stamp tokens. 

<snip - RFC 3379 quotation>

<snip - validation policy store definition>

17 - Instead of a Trust Anchor Manager, a Validation Policy Manager
should be 
defined. 

Proposal: 

Validation Policy Manager: A role responsible for managing the full
contents of 
a given validation policy store. 

[CRW] Re: 15, 16 and 17, we're not defining the requirements for
managing or using validation policies so these definitions are not
applicable.  No change resulted from these comments. 

18 - Since a device or a system may support several validation policies,
some 
entity should be able to create empty validation policy stores and then
tell who 
is able to manage each of them. 

Proposal: "Validation Policy Stores Manager": A role responsible for
managing, 
for a given device or system, associations between validation policies
stores 
and validation policy managers. 

19 - The requirements in sections 3.X should be on validation policies
rather 
than on TAs. 

20 - In section 3.2.1, if would be better to separate the functional 
requirements for validation policy stores managers, validation policy
managers 
and the functional requirements for TAs. 

<snip - functional requirements for validation policies>

[CRW] Re: 18, 19 and 20, we're not defining the requirements for
managing or using validation policies.  No change resulted from this
comment.  Comment 19 neatly summarizes the core disagreement.

21 - Section 3.5.1 is omitting to mention the revocation conditions that
apply 
in RFC 5280 as well as the additional constraints that may exist. 

[CRW] Will add a note to 3.5.2 noting that trust anchors used to
validate certification paths must provide revocation status information.

22 - Section 3.7.1 is about "Trust Anchor Formats". The problem is that
a 
validation policy does not simply include TAs, but other information.
The 
relationship between the TA formats and the validation policy format
should be 
explained. 

[CRW] A discussion of the relationship between concrete TA formats and
validation policy is probably appropriate for a document, but this is
not the appropriate document.  No change resulted from this comment.

This sentence is incorrect since a trust anchor is not simply defined
using a 
distinguished name and public key information. Please refer to new
proposed 
definition of a Trust anchor. 

[CRW] Will augment this statement to include associated data.

There is also the need for a management protocol to support the
management of a 
validation policy as a whole. 

[CRW] We're not defining the requirements for managing or using
validation policies.  

The texts states: 

The next sentence attempts to express a requirement, but is not
understandable : 

A trust anchor format should enable specification of public key
identifier to 
enable other applications of the trust anchor, for example, verification
of data 
signed using the Cryptographic Message Syntax (CMS) SignedData structure

[RFC3852]. 

What is the "specification of public key identifier" ? 

[CRW] In contexts where TAs are represented as certificates, it is the
inclusion of a subjectKeyIdentifier extension.

The conditions that would 
apply to verify data signed using CMS may not be included in the TA
format since 
a root CA may not be aware of all the various usages of its root
certificate. 

[CRW] In some cases this is true, in other cases the usages are known.
The requirement is that the protocol support the expression of these
constraints, not that all systems use this.

<snip - discussion of constraint placement>

24 - Section 3.8.1. Functional requirements that apply to validation
policy 
managers and validation policy stores managers should also be considered

instead. Proposal: 

<snip - discussion of validation policy managers>

[CRW] We're not defining the requirements for managing or using
validation policies.  No change resulted from this comment. 

25 - Section 3.9 about source authentication. The functional
requirements from 
section 3.9.1 are unrelated to the rationale from section 3.9.2. The
rational is 
about authorization while the requirements are about authentication.
This 
section needs to be revised. 

[CRW] This section will be revised.  Most likely, sections 3.8 and 3.9
will be collapsed into one section.

26 - Section 3.10 about a reduction of reliance on out-of-bands
mechanism. While 
the rationale from section 3.10.2 is roughly correct, the functional 
requirements from section 3.10.1 are unrelated. 

Replace with: 

Out-of-band trust mechanisms should only be required to allow validation
policy 
stores managers to manage validation policy stores. 

[CRW] We're not defining the requirements for managing or using
validation policies, so the replacement text was not used.  I fail to
see that 3.10.1 and 3.10.2 are unrelated, but they are inconsistent.
Revised text for section 3.10.1 will be included in the next draft. 

This requirement should not be placed in the MUST category but in the
SHOULD 
category (it is only a nice-to-have feature). Systems should not be
mandated to 
implement it. It is unsure what the editors have in mind behind this 
requirement. Further explanations would be appreciated. 

[CRW] The requirement is that the protocol support this.  Systems are
not mandated to implement it.  Will try to make this more clear in the
draft. 

The text states: 

In all scenarios, regardless of the authentication mechanism, at least
one trust 
anchor manager must be established for each trust anchor store during
the 
initial configuration of the trust anchor store. 

In all scenarios, regardless of the authentication mechanism, at least
one 
validation policy stores manager must be established for each device or
system.

[CRW] We're not defining the requirements for managing or using
validation policies.  No change resulted from this comment.

---

From: "Denis Pinkas"<[email-masked]>
Date: Mon, 27 Oct 2008 09:39:30 +0100

The fact that some topics were discussed at WG meetings such as in Philadelphia or Dublin 
does  not mean that any decision what taken on these topics. Since everybody cannot attend meetings
the mailing list has the last word.
First of all, I pleased to read that you consider that the pull model should be part of the requirements.
Nonetheless, I  will be interested to see how the draft is redrafted to allow the use of a pull model. 
I would be particularly interested to understand what a "TA manager" means in such a case.
One basic question is whether constraints may be included within self-signed certificates or/and 
may be associated with self-signed certificates. IMO, both cases exist, but there is a major difference 
between these two cases :
   a) Constraints included within a self-signed certificate are valid for *all RPs* during the whole validity period 
      of the self-signed certificate and *cannot be changed* during its life-time.
    b) Constraints associated with a self-signed certificate can be tailored by every RP to a specific use 
        and thus can be changed by the RP during the life-time of the self-signed certificate.
I have two questions:
1) What is the relationship between a  "TA manager" and a RP ?
2) According to your understanding of the responsabilities dedicated to a "TA manager", 
is a "TA manager" involved or not involved in the above two cases ?
RFC 5055, which is a standard track document, specifies in its introduction:
   The path construction or validation
   (e.g., making sure that none of the certificates in the path are
   revoked) is performed according to a validation policy, which
   contains one or more trust anchors.  
It is clear that TAs are data elements contained in a validation policy. 
If someone manages TAs, its relationship with a validation policy manager must be clarified.
RFC 5055 also references the definition given in RF 3379:
   A validation policy (as defined in RFC 3379 [RQMTS]) specifies the
   rules and parameters to be used by the SCVP server when validating a
   certificate.
A core of the disagreement relates to comment 22 where you say:
[CRW] A discussion of the relationship between concrete TA formats and validation policy 
is probably appropriate for a document, but this is not the appropriate document. 
No change resulted from this comment.
Since this is a very important issue, I believe that a discussion of the relationship between concrete TA formats 
and validation policy is necessary. Until the draft clarifies the relationship between concrete TA formats 
and validation policies we will make no progress on that topic.
Denis
De : owner-ietf-pkix 
À : ietf-pkix 
Date : 2008-10-16, 21:26:36
Sujet : RE: Comments 14 to 28 - Response to WGLC on TAM: draft-ietf-pkix-ta-mgmt-reqs-01.txt

Replacement proposal: 

Change into: 

Proposal: 

The texts states: 

[RFC3852]. 

instead. Proposal: 

Replace with: 

The text states:

---

From: "Carl Wallace" <[email-masked]>
Date: Mon, 27 Oct 2008 08:19:06 -0400

RE: WG meetings discussions - Validation policies and TAM have been
discussed on this list and the TAM BOF list.  The slides and audio feeds
from the cited meetings are available.

RE: push/pull - As noted in recent related threads, the current draft
supports "push" and "pull".

RE: relying parties and TAs - Relying parties use trust anchor stores.
TA managers manage trust anchor stores.  Relying parties may be TA
managers.

RE: TA manager involvement in given scenarios - The involvement of a TA
manager in the two cited scenarios depends on how the TA format is
defined.  See draft-ietf-pkix-ta-format-00 for a proposal.  In that
case, a TA manager may be involved in both scenarios.

RE: TA managers and validation policy managers - Though we've not
defined "validation policy manager", it seems likely that a validation
policy manager would use a TA store when composing a validation policy.
That TA store would be managed by a TA manager.  As with relying
parties, the same entity may function as a TA manager and as a
validation policy manager.

RE: validation policies - Trust anchor usage is a broader topic than
validation policy usage.   We are not defining requirements for
validation policy management.  Since the draft does not define a
concrete trust anchor format and is not addressing validation policy
management, a discussion of the relationship between concrete TA formats
and validation policies is unnecessary.

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Denis Pinkas
	Sent: Monday, October 27, 2008 4:40 AM
	To: ietf-pkix
	Subject: RE: Response to WGLC on TAM:
draft-ietf-pkix-ta-mgmt-reqs-01.txt

	The fact that some topics were discussed at WG meetings such as
in Philadelphia or Dublin 
	does  not mean that any decision what taken on these topics.
Since everybody cannot attend meetings
	the mailing list has the last word.

	First of all, I pleased to read that you consider that the pull
model should be part of the requirements.
	Nonetheless, I  will be interested to see how the draft is
redrafted to allow the use of a pull model. 

	I would be particularly interested to understand what a "TA
manager" means in such a case.

	One basic question is whether constraints may be included within
self-signed certificates or/and 
	may be associated with self-signed certificates. IMO, both cases
exist, but there is a major difference 
	between these two cases :

	   a) Constraints included within a self-signed certificate are
valid for *all RPs* during the whole validity period 
	      of the self-signed certificate and *cannot be changed*
during its life-time.

	    b) Constraints associated with a self-signed certificate can
be tailored by every RP to a specific use 
	        and thus can be changed by the RP during the life-time
of the self-signed certificate.

	I have two questions:

	2) According to your understanding of the responsabilities
dedicated to a "TA manager", 
	is a "TA manager" involved or not involved in the above two
cases ?

	RFC 5055, which is a standard track document, specifies in its
introduction:

	   (e.g., making sure that none of the certificates in the path
are

	It is clear that TAs are data elements contained in a validation
policy. 
	If someone manages TAs, its relationship with a validation
policy manager must be clarified.

	   A validation policy (as defined in RFC 3379 [RQMTS])
specifies the

	   rules and parameters to be used by the SCVP server when
validating a

	   certificate.

	[CRW] A discussion of the relationship between concrete TA
formats and validation policy 
	is probably appropriate for a document, but this is not the
appropriate document. 
	No change resulted from this comment.

	Since this is a very important issue, I believe that a
discussion of the relationship between concrete TA formats 
	and validation policy is necessary. Until the draft clarifies
the relationship between concrete TA formats 
	and validation policies we will make no progress on that topic.

	Denis

	<snip>