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

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

> From: John Pawling <jsp@JGVANDYKE.COM>
>
> I believe that your text expresses the original intention of the critical
> flag, but there are several cases in the 1997 X.509 Recommendation in which
> the critical flag is used for purposes beyong the original intent.  X.509,
> Sec 12.4.3, states special processing requirements for certificatePolicies
> extensions that are flagged critical.  Also, X.509, Sec 12.6.2, states
> special requirements associated with CRLDistributionPoint extensions that
> are marked critical.  Therefore, your proposed text should not be added to
> PKIX I because it would be contradictory to the X.509 Recommendation.


The text of 1997 X.509 section 12.2.2.6 (Certificate policies) is:

  If the extension is flagged critical, it indicates that the certificate
  shall be used for the purpose, and in accordance with the rules implied
  by one of the indicated certificate policies.  The rules of a particular
  policy may require the certificate-using system to process the qualifier
  in a particular way.

  If the extension is flagged non-critical, use of this extension does
  not necessaily constrain use of the certificate to the policies listed.
  However, a certificate user may require a particular policy to be present
  in order to use the certificate.

I believe that this text is a clarification of, not a contradiction of,
the original meaning of the critical flag:  it requires an application to
support (be able to recognize and act on) not only the syntax of the
certificatePolicies extension itself, but also the particular OIDs
present in the extension.

The wording of 12.2.2.6, standing alone, is open to misinterpretation: it
could be read as giving the critical flag the ability to modify the meaning
of the extension.  But that wording is also compatible with the "correct"
interpretation - it describes the effect of the critical flag when considered
over all implementations, not just those applications which support the
extension and the specific policy IDs.

That is why the wording of particular extensions must be considered in
the context of the universal meaning of the critical flag, not taken in
isolation.

For a simpler example, consider section 12.4.2.1 (Basic constraints):

  If this extension is present and is flagged critical then:
    -- if the value of cA is not set to true then the certified public
       key shall not be used to verify a certificate signature;

In the case of applications which do not support basicConstraints, this
statement is true because the critical flag causes the certificate to
be rejected.

In the case of applications which do support basicConstraints, the
cA flag is always expected to be honored, regardless of whether the
critical flag is set or not.  I.e. the critical flag does not modify
the meaning of the extension in applications which support the extension.

Section 12.4.2.1 omits an explicit statement for the non-critical case,
(except for Note 1).  If that statement were present, it might read:

  If the extension is flagged non-critical, use of this extension does
  not necessaily constrain use of the certificate to comply with the
  cA and pathLenConstraint values.

This statement is true not because it gives permission for supporting
applications to ignore the cA flag (it does not), but because it
recognizes that non-supporting applications may ignore the extension.

I still believe that an explicit statement of the (original) meaning of
the critical flag is needed.  That statement supplements, and does not
contradict, the wording in certificatePolicies and elsewhere.