Subject: Re: RFC3280bis: policy processing.

From: "David A. Cooper" <[email-masked]>
Date: Wed, 04 May 2005 15:20:17 -0400

Steve,

A few of the members of the design team spent some time reviewing the 
issue that you brought up below.  We agree that X.509 and RFC 3280 
differ as you describe and that in some circumstances the outputs of the 
algorithms could differ.  However, we do not believe that the 
differences in the two algorithms will result in different outcomes in 
any realistic scenarios and so we do not believe that it is necessary to 
change 3280bis to align with X.509.

An example of where X.509 and RFC 3280 could produce different results 
is shown in "X509vsRFC3280_policyMappings.pdf" (attached).  Pages 1 and 
2 describe Certification Path 1 and the steps that would result from 
processing this certification path under X.509.  Under X.509 the output 
consists of a authorities-constrained-policy-set of {1, 2} whereas under 
RFC 3280 the authorities-constrained-policy-set would be {1}.  Note 
however, that the first certificate in the path include a policyMappings 
extension that maps from policy 1 to policy 2.  So, the outcome of path 
validation would effectively be the same in either case unless the 
user-initial-policy-set included the subjectDomainPolicy from the policy 
mapping (2), but not the issuerDomainPolicy (1).  This seem unlikely.  
On page 3, Certification Path 2 demonstrates that RFC 3280 would get the 
same result as X.509 if the first certificate in the certification path 
explicitly asserted policy 2 in addition to asserting policy 1.

As shown in "MorePolicyMappingOddities.pdf", it turns out that a number 
of unusual things can happen when the policyMappings extension is 
included in a certificate that also asserts anyPolicy.  These oddities 
occur in both X.509 and RFC 3280.  But, as before, they would only 
result in a different outcome for path validation if the 
user-initial-policy-set asserted a policy that appeared as a 
subjectDomainPolicy in the policyMappings extension but did not assert 
the corresponding issuerDomainPolicy.  So, while the results are 
unusual, it does not seem that it is necessary to make any changes to 
the algorithm.

Dave

Stephen Henson wrote:

> While I was checking the X509 policy processing against the RFC3280
> version I've noticed what I believe to be a discrepancy between the two.
>
> In RFC3280 the policy mapping processing is described in 6.1.4 b(1) as:
>
>> (1)  If the policy_mapping variable is greater than 0, for each node
>> in the valid_policy_tree of depth i where ID-P is the valid_policy,
>> set expected_policy_set to the set of subjectDomainPolicy values that
>> are specified as equivalent to ID-P by the policy mapping extension.
>>
>> If no node of depth i in the valid_policy_tree has a valid_policy of
>> ID-P but there is a node of depth i with a valid_policy of anyPolicy,
>> then generate a child node of the node of depth i-1 that has a
>> valid_policy of anyPolicy as follows:
>
> Whereas the corresponding text in X509 is in 10.5.2 d):
>
>> process any policy mappings extension by, for each mapping identified
>> in the extension, locate all rows in the 
>> authorities-constrained-policy-set table whose [path-depth] column
>> entry is equal to the issuer domain policy value in the extension,
>> and write the subject domain policy value from the extension in the
>> [path-depth+1] column entry of the same row. If the extension maps an
>> issuer domain policy to more than one subject domain policy, then the
>> affected row must be copied and the new entry added to each row. If
>> the value in authoritiesconstrained- policy-set[0, path-depth] is
>> any-policy, then write each issuer domain policy identifier from the 
>> policy mappings extension in the [path-depth] column, making
>> duplicate rows as necessary and retaining qualifiers if they are
>> present, and write the subject domain policy value from the extension
>> in the [pathdepth+ 1] column entry of the same row.
>
>
> Translating this into RFC3280 terms it appears the processing of 
> anyPolicy is different.
>
> In RFC3280 a new node is added only if a node of depth i doesn't exist 
> with a valid policy of ID-P.
>
> In X509 it appears to be saying a new node is added unconditionally.
>
> I believe this difference could result in different outputs from the 
> algorithm. In particular the X509 processing will (significantly) 
> result in nodes whose parent is anyPolicy which will not appear in the 
> RFC3280 version.
>
> Steve.

---

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 6 May 2005 16:01:41 +0100

Thanks David, you are absolutely right.

This property just slipped my mind for a moment.

Stefan Santesson 
Program Manager, Standards Liaison 
Windows Security 
  
________________________________________
From: David A. Cooper [mailto:[email-masked]] 
Sent: den 6 maj 2005 14:53
To: Stefan Santesson
Cc: pkix
Subject: Re: RFC3280bis: policy processing.

Stefan Santesson wrote: 
David,

Another aspect of this strikes me.

That is what happens when a policy mapping extension maps from one
issuer domain policy to several subject domain policies.

The text in X.509 has noticed the need to duplicate the row (node in RFC
3280) for the issuer domain policy to accommodate both mappings.

Reading this corresponding text from RFC 3280 it seems that the
corresponding creation of a new node is not specified in RFC 3280 which
would result in the same node being overwritten twice with a new subject
domain policy, resulting in a loss of the first mapping.

Unless I misread this, this seems to be a bug that we do need to fix.

Stefan,

In RFC 3280, this is addressed by maintaining, within a single node, the set of policies that appear as subject domain policies for a given issuerDomainPolicy (the expected_policy_set):
6.1.4  Preparation for Certificate i+1

   To prepare for processing of certificate i+1, perform the following
   steps for certificate i:

      (b)  If a policy mappings extension is present, then for each
      issuerDomainPolicy ID-P in the policy mappings extension:

         (1)  If the policy_mapping variable is greater than 0, for each
         node in the valid_policy_tree of depth i where ID-P is the
         valid_policy, set expected_policy_set to the set of
         subjectDomainPolicy values that are specified as equivalent to
         ID-P by the policy mappings extension.
Take, for example figure 6 from RFC 3280:
                          +-----------------+
                          |      Red        |
                          +-----------------+
                          |       {}        |
                          +-----------------+ node of depth i-1
                          |  {Gold, Silver} |
                          +-----------------+
                             /           \
                            /             \
                           /               \
                          /                 \
            +-----------------+          +-----------------+
            |      Gold       |          |     Silver      |
            +-----------------+          +-----------------+
            |       {}        |          |       {}        |
            +-----------------+ nodes of +-----------------+
            |     {Gold}      | depth i  |    {Silver}     |
            +-----------------+          +-----------------+

         Figure 6.  Processing unmatched policies when the certificate
         policies extension specifies anyPolicy
This subtree would be created as a result of:

certificate i-1:
certificatePolicies:  Red
policyMappings:
    issuerDomainPolicy: Red
    subjectDomainPolicy: Gold

    issuerDomainPolicy: Red
    subjectDomainPolicy: Silver

certificate i:
certificatePolicies: Gold, Silver

Dave