Subject: Re: WG Last Call: Son-of-2459

From: Stephen Kent <[email-masked]>
Date: Fri, 2 Mar 2001 16:39:26 -0500

Steve,

I agree with most of the comments you have made re revisions to 2459, 
but I do disagree with the discussion if name constraints and its use 
in the validation algorithm.  I think that name constraints are 
critically important in PKIs that make extensive use of cross 
certification. Yet, as you note, they are no commonly used so far. I 
think that making provision to associate name constraints with trust 
anchors is a good way to let users (or administrators) locally manage 
the concerns that this extension addresses, without having to 
persuade CAs to issue cross certs with such constraints.  In fact, I 
was persuaded to drop my proposal for local issuance of such cross 
certs because of the inclusion of this facility as a control measure 
on the validation process.

This will become more than a local implementation issue, as we 
continue with the DPV/DPD work.  My current draft of the message 
syntax for requests calls for inclusion of name constraints as a 
validation control parameter, a protocol feature motivated by the 
notion that name constraints would become a standard part of the 
validation algorithm.

Steve

---

From: Steve Hanna <[email-masked]>
Date: Fri, 02 Mar 2001 17:34:54 -0500

Steve,

I certainly agree with you that name constraints (along with policy
constraints) are critically important in PKIs that make extensive use of
cross certification. The U.S. Government's Federal Bridge CA (currently
in a pilot stage) includes name constraints in cross certificates that
it issues and I expect that CAs will do this more frequently as cross
certification increases.

However, I don't agree that it's important to let end-users associate
name constraints with trust anchors. Few end-users even understand what
a trust anchor is. The number of end-users that could properly assign
name constraints to each trust anchor is much smaller, still. When I
talk with browser vendors, they say that PKI must become simpler, not
harder!

A better and more practical way to achieve the same end is for the
end-user to have a single trust anchor (the corporate or departmental
CA) and have that CA issue cross-certificates with name constraints.
This allows the administrator to manage all the name constraints (as
well as policy mappings and other policy constraints, which may be
necessary in a cross-certification environment).

If the user is really paranoid, they can set up their own CA and use
that as their trust anchor. Anyone sophisticated enough to configure
name constraints is sophisticated enough to run their own CA. And there
are plenty of free CA software packages out there that are perfectly
adequate for issuing a few cross-certificates with name constraints.

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.

-Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 2 Mar 2001 18:04:15 -0500

Steve,

>talk with browser vendors, they say that PKI must become simpler, not

Bwoeser vendors have a very poor track record re offering appropriate 
controls for user management of certs, and the complete lack of 
management knobs for trust anchors is appalling. I understand the 
motivation here, I think that's one reason why we see such interest 
in DPV, but, as I note in the last paragraph, providing a control 
that's not invoked by most users need not make their lives more 
complex.  As a Mac user, I see a fair number of software modules that 
have novice user controls, but with (slightly hidden) advanced user 
controls as well.

>necessary in a cross-certification environment).

I like that approach too, and said as much a while ago, but was 
talked out of it.

>adequate for issuing a few cross-certificates with name constraints.

It's a big step to go from managing name constraints for a few trust 
anchors to becoming one's own CA in order to manage these validation 
parameters, but I agree that in some cases one might do this.

>name constraints on trust anchors. I just don't want to have it as a

If one mandates such support in products, but users choose not to 
make use of it, then their lives are unaffected. It's the vendors who 
have to do more work, but is that extra work significant relative to 
the rest of the cert processing implementation? I'm not convinced 
that it is.

Steve

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 02 Mar 2001 18:09:57 -0500

>name constraints on trust anchors. I just don't want to have it as a

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

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 05 Mar 2001 18:04:31 +0100

Steve (Hanna),

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

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

>>name constraints on trust anchors. I just don't want to have it as a
 
[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

---

From: Polar Humenn <[email-masked]>
Date: Mon, 5 Mar 2001 12:46:38 -0500 (EST)

Below Steve Hanna writes about associating name constraints with "trust
anchors" as a bad idea, and that it should be done the "proper" way by
having your departmental CA producing cross certs. Wouldn't that require
every ordinary internet user with a browser to set up their own CA?

My next question is "what is a trust anchor?"

I thought we were talking about "validation". "Trust" is a COMPLETELY
different matter. I know it's pedantic, but should such a thing be called
a validation anchor, or validity anchor. I don't associate certificate
validation with trust. I validate first, then make a trust decision.

Many browsers come fully stocked with CA certs, which is a good thing,
because there is no general way to locate one if you needed to. My trust
policy is much different than my validation policy. Removing CA certs from
the "validators" may be a way to provide a trust decision, but it should
be construed to be the only way.

Cheers,
-Polar

> > notion that name constraints would become a standard part of the

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[email-masked]       2-212 CST      
Phone: 315-443-3171           Syracuse, NY 13244-4100
Fax:   315-443-4745           http://www.adiron.com