Subject: Criticality marking of the policy mappings extension

From: Tim Moses <[email-masked]>
Date: Fri, 2 Jun 2000 16:26:01 -0400

Colleagues - I have just reviewed the path processing procedure specified in
the certificate and CRL profile Internet draft.  I have the following
observations.  Let's start with very minor ones ...

1.  In 6.1.3 (b) it says "If certificate i is not self-issued, verify that
the subject name is within one of the permitted_subtrees for X.500
distinguished names, ...".  This rule applies to end-user certificates, as
well as CA certificates.  So, perhaps it should be explicitly stated that a
null subject is within all permitted_subtrees, including a null one.

2.  There appears to be something missing from 6.1.3 (d) (3).  It reads ...
"The two nodes at depth i-1 that are marked with an to the resulting tree
will cause the node at depth i-2 that is marked with a Y to be deleted."

3.  Sub-paras (1) and (2) of 6.1.4 (g) should be indented.

4.  Para 6.1.4 (m) should say "If pathLengthConstraint is present in the
basic constraints extension of the certificate ..."

5.	The reference at the very end of 6.1.4 should be to para 6.1.3, not
6.1.2.

6.	The extended path validation described in Para 6.2 deals with the
case of multiple trust anchors.  In this case it says: "Limitations in the
trust path for any particular key may be incorporated into the self-signed
certificate's extensions.  In this way, the self-signed certificates permit
the path validation module to automatically incorporate local security
policy and requirements."  Setting aside the questions of whether this is a
good thing or a bad thing and whether or not it is consistent with X.509.  I
wonder whether it is appropriate to have different behaviour depending upon
the number of trust anchors.

7.  The final comment relates to the criticality marking on the policy
mappings extension.  If an (admittedly non-conformant) client were to
encounter a PKIX certificate with a non-critical policy mappings extension,
then it could accept the path, when the issuer of the certificate intended
it to reject the path.

Consider this example.  A CA issues a certificate to another CA.  The
certificate policies extension identifies Policy A, and the non-critical
policy mappings extension maps Policy A to Policy B.  The other CA issues a
certificate under Policy A.  The intention of the first CA is that the
certificate user would reject this certificate.  But, a client that
understood certificate policies, but not policy mapping would accept the
certificate. Therefore, it should be permissible to mark the policy mappings
extension critical.  But, this is disallowed by Para 4.2.1.6, which requires
the extension to be marked non-critical.

The 2000 version of X.509 allows and recommends that the policy mappings
extension be marked critical.  So, the PKIX profile should make the same
recommendation.

----------------------------------------------------------------------------
-----------
Tim Moses
Tel: 613.247.3183