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

From: "Denis Pinkas"<[email-masked]>
Date: Thu, 16 Oct 2008 09:55:32 +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 is about comments 1 to 13. 
The second part will be about comments 14 to 28.
 
=========================================================== 
Comments on TAM: draft-ietf-pkix-ta-mgmt-reqs-01.txt. October 3, 2008  

Summary  

The current draft omits to take into consideration the existence of a TA  
management protocol that already exists and which is defied in RFC 4210.  

The current draft omits to take into consideration the concept of a validation  
policy which is described in RFC 3379 and in RFC 3125.  

The current draft only considers a push model, whereas a pull model should be  
considered.  

A different approach with three steps is proposed.  

Please find below a list of 28 detailed comments.  

1 - The document states in the abstract: "A trust anchor represents an  
authoritative entity via a public key and associated data. The public key is  
used to verify digital signatures ...".  

This is incorrect. A trust anchor is not simply used to verify *digital  
signatures*, but to verify *chains of certificates*.  

2 - The abstract is incorrect, since it mentions the "lack of a standard trust  
anchor management mechanism", whereas a management protocol based on pull model  
described in RFC 4210 exists.  

3 - The document is only considering one way to manage TAs, i.e. when TA  
information is "pushed" towards a device or a system.  

CMP (RFC 4210) defines a protocol which allows root CAs to make available  
information that allows updating TAs. See section 4.4. "Root CA Key Update".  
In order to use it efficiently, the following data should be placed within a TA:  

   - an indicator to state whether automatic self-signed certificate updates are  
     allowed or not,  
   - URLs to say where the updated self-signed certificates may be fetched, and  
   - the expected time period between two consecutive self-signed certificate  
     updates.  

This would allow a RP to pull self-signed certificates and to renew them before  
they expire.  
As a consequence, when only updates of root keys is a concern, no new protocol  
for updating TA information needs to be defined, since there already exists one.  

Such a pull protocol offers a major advantage over the push model. When the  
system is placed in an intranet behind a firewall, it can make use of a web  
proxy to acquire updated self-signed certificates, usually on the Internet. As a  
consequence, there is no need to open new ports on the firewall to allow  
external connections for remote management. That information may be cached and  
the external world is then unaware of the number of devices or systems that uses it.  

The other major advantage is that the access control rights are included in the  
self-signed certificate: only the CA that has signed it is allowed to change it.  
This a very compact form which avoids managing access rights as it would be the  
case with the push model.  

4 - In order to allow the use of the pull model, additional data needs to be  
associated with a TA. Hereafter is a proposal for a requirement:  

"Section 3.X. TA format for automatic update  

3.X.1 Functional requirement  

The format of the TA must support the CMP protocol defined in RFC 4210 that  
allows changing self-signed certificates. The format must allow indicating: (a)  
whether automatic updates are allowed or not, (b) where the information may be  
fetched, and (c) the expected time period between two consecutive published  
information. Once a TA has been updated there should be two TAs valid at a time  
for the same CA: the old one and the new one.  

3.X.2. Rationale  

CMP defines a protocol which allows root CAs to provide information that allows  
a smooth change key rollover. The protocol allows to pull information from a CA  
store and to automatically update TA information. When a root CA renews its  
self-signed certificate, the old self-signed certificate needs to be used to  
verify old certificates, while the new one needs to be used to verify new  
certificates. This means that usually two TAs are valid at one point of time for  
each root CA".  

5 - As RFC 3379 mentions, TAs are used in validation policies:  

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

   Additional constraints for each trust anchor MAY be defined. These  
   constraints might include a set of certification policy constraints  
   or a set of naming constraints. These constraints MAY also be  
   included in self-signed certificates.  

   Additional conditions that apply to the certificates in the path MAY  
   also be specified in the validation policy. For example, specific  
   values could be provided for the inputs to the certification path  
   validation algorithm in [PKIX-1], such as user-initial-policy-set,  
   initial-policy-mapping-inhibit, initial-explicit-policy, or initial-  
   any-policy-inhibit.  

   Additional conditions that apply to the end-entity certificate MAY  
   also be specified in the validation policy. For example, a specific  
   name form might be required.  

   A validation policy is built from three components:  

   1. Certification path requirements,  
   2. Revocation requirements, and  
   3. End-entity certificate specific requirements.  

The format of a validation policy may be rather complex. Before attempting to  
standardize its detailed content, a first step would be to define the format of  
TAs that must be placed inside validation policies. Systems or devices could  
then locate TA information within the validation policies, and take into account  
the format of the TAs to automatically renew the TAs, if allowed.  

6 - A second step, more ambitious, in the direction of standardization would be  
to allow to add, remove or replace validation policies as a whole, but treat the  
detailed rules as opaque. The additional requirements would be reduced to the  
identification of the validation policies and the identification of the entities  
allowed managing them as a whole.  

7 - In order to address the second step, a validation policy must include  
information such as:  

   - a unique identifier of the policy,  
   - the name of the issuer of the policy,  
   - the field of application of the policy, etc ...  

8 - To summarize the approach for both the first and the second steps, a  
validation policy store would include:  
   - management information for the ownership of a validation policy store  
     (not modifiable by the validation policy manager).  
   - a unique identifier of the policy, the name of the issuer of the policy,  
     the field of application of the policy, etc ...  
   - a set of TAs, each one with :  
       - an indicator to state whether automatic self-signed certificate updates  
         are allowed or not,  
       - URLs to say where the updated self-signed certificates may be fetched,  
         and  
       - optionally, the time period between two consecutive self-signed  
         certificate updates.  
   - an opaque definition of the validation policy that contains pointers  
     to the TAs placed above with constraints for each TA.  

The picture below attempts to show the general content of a validation policy  
and its relationship with TAs, each TA being placed in *one* TAS (TA store)  

  +------------------------+   +------------------------+
  |   Validation policy 1  |   |   Validation policy 2  |
  |                        |   |                        |
  |     Description        |   |     Description        |
  |      +--------+        |   |      +--------+        |
  |      |  TAS 1 |        |   |      |  TAS 2 |        |
  |      +--------+        |   |      +--------+        |
  |      +--------+        |   |      +--------+        |
  |      |  TAS 2 |        |   |      |  TAS 3 |        |
  |      +--------+        |   |      +--------+        |
  |   +--------------+     |   |   +--------------+     |
  |   |  Purpose 1   |     |   |   |  Purpose 1   |     |
  |   |              |     |   |   |              |     |
  |   | TAS 1 Ref.   |     |   |   | TAS 2 Ref.   |     |
  |   |+ constraints |     |   |   |+ constraints |     |
  |   |              |     |   |   |              |     |
  |   | TAS 2 Ref.   |     |   |   | TAS 3 Ref.   |     |
  |   |+ constraints |     |   |   |+ constraints |     |
  |   +--------------+     |   |   +--------------+     |
  |   +--------------+     |   |   +--------------+     |
  |   |  Purpose 2   |     |   |   |  Purpose 3   |     |
  |   |              |     |   |   |              |     |
  |   | TAS 2 Ref.   |     |   |   | TAS 3 Ref.   |     |
  |   |+ constraints |     |   |   |+ constraints |     |
  |   +--------------+     |   |   +--------------+     |
  +------------------------+   +------------------------+

Note: if the above example, if the validation policy 1 is applied to a CMS  
message that is both signed and encrypted, then Purpose 1 specifies the  
conditions for signature validation, while purpose 2 specifies the conditions  
for decryption.  

9 - If the concern is also addition and deletion of trust anchors, TAs anchors  
that are present in a validation policy store can only be defined, added or  
removed by a "validation policy manager", i.e. NOT a “TA store manager” 

10 - The final step would be the definition of the detailed contents of some  
validation policies.  

11 - The document states: "There is currently no standard means of limiting the  
applicability (scope) of a trust anchor except by placing different TAs in  
different stores and limiting the set of applications that access a given TA  
store".  

This is incorrect. RFC 3125 introduces the concept of a "signature policy" and  
of a "signature validation policy" that allows to designate different trust  
anchors for the validation of the signer's certificate *and* for the validation  
of time-stamp tokens. TAs are placed in validation policies, not in Trust Anchor  
Stores.  

12 - The verification of a chain of certificates mandates the checking of  
revocation statuses of the certificates from the revocation chain. This aspect  
is not addressed in the draft. Such rules need to be defined in the validation  
policy.  

Some old implementations are simply omitting to check the revocation statuses.  
In some other cases, it may be sufficient to use ARLs for CA certificates, but  
for leaf certificates an OCSP response may sometimes be required. In some other  
cases, the use of delta CRLs may be required. When OCSP is used the source of  
authority may not necessarily be the CA that has issued the certificate. In some  
other cases, it may be required to check at regular intervals if an emergency  
ARL or CRL has not been issued. In that case the intervals should be specified.  

All these aspects are related to the third step. They should be mentioned in the  
draft.  

13 - Signature validation policies (that are used for non-repudiation purposes)  
cannot be changed (i.e. redefined), but can only be replaced. This means that  
updating a TA within a signature validation policy is not allowed. As a  
consequence, a signature validation policy can only be changed as a whole.  

On the contrary, TAs contained in other types of validation policies (e.g. used  
for authentication purposes) may be changed.  

==================================================

See the second message for comments 14 to 28.

---

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

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

Summary  

[CRW] A reference to the RFC 4210 mechanism has been added to section 2
of the draft.  The RFC 4210 mechanism was discussed relative to the
requirements draft during the WG meeting in Dublin.  

The current draft omits to take into consideration the concept of a
validation  
policy which is described in RFC 3379 and in RFC 3125.   
 
[CRW] Validation policies are indirectly referenced in section 3.5,
which requires the trust anchor management protocol to support
management of trust anchors in accordance with RFCs 5280 and 5055.
Validation policies were discussed relative to the requirements draft
during the WG meetings in Philadelphia and Dublin.

The current draft only considers a push model, whereas a pull model
should be  
considered.   
 
[CRW] The requirements are applicable to either push or pull models.
This will be made explicit in section 3.1.

1 - The document states in the abstract: "A trust anchor represents an  
authoritative entity via a public key and associated data. The public
key is  
used to verify digital signatures ...".  

 
[CRW] The definition in the draft was the result of much mailing list
and WG/BOF discussion.  TAs are used for purposes other than
verification of "chains of certificates".  No change resulted from this
comment.
 
2 - The abstract is incorrect, since it mentions the "lack of a standard
trust  
anchor management mechanism", whereas a management protocol based on
pull model  
described in RFC 4210 exists.   
 
[CRW] As noted above, a reference to the 4210 mechanism has been added
to section 2.   

 
[CRW] As noted above, the requirements are applicable to push or pull
models.  This will be made explicit in section 3.1.

 <snip - CMP discussion>
 
4 - In order to allow the use of the pull model, additional data needs
to be  
associated with a TA. Hereafter is a proposal for a requirement:  

The format of the TA must support the CMP protocol defined in RFC 4210
that  
allows changing self-signed certificates. The format must allow
indicating: (a)  
whether automatic updates are allowed or not, (b) where the information
may be  
fetched, and (c) the expected time period between two consecutive
published  
information. Once a TA has been updated there should be two TAs valid at
a time  
for the same CA: the old one and the new one.  

3.X.2. Rationale  

CMP defines a protocol which allows root CAs to provide information that
allows  
a smooth change key rollover. The protocol allows to pull information
from a CA  
store and to automatically update TA information. When a root CA renews
its  
self-signed certificate, the old self-signed certificate needs to be
used to  
verify old certificates, while the new one needs to be used to verify
new  
certificates. This means that usually two TAs are valid at one point of
time for  
each root CA".   
 
[CRW] Section 3.7 requires support for managing self-signed
certificates.  This provides a bridge to the RFC 4210 mechanism.  The
automatic update information could be instantiated as an instance of the
"associated data" included in the definition of a TA.   No change
resulted from this comment.

 <snip - quotation from RFC 3379>
 
The format of a validation policy may be rather complex. Before
attempting to  
standardize its detailed content, a first step would be to define the
format of  
TAs that must be placed inside validation policies. Systems or devices
could  
then locate TA information within the validation policies, and take into
account  
the format of the TAs to automatically renew the TAs, if allowed.   
 
[CRW] Validation policies are already been standardized - in RFC 5055.
The requirements for TA formats are defined in section 3.7.   We're not
defining the requirements for managing or using validation policies.  No
change resulted from this comment.

6 - A second step, more ambitious, in the direction of standardization
would be  
to allow to add, remove or replace validation policies as a whole, but
treat the  
detailed rules as opaque. The additional requirements would be reduced
to the  
identification of the validation policies and the identification of the
entities  
allowed managing them as a whole.   
 
[CRW]  We've discussed validation policies at two PKIX meetings and
there has been little (or no) support voiced for using validation
policies as TAs or TA stores.  No change resulted from this comment.

7 - In order to address the second step, a validation policy must
include  
information such as:  

validation policy store would include:  
   - management information for the ownership of a validation policy
store  
     (not modifiable by the validation policy manager).  
   - a unique identifier of the policy, the name of the issuer of the
policy,  
     the field of application of the policy, etc ...  
   - a set of TAs, each one with :  
       - an indicator to state whether automatic self-signed certificate
updates  
         are allowed or not,  
       - URLs to say where the updated self-signed certificates may be
fetched,  
         and  
       - optionally, the time period between two consecutive self-signed

         certificate updates.  
   - an opaque definition of the validation policy that contains
pointers  
     to the TAs placed above with constraints for each TA.  

The picture below attempts to show the general content of a validation
policy  
and its relationship with TAs, each TA being placed in *one* TAS (TA
store)  

 <snip - ASCII art>
 
Note: if the above example, if the validation policy 1 is applied to a
CMS  
message that is both signed and encrypted, then Purpose 1 specifies the

conditions for signature validation, while purpose 2 specifies the
conditions  
for decryption.  

9 - If the concern is also addition and deletion of trust anchors, TAs
anchors  
that are present in a validation policy store can only be defined, added
or  
removed by a "validation policy manager", i.e. NOT a "TA store manager" 

10 - The final step would be the definition of the detailed contents of
some  
validation policies.   
 
[CRW] Re: 7, 8, 9 and 10, we're not defining the requirements for
managing or using validation policies.  No change resulted from this
comment. 

11 - The document states: "There is currently no standard means of
limiting the  
applicability (scope) of a trust anchor except by placing different TAs
in  
different stores and limiting the set of applications that access a
given TA  
store".    

This is incorrect. RFC 3125 introduces the concept of a "signature
policy" and  
of a "signature validation policy" that allows to designate different
trust  
anchors for the validation of the signer's certificate *and* for the
validation  
of time-stamp tokens. TAs are placed in validation policies, not in
Trust Anchor  
Stores.   
 
[CRW]  Will reword to state that there is no standard general purpose
mechanism.  In any case, RFC 3125 is experimental.

12 - The verification of a chain of certificates mandates the checking
of  
revocation statuses of the certificates from the revocation chain. This
aspect  
is not addressed in the draft. Such rules need to be defined in the
validation  
policy.  

Some old implementations are simply omitting to check the revocation
statuses.  
In some other cases, it may be sufficient to use ARLs for CA
certificates, but  
for leaf certificates an OCSP response may sometimes be required. In
some other  
cases, the use of delta CRLs may be required. When OCSP is used the
source of  
authority may not necessarily be the CA that has issued the certificate.
In some  
other cases, it may be required to check at regular intervals if an
emergency  
ARL or CRL has not been issued. In that case the intervals should be
specified.  

All these aspects are related to the third step. They should be
mentioned in the  
draft.   
 
[CRW] RFC 5280 addresses revocation status checking.  The revocation
status of trust anchors is not checked, hence the omission of a
discussion of revocation status checking.  No change resulted from this
comment. 

13 - Signature validation policies (that are used for non-repudiation
purposes)  
cannot be changed (i.e. redefined), but can only be replaced. This means
that  
updating a TA within a signature validation policy is not allowed. As a

consequence, a signature validation policy can only be changed as a
whole.  

On the contrary, TAs contained in other types of validation policies
(e.g. used  
for authentication purposes) may be changed.  
 
[CRW] We're not defining the requirements for managing or using
validation policies.  No change resulted from this comment.