Re: WG Last Call: Son-of-2459

[Polar Humenn <polar@xxxxxxxxxx>]

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

On Fri, 2 Mar 2001, Steve Hanna wrote:

> 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
> 
> Stephen Kent wrote:
> > 
> > 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
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:polar@xxxxxxxxxx       2-212 CST      
Phone: 315-443-3171           Syracuse, NY 13244-4100
Fax:   315-443-4745           http://www.adiron.com