Subject: [keyassure] Charter sent to ADs

From: Ondřej Surý <[email-masked]>
Date: Wed, 06 Oct 2010 17:09:58 +0200

Hi all,

since the proposed charter is quite stable for a last week or so with 
small exceptions of small nits, we (me and Warren) believed that the 
charter is good to go and that we have a rough consensus on the charter, 
and so we asked our fellow ADs to process it accordingly to IETF 
processes, ie. take it to the IESG.

With some luck that could mean that we can make it to be WG in the time 
of Beijing meeting.

I would like to thank all the contributors to the charter, so thank you all.

Regards,
Ondrej
-- 
  Ondřej Surý
  vedoucí výzkumu/Head of R&D department
  -------------------------------------------
  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
  Americka 23, 120 00 Praha 2, Czech Republic
  mailto:[email-masked]    http://nic.cz/
  tel:+420.222745110       fax:+420.222745112
  -------------------------------------------

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 08 Oct 2010 10:15:12 +0200

On 6.10.2010 17:09, Ondřej Surý wrote:
> Hi all,
>
> since the proposed charter is quite stable for a last week or so
> with small exceptions of small nits, we (me and Warren) believed that
> the charter is good to go and that we have a rough consensus on the
> charter, and so we asked our fellow ADs to process it accordingly to
> IETF processes, ie. take it to the IESG.
>
> With some luck that could mean that we can make it to be WG in the
> time of Beijing meeting.
>
> Regards, Ondrej

Bill has asked me to post a charter as sent to ADs:

http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure

Here's verbatim copy of that page for an evidence:

Objective:
Specify mechanisms and techniques that allow Internet applications to
establish cryptographically secured communications by using information
distributed through the DNS for discovering and authenticating public
keys which are associated with a service located at a domain name.

Problem Statement:
Entities on the Internet are usually identified using domain names and
forming a cryptographically secured connection to the entity requires
the entity to authenticate its name. For instance, in HTTPS, a server
responding to a query for <https://www.example.com> is expected to
authenticate as "www.example.com". Security protocols such as TLS and
IPsec accomplish this authentication by allowing an endpoint to prove
ownership of a private key whose corresponding public key is somehow
bound to the name being authenticated. As a pre-requisite for
authentication, then, these protocols require a mechanism for bindings
to be asserted between public keys and domain names.

DNSSEC provides a mechanism for a domain operator to sign DNS
information directly, using keys that are bound to the domain by the
parent domain; relying parties can continue this chain up to any trust
anchor that they accept. In this way, bindings of keys to domains are
asserted not by external entities, but by the entities that operate the
DNS. In addition, this technique inherently limits the scope of any
given entity to the names in zones he controls.

This working group will develop mechanisms for domain operators to
present bindings between names within their control and public keys, in
such a way that these bindings can be integrity-protected (and thus
shown to be authentically from the domain operator) using DNSSEC and
used as a basis for authentication in protocols that use domain names as
identifiers. Possible starting points for these deliverables include
draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, and
draft-josefsson-keyassure-tls.

The mechanisms developed by this group will address bindings between
domain names and keys, allowing flexibility for all key-transport
mechanisms supported by the application protocols addressed (e.g., both
self-signed and CA-issued certificates for use in TLS).

The group may also create documents that describe how protocol entities
can discover and validate these bindings in the execution of specific
applications. This work would be done in coordination with the IETF
Working Groups responsible for the protocols.

Milestones:
Nov 2010   First WG draft of standards-track protocol for using DNS to
associate hosts with keys for TLS and DTLS
Jan 2011   First WG draft of standards-track protocols for using DNS to
associate hosts with IPsec
Jun 2011   Protocol for using DNS to associate domain names with keys
for TLS and DTLS to IESG
Aug 2011   Protocols for using DNS to associate domain names with keys
for IPsec to IESG
Aug 2011   Recharter

O.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 8 Oct 2010 10:26:17 -0400

As I pointed out to Ondrej offlist,

A WG meeting has a minimum notice period that is constrained by legal
considerations, visa issue requirements and a whole host of travel planning
issues.

If the group is chartered before Beijing it cannot have a BOF and it cannot
have a WG meeting either.

So sending the charter to the ADs in advance of the meeting is probably a
mistake.

The BOF is an opportunity to advertise the work to the wider IETF community.
It is your single best advertising and marketing opportunity.

The charter milestones are completely unrealistic.

Time and again I see WG charters propose unrealistic milestones that are
then used to constrain the discussion on the basis that there is no time to
consider other options.

The result is inevitably that the WG takes far longer than it would have
done had the milestones been realistic.

We can come to agreement almost immediately on a proposal to use the DNS to
validate keys. The tricky part is how to use DNS to constrain key validity.

So far the group has only discussed one mechanism that is designed to
constrain key validity after issue. But that is not the only option, a much
more powerful and lower impact approach is to provide mechanisms that enable
domain name owners to avoid mis-issue.

There is really no need or point to scheduling milestones for submission of
initial drafts. The charter states that there are input drafts, that is
enough.

As far as work schedules go, I think it is realistic to have a draft ready
for IESG review that describes a mechanism for key validation and for
publishing 'do not issue' advice to CAs by March. Describing a mechanism for
client side enforcement is a lot more involved and necessitates
consideration of lots of application details. So November 2011 is
optimistic.

The Shepherding process for turning drafts into standards always takes much
longer than everyone expects, even people who have done something before.

Rushing a proposal through a WG only makes the process take a lot longer
with much less control.  Issues that could have been disposed of quickly end
up taking much longer as the IESG raises them and takes much longer to
dispose of them because they are overloaded.

On Fri, Oct 8, 2010 at 4:15 AM, Ondřej Surý <[email-masked]> wrote:

> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

-- 
Website: http://hallambaker.com/

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 8 Oct 2010 11:58:00 -0400

> So far the group has only discussed one mechanism that is designed  
> to constrain key validity after issue. But that is not the only  
> option, a much more powerful and lower impact approach is to provide  
> mechanisms that enable domain name owners to avoid mis-issue.

  ...

> As far as work schedules go, I think it is realistic to have a draft  
> ready for IESG review that describes a mechanism for key validation  
> and for publishing 'do not issue' advice to CAs by March.

I do not understand what you mean by "avoid mis-issue" or "publishing  
'do not issue' advice to CAs".  Those phrases doesn't sound like any  
problem that had been discussed previously on this list.

--Richard

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 8 Oct 2010 09:19:29 -0700

At 11:58 AM -0400 10/8/10, Richard L. Barnes wrote:
>>So far the group has only discussed one mechanism that is designed to constrain key validity after issue. But that is not the only option, a much more powerful and lower impact approach is to provide mechanisms that enable domain name owners to avoid mis-issue.
>
> ...
>
>>As far as work schedules go, I think it is realistic to have a draft ready for IESG review that describes a mechanism for key validation and for publishing 'do not issue' advice to CAs by March.
>
>I do not understand what you mean by "avoid mis-issue" or "publishing 'do not issue' advice to CAs".  Those phrases doesn't sound like any problem that had been discussed previously on this list.

+1. These sound like topics for a different proposed Working Group, not one focused on associating a key with a host name.

--Paul Hoffman, Director
--VPN Consortium

---

From: Ben Laurie <[email-masked]>
Date: Fri, 8 Oct 2010 17:33:44 +0100

> +1. These sound like topics for a different proposed Working Group, not one focused on associating a key with a host name.

Agreed.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 8 Oct 2010 12:53:24 -0400

On Fri, Oct 8, 2010 at 11:58 AM, Richard L. Barnes <[email-masked]> wrote:

>> publishing 'do not issue' advice to CAs by March.
>>
>
> I do not understand what you mean by "avoid mis-issue" or "publishing 'do
> not issue' advice to CAs".  Those phrases doesn't sound like any problem
> that had been discussed previously on this list.

Which is a real problem because that is exactly what the code we are
discussing is designed to prevent.

And I am not at all surprised that you were unaware that this was an
objective as it is not something that I would have expected to be an
objective either and have only discovered gradually.

Let us rewind back to the Black Hat 2010 conference.

At BH, Dan Kaminsky presented a paper where he identified the lack of
standards for issuing DV certificates as a problem and suggested an
alternative scheme based on DNSSEC which would have two purposes:

1) Enable a domain name owner to validate keys at the DV level
2) Enable a domain name owner to prevent clients that support the proposed
mechanism from trusting certificates that they did not authorize.

I did not attend BH this year and so when I saw the group formed I assumed
that the only requirement it was intended to address was the first one.

This week I have spoken to or otherwise communicated to several of the draft
authors offlist. I have confirmed with them that the purpose of enabling a
domain name owner to prevent use of the certificates is indeed one of their
principal objectives.

Now if you want to rule the second purpose out of the charter, that is fine
with me. But the fact remains that the technical complexity of putting any
form of restriction in the client is vastly greater than the complexity of a
mandate that is imposed on the issuing CAs.

Whether or not this group wishes to be a part of the 'do not issue'
approach, it is a simpler approach and one that offers benefits to both CAs
and to the users of legacy browsers and browsers that choose not to deploy
an enumeration based restriction scheme. And while it can make use of
DNSSEC, it is not dependent on DNSSEC deployment.

I would see the forum for addressing do-not-issue to be CABForum more than
IETF.

The reason it is relevant here is because it bears on the same original
requirement and may well pre-empt it to an extent. It is not possible to use
the enumeration approach as the basis of do-not-issue for obvious reasons
(can't take the hash of a cert before it is issued).

So there is going to be do-not-issue information in the DNS that can
potentially be applied to solve this problem equally well and with a far
lower maintenance requirement than this particular scheme.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 8 Oct 2010 13:07:31 -0400

> approach, it is a simpler approach and one that offers benefits to  
> both CAs and to the users of legacy browsers and browsers that  
> choose not to deploy an enumeration based restriction scheme. And  
> while it can make use of DNSSEC, it is not dependent on DNSSEC  
> deployment.

The "do not issue" approach is entirely orthogonal to the point of  
this group.  It assumes that commercial CAs are still the entities  
asserting the name-key binding.

The point of this group is to enable the assertion of name-key  
bindings using DNSSEC, so that the domain owner, rather than an  
external CA, is the entity asserting the binding.

As a side note, objective (2) as you've phrased it is non-sensical.   
Domain owners cannot prevent clients from accepting any certificate.   
The only thing a domain owner can do is make assertions about what  
their servers will do, which the client can use to make validation  
decisions.  Discussion to date has focused on positive assertions like  
"My servers will use this key:...", but one could imagine negative  
assertions as well, of the character "My servers will not use any  
other keys."  As I read it, the current charter allows both of these.   
(And whoever you talked to off-list, I'm imagining that's more like  
what they had in mind than a "do-not-issue" approach.)

--Richard

---

From: Tony Finch <[email-masked]>
Date: Fri, 8 Oct 2010 19:41:47 +0100

On 8 Oct 2010, at 18:07, "Richard L. Barnes" <[email-masked]> wrote:

>> Whether or not this group wishes to be a part of the 'do not issue' approach, it is a simpler approach and one that offers benefits to both CAs and to the users of legacy browsers and browsers that choose not to deploy an enumeration based restriction scheme. And while it can make use of DNSSEC, it is not dependent on DNSSEC deployment.
> 
> The "do not issue" approach is entirely orthogonal to the point of this group.  It assumes that commercial CAs are still the entities asserting the name-key binding.
> 
> The point of this group is to enable the assertion of name-key bindings using DNSSEC, so that the domain owner, rather than an external CA, is the entity asserting the binding.

The two are not mutually incompatible. The authorized CA identified in the DNS can be a private CA (which also deals with the many-certs problem that Phill identified) and in the simplest case it should also be possible to identify the server's cert directly.

Tony.
--
f.anthony.n.finch  <[email-masked]>  http://dotat.at/

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 8 Oct 2010 15:32:06 -0400

>>> Whether or not this group wishes to be a part of the 'do not  
>>> issue' approach, it is a simpler approach and one that offers  
>>> benefits to both CAs and to the users of legacy browsers and  
>>> browsers that choose not to deploy an enumeration based  
>>> restriction scheme. And while it can make use of DNSSEC, it is not  
>>> dependent on DNSSEC deployment.
>>
> The two are not mutually incompatible. The authorized CA identified  
> in the DNS can be a private CA (which also deals with the many-certs  
> problem that Phill identified) and in the simplest case it should  
> also be possible to identify the server's cert directly.

Certainly agree that putting CA certs in the DNS could be a useful  
approach.  It's not the same as a "do not issue" warning.

--Richard

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 9 Oct 2010 00:20:32 +0300

On Fri, Oct 08, 2010 at 03:32:06PM -0400, Richard L. Barnes wrote:
> >
> >The two are not mutually incompatible. The authorized CA
> >identified in the DNS can be a private CA (which also deals with
> >the many-certs problem that Phill identified) and in the simplest
> >case it should also be possible to identify the server's cert
> >directly.
> 

Furthermore, bad enough CAs could just ignore the "do not issue"
warnings (for instance if coerced). 

Here's (another) way to do that:

TLSCFP (Transport Layer Security Chaining FingerPrint) record.

These come to play if no matching TLSFP record (eithe direct or
indirect via TLSRQ) is found but usable TLSCFP records are present.

The client will then collect all available (local store and server-
sent) certificates that match fingerprints in TLSCFP records and
runs normal PKI validation with collected certificates notionally
declared to be trust anchors.

If this check passes, the key is OK from DNS key checking POV. The
client may or may not trust it at this point (depending on client
local policy).

If this check fails, the whole DNS key checking fails and client
SHOULD NOT trust the certificate.

The reason for excluding certs that match TLSFPs is that one can't
attack those using bad-CA attacks anyway (since that certificate
can't be used without server key, legimate server sends good
certificate chains and compromising the key would compromise
everything anyway).

-Ilari

---

From: Tony Finch <[email-masked]>
Date: Sun, 10 Oct 2010 23:55:13 +0100

On 8 Oct 2010, at 20:32, "Richard L. Barnes" <[email-masked]> wrote:
> 
> Certainly agree that putting CA certs in the DNS could be a useful approach.  It's not the same as a "do not issue" warning.

Phill's proposal said that clients could check the server's cert chain against the list of allowed CAs in the DNS. The CA issuing rules help for old clients, and provide defence in depth.

Tony.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 10 Oct 2010 23:18:51 -0400

One scheme can certainly do both.

But changing CA practices when there is a dramatic and immediate advantage
to the CA is much easier than working out 'fire and forget' rules for client
side processing and getting them agreed amongst the various IETF groups
affected.

I tend to think that the proper procedure on this concept would be to have
the IETF assign the RR code but hand as much work as possible on the
practices side to the CABForum where there are lawyers who like writing
rules for that sort of thing.

I certainly want to do client side rules. But realistically we only get one
chance to do those right.

On Sun, Oct 10, 2010 at 6:55 PM, Tony Finch <[email-masked]> wrote:

> Phill's proposal said that clients could check the server's cert chain
> against the list of allowed CAs in the DNS. The CA issuing rules help for
> old clients, and provide defence in depth.
>
> Tony.
> --

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 11 Oct 2010 08:14:56 +0300

> side processing and getting them agreed amongst the various IETF groups

The only three (present or near term future) ones that spring to mind are:
- HASMAT
- PKIX
- Keyassure (this group)

(I didn't put TLS on that list because authentication issues are AFAIK
outside its scope).

Also, "do not issue" advisories are not enough against rogue (or just plain
careless[*]!) CAs. Against those you need genuine chaining restrictions or
exhaustive end-server cert enumeration.

[*] Remember, X.509 is only as strong as weakest acceptable CA.

-Ilari

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 11 Oct 2010 09:18:18 +0200

Phillip,

We spoke to ADs before we sent the charter, and we sent the charter to 
them upon their request (after we ironed out few flaws we had in the 
charter).  And I am quite sure that if such a danger existed, the ADs 
would point that out.

Also we have a recent precedent - the websec WG (former HASMAT) was 
recently approved[1] and it has requested BoF before it was approved for 
Beijing[2].

O.
Links:
1. http://www.ietf.org/mail-archive/web/hasmat/current/msg00123.html
2. http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#Applications

On 8.10.2010 16:26, Phillip Hallam-Baker wrote:
> considerations, visa issue requirements and a whole host of travel
> planning issues.
>
> If the group is chartered before Beijing it cannot have a BOF and it
> cannot have a WG meeting either.
>
> So sending the charter to the ADs in advance of the meeting is probably
> a mistake.
>
> The BOF is an opportunity to advertise the work to the wider IETF
> community. It is your single best advertising and marketing opportunity.
>
>
> then used to constrain the discussion on the basis that there is no time
> to consider other options.
>
> We can come to agreement almost immediately on a proposal to use the DNS
> to validate keys. The tricky part is how to use DNS to constrain key
> validity.
>
> constrain key validity after issue. But that is not the only option, a
> much more powerful and lower impact approach is to provide mechanisms
> that enable domain name owners to avoid mis-issue.
>
> There is really no need or point to scheduling milestones for submission
> of initial drafts. The charter states that there are input drafts, that
> is enough.
>
> ready for IESG review that describes a mechanism for key validation and
> for publishing 'do not issue' advice to CAs by March. Describing a
> mechanism for client side enforcement is a lot more involved and
> necessitates consideration of lots of application details. So November
> 2011 is optimistic.
>
> The Shepherding process for turning drafts into standards always takes
> much longer than everyone expects, even people who have done something
> before.
>
> with much less control.  Issues that could have been disposed of quickly
> end up taking much longer as the IESG raises them and takes much longer
> to dispose of them because they are overloaded.
>
>
> On Fri, Oct 8, 2010 at 4:15 AM, Ondřej Surý <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     authenticate as "www.example.com <http://www.example.com>". Security
>     protocols such as TLS and
>       mailto:[email-masked] <mailto:[email-masked]> http://nic.cz/
>     [email-masked] <mailto:[email-masked]>

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 11 Oct 2010 09:27:42 +0200

Just to clarify.  This group has nothing to do with Dan Kaminsky and 
it's not based on his work.  Neither his name nor his presentation was 
pointed out neither when we did bar-BoF nor when we started mailing list.

This group was started on basis of work of earlier IETF contributors as 
was Simon Josefsson, Jakob Schlyter and others.[1]  It was merely meant 
as a revival of that work after we started having DNSSEC signed root.

I spoke to different parties and everybody seemed to be working on 
"something like this", and because I didn't want to have divergence on 
the market, I tried to concentrate work done into this place.  (Even 
though I was warned that IETF way is painful and we better keep this 
outside.)

And Phillip, I would really like to see if you can stop obstructing the 
work here by sending tons of emails where you reiterate your ideas again 
and again just because you have entirely different idea what this group 
should be doing.  Your ideas about the work for this to-be-WG is that 
much different that you should create your own WG.  I wouldn't mind. 
But don't try to change this group into something it isn't and was never 
meant to be.

O.
Links:
1. http://www.ietf.org/mail-archive/web/keyassure/current/msg00002.html

On 8.10.2010 18:53, Phillip Hallam-Baker wrote:
> 2) Enable a domain name owner to prevent clients that support the
> proposed mechanism from trusting certificates that they did not authorize.
>
>
> I did not attend BH this year and so when I saw the group formed I
> assumed that the only requirement it was intended to address was the
> first one.
>
> This week I have spoken to or otherwise communicated to several of the
> draft authors offlist. I have confirmed with them that the purpose of
> enabling a domain name owner to prevent use of the certificates is
> indeed one of their principal objectives.
>
>
> Now if you want to rule the second purpose out of the charter, that is
> fine with me. But the fact remains that the technical complexity of
> putting any form of restriction in the client is vastly greater than the
> complexity of a mandate that is imposed on the issuing CAs.
>
> approach, it is a simpler approach and one that offers benefits to both
> CAs and to the users of legacy browsers and browsers that choose not to
> deploy an enumeration based restriction scheme. And while it can make
> use of DNSSEC, it is not dependent on DNSSEC deployment.
>
> I would see the forum for addressing do-not-issue to be CABForum more
> than IETF.
>
> requirement and may well pre-empt it to an extent. It is not possible to
> use the enumeration approach as the basis of do-not-issue for obvious
> reasons (can't take the hash of a cert before it is issued).
>

---

From: Tony Finch <[email-masked]>
Date: Mon, 11 Oct 2010 14:42:27 +0100

On 11 Oct 2010, at 06:14, Ilari Liusvaara <[email-masked]> wrote:
> careless[*]!) CAs. Against those you need genuine chaining restrictions

Phill's proposal includes that.

> or exhaustive end-server cert enumeration.

I think this should not be necessary. If you don't trust your CA to issue
certs to the right people, why are you buying certs from them?

Also I am worried that this requires too much complexity to deal with the
many-certs case, and will be bad for performance if the DNS lookup has to
be delayed until the TLS handshake.

I'm inclined to say the client's logic should be to accept the cert if any
of the certs in the chain (including the server cert itself) match any
TLSFP record [0] in the DNS. Then you can either enumerate all the server
certs or rely on CA "do not issue" rules. Sadly you can't have both
because listing a CA cert implicitly authorizes any subordinate cert,
which negates the point of server cert enumeration.

[0] or whatever we settle on

Tony.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 11 Oct 2010 11:41:20 -0400

Ondrej,

I am not trying to 'obstruct' the WG as you claim.

I have been through IETF process many times over the past 18 years. I have
also had a hand in creating many of the alternative standardization routes
so I can tell you those pitfalls as well.

I would have absolutely no problem with a WG that is only going to specify
additional methods of telling a client that it can trust a key. Which is
what you appear to think that the group is limited to.

My problem is with a proposal that has an implicit condition that if there
is one FP specified in the DNS, then a client MUST regard the absence of a
matching FP to invalidate any other certificate regardless of whether there
is a valid PKIX chain or not.

Now you may not be aware that this is what some people are proposing but the
fact is that (1) they are and (2) they believe that it is a rather important
requirement.

This is precisely the type of thing that it is important to get clear before
you submit the charter. The fact that the prototype code that has been
deployed already implements these semantics is rather relevant.

As for the milestones, you want to manage expectations and specify the
longest time period the ADs will allow you to get away with. I cannot
possibly imagine them insisting on the milestones being shorter than a year.

There are many aspects of IETF process that are completely out of control of
the WG chairs and authors.

On Mon, Oct 11, 2010 at 3:27 AM, Ondřej Surý <[email-masked]> wrote:

> Just to clarify.  This group has nothing to do with Dan Kaminsky and it's
> not based on his work.  Neither his name nor his presentation was pointed
> out neither when we did bar-BoF nor when we started mailing list.
>
> This group was started on basis of work of earlier IETF contributors as was
> Simon Josefsson, Jakob Schlyter and others.[1]  It was merely meant as a
> revival of that work after we started having DNSSEC signed root.
>
> "something like this", and because I didn't want to have divergence on the
> market, I tried to concentrate work done into this place.  (Even though I
> was warned that IETF way is painful and we better keep this outside.)
>
> work here by sending tons of emails where you reiterate your ideas again and
> again just because you have entirely different idea what this group should
> be doing.  Your ideas about the work for this to-be-WG is that much
> different that you should create your own WG.  I wouldn't mind. But don't
> try to change this group into something it isn't and was never meant to be.
>
> O.
> Links:

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 11 Oct 2010 12:05:45 -0400

> which negates the point of server cert enumeration.

I agree that there are cases where there is a risk of either a CA default or
a CA being co-erced. But they are rather complex corner cases and require
assumptions that would invalidate any technology.

In the case where an end entity requires local control, the solution in my
view would be for them to either deploy their own cert issuing CA or deploy
a CA that cross certifies the end entity certs.

I cannot really see a commercial need for this approach, but there could be
a need in a government deployment.

So for example, say that you deploy Windows Server CA internally and get a
cross cert that chains your CA root to a public one. In that case you would
put out a policy statement with the FP of the intermediate root that you
control.

That is going to be a lot easier to manage than the enumeration approach
because all the necessary software to run that type of system already exists
and is mature. The enumeration approach would require tight integration
between the PKI and the DNS which is an entirely new approach.