Re: [IETF-PKIX] Dave's Critical Proposal

["David P. Kemp" <dpkemp@xxxxxxxxxxxxxx>]

> From: Warwick Ford <wford@VERISIGN.COM>
> >
> >  "If an implementation recognizes the syntax of a particular extension,
> >   the value of the critical boolean in that extension SHALL be ignored."
>
> This would be going too far.  A critical extension conveys semantics that a
> conforming implementation must implement, otherwise not use the
> certificate.  With a non-critical extension, there is no requirement to
> implement particular semantics -- the extension may be ignored, regardless
> of whether or not the implmentation recognizes the syntax.


Warwick (and Bob),
  You are correct; I did not make a distinction between "recognize"
and "support".  A hypothetical implementation might recognize a particular
extension but not, for some reason, claim for compliance purposes to
support it.  Would the following rule be more suitable?

  "If an implementation claims PKIX-compliant support for a particular
   extension, where the scope of "support" is specified in the
   extension definition, then when processing that extension the value
   of the critical flag SHALL be ignored."


In the case of certificatePolicies, "recognize" or "support" means that
the application must support both the certificatePolicies extension
{ id-ce 32 } itself and at least one of the policies (specified by
the policyIdentifier field) contained in the extension.


> From: John Pawling <jsp@JGVANDYKE.COM>
>
> Dave,
>
> X.509, Sec 12.4.3, certificate check, bullet 6 states:
> "d) If the certificate policies extension is present and is flagged
> critical, compute the intersection of the policies in that extension and the
> authority-constrained-policy-set and put the result as the new value of
> authority-constrained-policy-set. Check that the intersection of
> authority-constrained-policy-set and user-constrained-policy-set is non-empty."
>
> If certificate-processing software followed your proposed rule, then it
> wouldn't be allowed to use the value of the certificate policies extension
> critical flag as part of the certification path validation process specified
> in X.509, Sec 12.4.3.  Therefore, your statement is contradictory to X.509
> and should not be added to PKIX I.


I submit that this contradiction is a red flag that a design inconsistency
exists in X.509.

A CA has three options with respect to including a particular extension in
a certificate:  not present, non-critical, and critical.

An application has two options: claim support for an extension or not claim
support.

The processing of a particular extension by an application may have the
following outcomes:

                 |           Application:
      Cert:      | Not supported     Supported
                 |----------------|-------------
    absent       |     N/A        |    N/A
                 |                |
    non-critical |    Ignore      |  Process
                 |                |
    critical     |  Reject cert   |  Process


The path validation procedure described in section 12.4.3 introduces
a third column to processing model:

                 |---------------
    absent       |     N/A
                 |
    non-critical |   Process-A
                 |
    critical     |   Process-B


The use of a single flag for two independent purposes (managing
compatibility with non-supporting applications, and selecting different
processing in supporting applications) sounds like a mistake.

Is there really a need for the phrase "and is flagged critical" to be
included in certificate checks paragraph d)?  If not, it should be
removed from X.509.

If there is an operational requirement for both certificatePolicies
that are used as input to authority-constrained-policy-set, and
policies that are present in a cert but not used as input to a-c-p-s,
then two different extensions should be defined to specify the two
different processing procedures.  My suspicion is that there is no such
operational requirement.