Re: DPD & DPV requirements

[Steve Hanna <steve.hanna@xxxxxxx>]

I would like to second Steve Kent's comments against associating name
constraints with trust anchors. We need to balance flexibility and
complexity here, I believe.

Most users never tweak their trust anchors. They don't even know what a
trust anchor is. In most cases where trust anchors are modified from the
default, the set of trust anchors is configured by an administrator. For
the administrator who wants to configure a partially trusted CA (with
name constraints), the simplest and best solution is for the
administrator to establish his own CA, issue a cross-certificate to the 
partially trusted CA (with name constraints), and configure the
administrator's CA as the trust anchor. This allows the administrator to
modify the set of trusted CAs and the limits placed on that trust ad
infinitum without requiring the application's trust anchors to be
reconfigured (which is often painful).

Associating name constraints with trust anchors adds needless complexity
to application code and user interface. Added complexity increases the
likelihood of bugs and security holes. And this is a slippery slope.
Today, we want name constraints with each trust anchor. Tomorrow, policy
constraints. Then policy mapping. Imagine the user interface for that.
We already have a format for expressing these constraints. It's called a
cross-certificate. Let's not reinvent the wheel.

-Steve

Stephen Kent wrote:
> >[Steve]
> >
> >Self-signed certs are not the only way to deal with multiple roots, and it
> >often seems to me that they are a poor way, when we want to make use of
> >features like naming constraints. Why not just have cross certs issued to
> >other "roots" by a local CA and embed the naming (and policy?) constraints
> >into those cross certs?
> >
> >
> >[Denis]
> >
> >This would be quite an artificial way to do this, and more complex than
> >simply adding the elements to define the policy and naming constraints. The
> >proposal is simply to define the policy constraints and the name
> >constraints. Take a look at the document being progressed in the S/MIME WG
> >which defines a validation policy format for non repudiation: Electronic
> >Signature Policies <draft-ietf-smime-espolicies>
> 
> I don't think of it as artificial at all. Cross certification is a
> standard way to create links between PKIs, and to express constraints
> on these links. It has the advantage that path validation can be
> applied uniformly rather than having to treat each trust point
> specially, associating name and policy constraints etc. via special
> means. But, I'm not hard over on this.