Re: WG Last Call: Son-of-2459

[Steve Hanna <steve.hanna@xxxxxxx>]

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