Re: WG Last Call: Son-of-2459

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Steve (Hanna),

 ... using a response from David A. Cooper.

I think that we can all agree with the following (posted by David A.
Cooper):

>>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.
 
[David A. Coooper]

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.

[Denis]

In your first reply, you said:" Including name constraints in a self-issued
certificate is pretty unusual (and not likely to be very effective). "

I fully agree with you. Name constraints, when used, should be defined
outside the self-signed certificate. 

Then you add: " In general, I suggest finding a trusted CA (or a small
number) and having them issue cross certificates (with name constraints and
any other fancy stuff). This avoids the problem of having many trust anchors
with various name constraints, which must be replaced manually if the
constraints change (due to marketing, mergers, etc.)."

I am a little bit puzzled with your suggestion. Usually a given application
trusts an anchor to isssue names for some organizations. But another
application may chooose to apply different rules. So this is not a pure
decision from the CA, otherwise the application would have to evaluate these
name constraints before accepting them. 

So I have difficulties to see how the original name contraints could be
handled by using the cross certificates you mention. Whatever, this seems to
be only a suggestion. :-)

Denis
 
> Dave