Name Constraints, empty sets in permitted subtree (RFC 3280 vs RFC 5280)

Question

I'm trying to understand the effect of empty sets in permittedSubtrees in both, RFC 5280 and RFC 3280. There is something that doesn't compile in my head.

Scenario:

We have a CA certificate with the following Name Constraints setup:

Permitted
     [1]Subtrees (0..Max):
          RFC822 Name=email@example.com
     [2]Subtrees (0..Max):
          DNS Name=

The setup has an empty set for dnsName name type. RFC 5280 is more clear on this and §6.1.1 (h), §6.1.2 (b), §6.1.3 (b) and §6.1.4 (g) suggests that any issued certificate by this CA with dnsName name type in SAN extension are considered non-valid.

Here are my understandings:

1. There is an obvious difference between absent subtree and explicit empty set. In first case, (as per initialization in §6.1.2 (b)), a default value permit all is assigned to the absent subtree. In second case, default value is overridden with explicit empty set.
2. In a given setup, no dnsName name types are allowed in issued certificates.
3. any iPAddress name type is allowed in issued certificates.

If my understanding of RFC 5280 in this regard is correct, then my main question: what is the expected behavior for this setup against RFC 3280? The main difference is that RFC 3280 doesn't include §6.1.1 (h) where empty set behavior is explicitly defined. Does this section absence allows free interpretation of empty set behavior?

p.s. The question is related to Name Constraints validation in Windows client. Windows client successfully validate leaf certificate with dnsName name type despite that issuer defines an empty set for this name type. I have a support ticket with Microsoft, however the process is extremely slow (10 months atm) and their only helpful answer is that Windows client is written against RFC 3280 and Microsoft claims that the absence of §6.1.1 (h) allowed them to freely treat this behavior.

Answer 1

I did some digging, and The CA/Brower Forum, of which Microsoft is a member, suggests another way of doing it, that doesn't sound very logical. The Baseline Requirements have the following blurb in §7.1.5 Name constraints:

If the Subordinate CA is not allowed to issue certificates with dNSNames, then the Subordinate CA Certificate MUST include a zero‐length dNSName in excludedSubtrees. Otherwise, the Subordinate CA Certificate MUST include at least one dNSName in permittedSubtrees.

Your certificate layout would be in contradiction of that.

But a footnote in the Baseline Requirements shows that the CA/Browser Forum has little illusion about any of it working correctly, as the baseline requirements allow non critical nameConstraints in violation of RFC 5280 with the note

Non‐critical Name Constraints are an exception to RFC 5280 (4.2.1.10), however, they MAY be used until the Name Constraints extension is supported by Application Software Suppliers whose software is used by a substantial portion of Relying Parties worldwide