Subject: RE: RFC3280bis: policy processing.

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 6 May 2005 09:38:06 +0100

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 Santesson
Program Manager, Standards Liaison
Windows Security
 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of David A. Cooper
> Sent: den 4 maj 2005 21:20
> To: Stephen Henson
> Cc: pkix
> Subject: Re: RFC3280bis: policy processing.
> 
> 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: Dr Stephen Henson <[email-masked]>
Date: Fri, 06 May 2005 13:56:05 +0100

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

I believe this is the same issue (albeit from a different direction) I
queried before in this thread on 22 November last year.

Steve.

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 06 May 2005 08:52:56 -0400

>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