Re: WG Last Call: Son-of-2459

["David A. Cooper" <david.cooper@xxxxxxxx>]

At 05:34 PM 3/2/01 -0500, Steve Hanna wrote:
>I certainly don't mind if son-of-2459 says implementations MAY support
>name constraints on trust anchors. I just don't want to have it as a
>SHOULD or a MUST.

I would certainly agree with this. I like the idea of adding initial name constraints values as input to the path validation algorithm, since otherwise they would be the only state variables whose initial values can not be set by the relying party. However, this should in no way be a SHOULD or a MUST.

Section 6.1.1 specifies several inputs to the path validation algorithm and then describes the results of path validation as a function of these inputs. I don't think there is anything in section 6 that states that all of these inputs must be user configurable. If the text does suggest otherwise, then it should be changed.

For example, one of the inputs is "the time, T, for which the validity of the path should be determined." I think it would be perfectly valid for an implementation not accept this input, but instead to always determine the validity of the path at the current time. Similarly, an implementation could choose to "hard-code in" the values for initial-policy-mapping-inhibit, initial-explicit-policy, and initial-any-policy-inhibit. So, even if son-of-2459 adds the adds initial name constraints as an input, there would be no requirement for implementations to allow for inputs other than "all permitted, none excluded". Changing section 6.1.1 would only provide a new option, not impose a new requirement.

Dave