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