Subject: RFC3280bis: policy processing.

From: Stephen Henson <[email-masked]>
Date: Thu, 18 Nov 2004 13:15:38 +0000

While implementing policy processing for OpenSSL a couple of issues
arose in RFC3280 6.1.3:

1. The OID-P typo which has already been mentioned.

2. In order for the valid_policy_tree to be a "tree" some additional
conditions were required. Specifically:

a. The same OID cannot occur multiple times in the same certificate
policyIdentifier field of a Certificate Policies extension.
b. The same OID cannot occur multiple times in the subjectDomainPolicy
of the Policy Mappings extensions.

[The same OID can occur in issuerDomainPolicy: indeed that's the only
way the top node of Fig 4 could be produced.]

3. The use of the phrase "for each" in 6.1.4 b(1) implied to me that
there could me more than one node in the policy tree of depth i where
ID-P is the valid policy whereas there can be at most one. If condition
#2a above is valid there can be at most one.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 18 Nov 2004 15:04:31 -0500

Stephen Henson wrote:

While
implementing policy processing for OpenSSL a couple of issues

arose in RFC3280 6.1.3:

Yes.  The certificatePolicies extension logically contains a set of
certificate policies, referenced by OID.  So, the same OID should not
appear more than once.

b. The same OID
cannot occur multiple times in the subjectDomainPolicy

Actually, the same OID can occur multiple times in the
subjectDomainPolicy.  See below:

Certificate 1:

certificatePolicies:  Red

policyMappings: Red -> Gold, Red -> Silver

Certificate 2:

certificatePolicies:  Gold, Silver

policyMappings: Gold -> Medium, Silver -> Medium

Certificate 3:

certificatePolicies:  Medium

+-----------------+

|      Red        |

+-----------------+

|       {}        |

+-----------------+ node of depth i-2

|      FALSE      |

+-----------------+

|  {Gold, Silver} |

+-----------------+

/           \

/             \

/               \

/                 \

+-----------------+           +-----------------+

|      Gold       |           |     Silver      |

+-----------------+           +-----------------+

|       {}        |           |       {}        |

+-----------------+ nodes of  +-----------------+

|      FALSE      | depth i-1 |
FALSE      |

+-----------------+           +-----------------+

|    {Medium}     |           |    {Medium}
|

+-----------------+           +-----------------+

|                             |

|                             |

|                             |

+-----------------+           +-----------------+

|     Medium      |           |     Medium
|

+-----------------+           +-----------------+

|       {}        |           |       {}        |

+-----------------+ nodes of  +-----------------+

|      FALSE      | depth i   |
FALSE      |

+-----------------+           +-----------------+

|    {Medium}     |           |    {Medium}
|

+-----------------+           +-----------------+

3. The use of
the phrase "for each" in 6.1.4 b(1) implied to me that

Perhaps the problem is with 6.1.3 (d)(1)(i).  Perhaps this step also
needs to state "for each node of depth i-1 where P-OID is in the
expected_policy_set...."  Would that clear up the confusion?

Dave

---

From: Stephen Henson <[email-masked]>
Date: Fri, 19 Nov 2004 00:18:58 +0000

David A. Cooper wrote:
>             |      FALSE      | depth i-1 |      FALSE      |
>             |    {Medium}     |           |    {Medium}     |
>             |     Medium      |           |     Medium      |
>             |      FALSE      | depth i   |      FALSE      |
>             |    {Medium}     |           |    {Medium}     |

Ah, now I'd also assumed that you couldn't have duplicate nodes at the 
same depth. If that's allowed then it changes things...

> expected_policy_set...."  Would that clear up the confusion?

There certainly seems a problem with the wording of either 
6.1.3(d)(1)(i) or 6.1.4 b(1). The current wording of 6.1.3 (d)(1)(i):

>             (i)  If the valid_policy_tree includes a node of depth i-1
>             where P-OID is in the expected_policy_set, create a child
>             node as follows: set the valid_policy to OID-P; set the
>             qualifier_set to P-Q, and set the expected_policy_set to
>             {P-OID}.

could well be interpreted to mean that only one child node is created if 
there's an appropriate node of depth i-1 which would mean you wouldn't 
get the situation in your example above at depth i.

When I looked at this before I also looked at X509 and cross referenced 
the X509 algorithm wording (which uses different structures) to the 
RFC3280 form.

I finally decided that it was 6.1.4(b)(1) that was at fault and 
duplicate nodes weren't permitted but it was late and I was tired when I 
looked at it...

I'll check through my notes to see if I can find the precise sections of 
X509 that lead me to that conclusion.

Steve.

---

From: Stephen Henson <[email-masked]>
Date: Mon, 22 Nov 2004 16:52:04 +0000

Stephen Henson wrote:

> 
> 
> When I looked at this before I also looked at X509 and cross
> referenced the X509 algorithm wording (which uses different
> structures) to the RFC3280 form.
> 
> duplicate nodes weren't permitted but it was late and I was tired
> when I looked at it...
> 
> I'll check through my notes to see if I can find the precise sections
> of X509 that lead me to that conclusion.
> 

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.