Subject: WG Last Call: Son-of-2459

From: Tim Polk <[email-masked]>
Date: Wed, 14 Feb 2001 13:43:29 -0500

Folks,

The current version of Part1 is ready for Working Group Last Call; Last 
Call will close on or after February 28, 2001.

The draft is named draft-ietf-pkix-new-part1-04.txt.  The text has been 
posted and is available from the usual repositories, including: 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-04.txt

The name constraints issue has been addressed satisfactorily.  (See earlier 
message with subject "Resolution of name constraints issue").

I am aware of one open issue that needs to be discussed by this group.  The 
basic constraints text (4.2.1.10, page 37) and path validation algorithm 
wrap-up procedure (6.1.5, page 73) contained in this specification does not 
consider the path length constraint for an end certificate.   This may be 
considered a change from RFC 2459, and ...

                           *it was not discussed on the list*.

This is a change I made without bringing it to the attention of the 
list.  Oops.

We ran into this issue when we were developing the X.509 path validation 
tests.  After some discussion, we decided that the path length constraint 
did not apply to the end certificate. I thought I was clarifying the text 
of Part1 by making the corresponding changes.  However, users of the path 
validation tests have sited this as a *change* not a clarification.

It was not appropriate for me to make this change without discussion on the 
list.  We need to discuss this issue and resolve it on the list before WG 
Last Call closes.  I will be following this message with a more complete 
description of the problem this afternoon.

Thanks,

Tim Polk

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 20 Feb 2001 10:11:03 +0100

Tim,
 
> message with subject "Resolution of name constraints issue").

... but, in section 6, there is nearly no text on name constraints.

> consider the path length constraint for an end certificate.   

  ... and neither name constraints.

> This may be

I have found some time to take a look at section 6 from the long awaited
Son-of-2459, and I am disappointed. We spent quite an hour sitting
together with you during the Pittsburgh meeting to add the name constraints
to section 6.2 and I can't find that text. :-(

So let us go one by one at the changes that are required, and a few more
that we did not discuss. This makes 14 change proposals altogether:

1. Page 13. Current text:

    A CRL is a time stamped list
   identifying revoked certificates which is signed by a CA and made
   freely available in a public repository.

Proposed change:

   A CRL includes a list identifying revoked certificates and a date 
   of issue for that list, which is signed by a CA (or an entity 
   designated by the CA) and made freely available in a public 
   repository.

Rational: This sentence could be misleading by using the wording "time
stamped". Also the signature is usually not done with the CA issuing key.

2. Page 58. Current text:

   The
   binding is limited by constraints which are specified in the
   certificates which comprise the path and the initial state variables
   which are specified by the relying party. 

Proposed change:

   The binding is limited both by constraints which are specified in 
   the certificates which comprise the path and the initial state 
   variables which are specified by the relying party, such as 
   certificate policy and name constraints. 

Rational: name constraints were missing.

3. Page 58. Current text:

   The algorithm
   requires the public key of the CA, the CA's name, and any constraints
   upon the set of paths which may be validated using this key.

Proposed change:

   The algorithm requires the public key of the CA, the CA's name, 
   and any constraints upon the set of paths (i.e. using name 
   constraints) which may be validated using this key, and optionally 
   the validity period of this set of parameters (which may be 
   contained in a self-signed certificate). 

Rational: A CA self-signed certificate, when used, contains a validity
period which allows a nice key rollover using CMP.

4. Page 58. Current text:

   Section 6.3 describes the steps necessary to determine if a
   certificate is (…) on hold status when CRLs are the revocation
   mechanism used by the certificate issuer.

and 6.3 CRL Validation

   This section describes the steps necessary to determine if a
   certificate is (…) on hold status 

but in practice the case of on hold is not addressed in section 6.3 !  There
should be a story saying that if the certificate is on hold, then there is
still a chance, later on, to know that the certificate is no more revoked.
The text should be amended by the editor to address that case.

5. Page 59. Current text:

   The primary goal of path validation is to verify the binding between
   a subject distinguished name or subject alternative name and subject
   public key, as represented in the end entity certificate, based on
   the public key of the trust anchor.  

Proposed change:

   The primary goal of path validation is to verify for a given time 
   the binding between a subject distinguished name or subject 
   alternative name and subject public key, as represented in the 
   end entity certificate, based on the public key of the trust 
   anchor.

Rational: This is only valid at a given time, and thus necessary to say it.

6. Page 60. Current text: 

   However, a CA may issue a 
   certificate to itself to support key rollover or changes in 
   certificate policies.

Proposed change:

   However, a CA may issue a certificate to itself to support either 
   public key rollover, both public key rollover and changes in 
   certificate policies and/or name constraints.

Rational: name constraints were missing.

7. Page 61. Current text:

   6.1.1 Inputs

   This algorithm assumes the following seven inputs are provided to the
   path processing logic:

Proposed change:

   This algorithm assumes the following nine inputs are provided to the
   path processing logic:

Rational: see below that two additional parameters need to be initialized. 
7 + 2 = 9

8. Page 61. Current text:

  (b) the time, T, for which the validity of the path should be
      determined.  This may be the current date/time, or some point in
      the past.

Proposed change:

  (b) the time, T, for which the validity of the path should be
      determined.  This may be the current date/time, or some point in
      the past (see the security considerations section about the 
      limitations of that algorithm in the case of some time in
      the past).

Rational: some additional text has been provided in the security
consideration section to warn the user in the case of past validation. Note
that that has strong incidences on our current discussion on past validation
along DPV.

9. Page 62. Current text:

      (d) trust anchor information, describing a CA that serves as a
          trust anchor for the certification path.

Proposed change:

      (d) trust anchor information, valid at the time T, describing a 
          CA that serves as a trust anchor for the certification path.

Rational: This is only valid at a given time, and thus necessary to say it.

then add:

 (5) optionally, the validity period of the trusted public key 
     (which may be part of a CA self-signed certificate or be defined 
     independently).

Rational: A CA self-signed certificate, when used, contains a validity
period which allows a nice key rollover using CMP. The equivalent when
self-signed certificates are not used, should allow be permitted.

10. Page 62. Add the following

  (h)  initial permitted_subtrees, which indicates a name space 
within which all subject names in subsequent certificates in a 
certification path shall be located. Restrictions may apply to the 
subject distinguished name or subject alternative names only when the
specified name form is present. This parameter is either initialized 
using the name constraints contained in a CA self-signed certificate 
or defined as an independent parameter.

  (i) initial excluded_subtrees, which indicates a name space within 
which all subject names in subsequent certificates in a certification 
path shall not be located. Restrictions may apply to the subject 
distinguished name or subject alternative names only when the 
specified name form is present. This parameter is either initialized 
using the name constraints contained in a CA self-signed certificate 
or defined as an independent parameter.

Rational: These variables are used later on, but need to be initialized.

11. Page 75. Current text:

For example, a trusted CA may only be trusted for a particular certificate
policy.

Change proposal:

For example, a trusted CA may only be trusted for a particular certificate
policy or/and for some name space within which all subject names in
subsequent certificates in a certification path shall or shall not be
located. 

Rational: name constraints were missing.

12. Page 77. 6.3.3 CRL Processing

As said previously, there should be a story saying that if the certificate
is on hold, then there is still a chance, later on, to know that the
certificate is no more revoked. The text should be amended by the editor to
address that case.

13. Page 81. Section 9. Security Considerations

Current text:

   In addition, where a key compromise or CA failure occurs for a
   trusted CA, the user will need to modify the information provided to
   the path validation routine.  

Rational: The case of a key compromission for any key used in the path
validation should be addressed here. Add before that text:

   When performing path validation for a time in the past, because 
   CAs do not publish revocation information beyond the expiration 
   of a certificate, the path validation algorithm described in this 
   document (section 6) is only safe as long as the current time is 
   still within the certificate validity period of any certificate 
   used in the path validation.

   When a path validation succeeds for a current time, and when there
   might be a need to verify later on the validity of that path, it is 
   recommended to time stamp the certification path, the CRLs and/or
   the OCSP responses as soon as an initial verification is done. 
   This will prove that the certificates, CRLs or OCSP responses were 
   issued before the compromise of the key and will allow for a later 
   path verification to provide the same result (i.e. pass), otherwise 
   path validation would provide a different result (i.e. fail). 

   In order to avoid multiple and successive time stamps, a single 
   time stamp over the certification path and its associated 
   revocation information is recommended.

   This technique works as long as the key of the TSA is not itself
   compromised. Should that case happen, then two time stamps would 
   provide a protection. Should the key of a TSA likely to be soon 
   discovered (because of improvements in the cracking of a key or 
   an algorithm), an additional time stamp over the previous time 
   stamp obtained before this discovery would still provide a 
   protection.

14. Page 81. Section 9. Security Considerations

Current text:

   If the compromise is
   detected, all certificates issued to the CA shall be revoked,
   preventing services between its users and users of other CAs.
   Rebuilding after such a compromise will be problematic, so CAs are
   advised to implement a combination of strong technical measures
   (e.g., tamper-resistant cryptographic modules) and appropriate
   management procedures (e.g., separation of duties) to avoid such an
   incident.

Proposed text:

  [If the compromise is
   detected, all certificates issued to the CA shall be revoked,
   preventing services between its users and users of other CAs.]
   In any case, it is advisable to implement a combination of 
   strong technical measures (e.g., tamper-resistant cryptographic 
   modules) and appropriate management procedures (e.g., separation 
   of duties) to avoid such an incident. Should such an incident 
   nevertheless happen, then two options are possible depending upon 
   the context of the application:

     a)  When certificates are used for current time validation, 
         then the issuing key of the compromised CA shall be changed 
         and new cross certificates shall be issued to the CA.

     b)  When certificates are both used for current time and past 
         time validations, then the former measure still applies, 
         but in addition time stamping allows to continue to make use 
         of the already issued (and compromised) certificates, CRLs or 
         OCSP responses but only from the start of the original 
         validity period of the corresponding certificate used to verify 
         the signature of the certificates, CRLs or OCSP responses and 
         until revocation time of that certificate. 

Rational: A rebuilding is not problematic. It is possible to describe how to
recover from such a situation. The additional text describes one way to do
it.

Regards,

Denis

---

From: Steve Hanna <[email-masked]>
Date: Wed, 28 Feb 2001 17:09:41 -0500

For the record, I do not agree with these comments and I do not think
that any changes should be made to new-part1 because of them. My
responses are interspersed.

> ... but, in section 6, there is nearly no text on name constraints.

The text on name constraints in section 6 is perfectly adequate, when
combined with the text in section 4.2.1.11.

> to section 6.2 and I can't find that text. :-(

Substantial changes to IETF working group documents should be the result
of open discussions on the mailing list so that rough consensus can be
judged. Clarifications and simple corrections can be made by the
document editor on the basis of private conversations, but any
significant changes should at least be announced to the mailing list to
see if they reflect rough working group consensus before incorporating
them into the document. I haven't seen these changes (some rather
substantial) discussed before on the list, so I'm not surprised that
they didn't make it into the document.

> that we did not discuss. This makes 14 change proposals altogether:

I will address only some of the change proposals. This does not mean
that I agree with the ones I omit.

> Rational: name constraints were missing.

First, the text you quote as "current text" is actually from
draft-ietf-pkix-new-part1-03.txt. In draft-ietf-pkix-new-part1-04.txt,
this sentence has been changed to read "The binding is limited by
constraints which are specified in the certificates which comprise the
path and inputs which are specified by the relying party." The state
variables are initialized based on the relying party's inputs in the
initialization phase (section 6.1.2).

Second, in the basic validation algorithm described in section 6.1, the
relying party does not supply name constraints. Name constraints are
only provided by intermediate CA certificates. Some implementations may
extend the algorithm described in section 6.1 (using various techniques
such as those described in section 6.2), but I will argue strongly that
we should not include name constraints as an input to the basic
validation algorithm described in section 6.1. This is an unusual
feature and not commonly useful. It would be too great a burden to
require all implementations of the PKIX validation algorithm to include
support for it. That's why it belongs in section 6.2 and not in section
6.1. And, actually, it's not clear to me that it needs to be in section
6.2. Anyone is welcome to add support for specifying name constraints on
for each trust anchor or policy constraints or EKU constraints or
whatever they want. We don't need to describe how all of that would
work. We just need to describe the required algorithm and a few common
extensions (like multiple trust anchors).

> Rational: name constraints were missing.

Including name constraints in a self-issued certificate is pretty
unusual (and not likely to be very effective). In general, I suggest
finding a trusted CA (or a small number) and having them issue cross
certificates (with name constraints and any other fancy stuff). This
avoids the problem of having many trust anchors with various name
constraints, which must be replaced manually if the constraints change
(due to marketing, mergers, etc.).

-Steve