[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: WG Last Call: Son-of-2459



Steve,

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!

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.


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).

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


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.

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.


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.

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