Subject: Re: RFC 3280 valid_policy_tree clarification sought

From: "David A. Cooper" <[email-masked]>
Date: Thu, 15 May 2008 16:03:34 -0400

Nelson,

The successor to RFC 3280, RFC 5280 has been published, but I do not 
believe that it includes any changes that would be relevant to this 
discussion.

The intention of section 6.1.5, step (g) was for the valid_policy_tree 
to be modified to be the result of computing the intersection.  While 
the wording could have been better, I believe that this is how step (g) 
works.  For the cases covered by steps (i) and (ii), creating the 
intersection of the valid_policy_tree and the user-initial-policy-set 
does not modify the valid_policy_tree.  So, sentences could have been 
added to the ends of steps (i) and (ii) stating:  "So, no changes need 
to be made to the valid_policy_tree."  In step (g)(iii), nodes in the 
valid_policy_tree that are not in the intersection with the 
user-initial-policy-set are deleted from the valid_policy_tree.

In RFC 3280 (and RFC 5280), the decision to output only the intersection 
was based on the assumption that a user specifying a value for 
user-initial-policy-set other than any-policy intends for the 
user-initial-policy-set to be interpreted as a requirement and not just 
a set of preferred policies, in which case the user would have no 
interest in policies that are not in the user-initial-policy-set.  A 
user who would be willing to consider other policies could just always 
set user-initial-policy-set to any-policy, and then do some 
post-processing on the output to determine whether the path was valid 
for any of the "preferred" policies.  In the case of a browser, I would 
guess that it would rarely make sense to use a value for 
user-initial-policy-set other than any-policy.  I would guess that 
user-initial-policy-set would only be set to something other than 
any-policy in the case of a server performing client-side authentication 
or an enterprise application that was configured by an administrator 
base on predetermined requirements for the application.  In either case, 
accepting a path that was not valid for any of the policies in the 
user-initial-policy-set would not be an option.

There is no requirement, however, to not output the "unmodified" 
valid_policy_tree.  The algorithm in clause 10 of X.509 outputs both the 
valid_policy_tree as it exists before intersection with the 
user-initial-policy-set (what X.509 calls the 
authorities-constrained-policy-set) and the intersection of the 
valid_policy_tree with the user-initial-policy-set (what X.509 calls the 
user-constrained-policy-set).  As with RFC 5280, X.509 states that the 
path is invalid if explicit_policy is zero and 
user-constrained-policy-set is empty.  However, X.509 adds the following 
note: "If the failure is due to an empty user-constrained-policy-set, 
then the path is valid under the authority-constrained policy(s), but 
none is acceptable to the user."

Dave

Nelson B Bolyard wrote:
> Dear RFC 3280 authors and correspondents:
>
> You and I corresponded in June of 2006 about differing interpretations
> of RFC 3280's statement "in general it will be a DirectoryString", and
> your answers were most enlightening.  I thank you all again for your
> help with that.
>
> Now, once again, it seems that different implementers of the RFCs are
> having interoperability problems due to different understandings of the
> RFCS concerning certificates.  The issues this time concern RFC 3280
> and RFC 2560 (OCSP).  I hope you can clarify the issues with RFC 3280.
>
> The RFC 3280 issue this time is simpler to describe than last time,
> thankfully.
>
> A large portion of the algorithm defined in RFC 3280 section 6.1 has to
> do with computing the valid_policy_tree and the value of the 
> explicit_policy
> variable.  The valid_policy_tree appears to have been
> completely computed by the time that the "Wrap-up procedure" of section
> 6.1.5 has begun.  The last step that modifies the valid_policy_tree 
> appears
> to be step (b)(2)(ii) in section 6.1.4 on page 76.  The explicit_policy
> variable appears to have been finally determined by the end of step 
> (b) in
> the "Wrap-up procedure" of section 6.1.5.
>
> Then, in section 6.1.5 on page 78, step g explains how to "Calculate the
> intersection of the valid_policy_tree and the user-initial-policy-set".
> But nowhere does it say what that intersection is used for, and 
> nowhere does
> it say that the valid_policy_tree is to be replaced with that 
> intersection.
>  Nowhere does section 6.1.5 explicitly modify the valid_policy_tree.  
> After
> step g, where the intersection has been computed,
> the last paragraph of section 6.1.5 says the final determination of
> success is made based on two values:
>   (1) the value of explicit_policy variable is greater than zero, or
>   (2) the valid_policy_tree is not NULL.
> Neither of these factors mentions the intersection computed in step g.
>
> Likewise, section 6.1.6 "Outputs", says the outputs include, among 
> others,
> the "final value of the valid_policy_tree".  It does not mention the
> intersection, and (again) nowhere has the RFC said to replace the
> valid_policy_tree with that intersection.
>
> Most implementers seem to agree that the decision at the end of section
> 6.1.5 was intended to be made based on the intersection, rather than on
> the valid_policy_tree as it exists at the beginning of step 6.1.5.
> A few say that the RFCs must be interpreted very literally (a position
> that I cannot dispute based on much experience), and that the decision
> must be made on the policy tree, not the intersection of step g.
>
> The larger dispute is over the outputs.  There seem to be a number of
> reasonable arguments for the output being the full tree, as it exists
> at the beginning of section 6.1.5, rather than the intersection
> computed in step 6.1.5(g).  One of those arguments is that the full
> tree tells us what all the possible valid policies would have been,
> so that the user of the algorithm can look for other policies among
> those results for one that might be alternately acceptable.  This is
> very appealing for browsers.
>
> One consequence of the interpretation that the output is the full tree
> is that it obviates the computation of the intersection completely, when
> the value of explicit_policy variable is greater than zero at the end of
> step 6.1.5(b)(2)(ii).  If we know, at the end of step 6.1.5(b)(2)(ii)
> that the path processing has succeeded because the value of 
> explicit_policy
> variable is greater than zero, and if the intersection is not the output,
> then there is no need to compute the intersection.
>
> I hope you can clarify these matters.  Perhaps the next RFC successor
> to RFC 3280 can clarify these things.  Ideally I'd like to have a
> message that I can forward to individuals involved.  I look forward to
> your thoughtful words on this subject.
>
> /Nelson Bolyard
> SSL developer for Mozilla browsers
>