[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Recommended changes to draft-ietf-pkix-new-part1-08
Dave,
Thank you for the answers (and also to the other question I'd
had on "any-policy"), they are of enormous help. Excellent
artwork, too!
Jeff
"David A. Cooper" wrote:
>
> At 03:12 PM 8/21/01 -0700, Jeff Jacoby wrote:
>
> Section 6.1.4 Preperation for certificate i+1, step (b)(1). the
> second paragraph reads:
>
> "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 any-policy, then generate a child node of the
> node of depth i-1 that has a valid_policy of any-policy as
> follows:"
>
> Should it really be:
>
> "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-1 with a
> valid_policy of any-policy, then generate a child node of the
> node of depth i-1 that has a valid_policy of any-policy as
> follows:"
>
> (note the difference in the first sentence, "i" vs "i-1"). Afterall,
> the last sentence implies there must be a node of depth i-1 with a
> valid_policy of any-policy.
>
> Actually, I believe that the original text was correct. To see why,
> consider the following two examples:
>
> In the first example, the first certificate in the path contains the
> following policy extensions:
>
> certificatePolicies = {anyPolicy, a}
> policyMappings = {a --> c, b --> d}
>
> After carrying out the steps in section 6.1.3, the valid_policy_tree,
> excluding the qualifier_set and criticality_indicator fields, would be
> (NOTE: this is best viewed with a fixed-width font):
>
> +----------------+
> | any-policy | <---- valid_policy
> +----------------+
> | any-policy | <---- expected_policy_set
> +----------------+
> / \
> / \
> +----------------+ +----------------+
> | any-policy | | a | <---- valid_policy
> +----------------+ +----------------+
> | any-policy | | {a} | <----
> expected_policy_set
> +----------------+ +----------------+
>
> After the policy mappings extension is processed, the result is:
>
> +----------------+
> | any-policy | <---- valid_policy
> +----------------+
> | any-policy | <---- expected_policy_set
> +----------------+
> / | \
> / | \
> +----------------+ +----------------+ +----------------+
> | any-policy | | b | | a | <----
> valid_policy
> +----------------+ +----------------+ +----------------+
> | any-policy | | {d} | | {c} | <----
> expected_policy_set
> +----------------+ +----------------+ +----------------+
>
> In this case, the result would be the same whether the current text or
> the proposed text were used. Note that, by construction, if there is a
> node of depth i with valid_policy any-policy, there must also be a node
> of depth i-1 with valid_policy any-policy.
>
> The second example shows a case in which the two algorithms differ. In
> this case, the first certificate in the path contains the following
> policy extensions:
>
> certificatePolicies = {a}
> policyMappings = {a --> c, b --> d}
>
> +----------------+
> | any-policy | <---- valid_policy
> +----------------+
> | any-policy | <---- expected_policy_set
> +----------------+
> |
> |
> +----------------+
> | a | <---- valid_policy
> +----------------+
> | {a} | <---- expected_policy_set
> +----------------+
>
> When the policy mappings extension is processed, the expected_policy_set
> for the node at depth 1 is changed from {a} to {c}. Since there is no
> node of depth 1 with a valid_policy of any-policy, the mapping from b to
> d is ignored. The result is:
>
> +----------------+
> | any-policy | <---- valid_policy
> +----------------+
> | any-policy | <---- expected_policy_set
> +----------------+
> |
> |
> +----------------+
> | a | <---- valid_policy
> +----------------+
> | {c} | <---- expected_policy_set
> +----------------+
>
> If the proposed text were followed, a node of depth i with a
> valid_policy of b and expected_policy_set of {d} would be created.
> However, this would make it appear as if b appeared in the
> certificatePolicies extension. In the first example, this was OK since
> b was implicitly included in the certificatePolicies extension through
> the inclusion of anyPolicy. In the second example, however, b was
> neither explicitly nor implicitly included in the certificatePolicies
> extension. So, in the second example, b should not appear as the
> valid_policy in any node of depth i.
>
> So, in effect, the phrase "if ... there is a node of depth i with a
> valid_policy of any-policy" is checking to see if anyPolicy was included
> in the certificatePolicies extension. If so, then the issuing domain
> policy ID-P was implicitly included in the certificatePolicies extension
> and the mapping from the issuing domain policy to the subject domain
> policy can be included in the valid_policy tree just as if the issuing
> domain policy had been explicitly included in the certificatePolicies
> extension. If neither the issuing domain policy nor anyPolicy was
> included in the certificatePolicies extension, then the mapping should
> be ignored.
>
> Second issue is a simple typo. The very last sentence in section 6.1.4
> reads:
>
> "If (a), (k), (l), (n) and (o) have completed successfully, increment
> i and perform the basic certificate processing specified in 6.1.2."
>
> it should be:
>
> "If (a), (k), (l), (n) and (o) have completed successfully, increment
> i and perform the basic certificate processing specified in 6.1.3."
>
> (6.1.2 is Initialization)
>
> Good catch.
>
> Finally, in the wrap-up description, section 6.1.5 step (g)(iii) 1.
> reads:
>
> "1. Determine the set of policy nodes whose ancestor nodes
> have a valid_policy of any-policy. This is the
> valid_policy_node_set."
>
> Since the root node (depth 0) has valid_policy of any-policy, and it is
> an ancestor to every node in the tree, this would seem to mean (to me)
> the whole tree is in the valid_policy_node_set. Or does "ancestor node"
> mean something different?
>
> I believe that "ancestor" should be replaced by "parent". The idea is
> to compare policies from the user-initial-policy-set to policies in the
> valid_policy_tree that came from the domain of the relying party. Thus,
> we must look at nodes in the valid_policy_tree as close to the root as
> possible, before any policy mappings have taken place. If a node's
> parent has a valid_policy of any-policy, then no policy mappings could
> have been performed in any of that node's ancestors (i.e., in each of
> the node's ancestors, the expected_policy_set and the valid_policy are
> both any-policy) and so it is reasonable to check whether that node's
> valid_policy appears in the user-initial-policy-set. If a node's parent
> vald_policy other than any-policy then either a policy mapping has
> occurred (in which case the node's valid_policy should not be compared
> to the user-initial-policy-set) or no mapping has occurred (in which
> case one or more of the node's ancestors contains the same valid_policy,
> and one of those ancestor nodes will be compared against the
> user-initial-policy-set).
>
> Dave
--
Jeff Jacoby, Sr. Programmer
RSA Security Inc., SMDC jjacoby@xxxxxxxxxxxxxxx
2755 Campus Dr., Ste. 300 (650) 295-7569
San Mateo, CA 94403