[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-pkix
Subject:    RE: Comments 1 to 13 - Response to WGLC on TAM: draft-ietf-pkix-ta-mgmt-reqs-01.txt
From:       "Carl Wallace" <CWallace () cygnacom ! com>
Date:       2008-10-16 20:26:31
Message-ID: FAD1CF17F2A45B43ADE04E140BA83D487A4542 () scygexch1 ! cygnacom ! com
[Download RAW message or body]


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

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

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

3 - The document is only considering one way to manage TAs, i.e. when TA

information is "pushed" towards a device or a system.   
 
[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:  

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

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

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

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

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

See the second message for comments 14 to 28.


[prev in list] [next in list] [prev in thread] [next in thread]