Hi Peter, According to this decision flow, I think it's okay for a CA to issue certificates: ``` Receive CAA query result │ ├─ RCODE = NXDOMAIN? │ │ │ ├─ AD = 1 │ │ └─ Trustworthy → CAA(X) = Empty → continue to Parent(X) <---- example.org │ │ │ ├─ Parent zone has no DNSSEC │ │ └─ Trustworthy → CAA(X) = Empty → continue to Parent(X) <---- atomicpath.com │ │ │ └─ AD = 0 AND parent has DNSSEC │ └─ Untrustworthy → fail closed, refuse issuance │ ├─ SERVFAIL / TIMEOUT / REFUSED / NOTIMP? │ └─ MAY refuse issuance (fail closed → refuse issuance) │ ├─ NOERROR + has CAA records? │ ├─ issue/issuewild restricts issuance → apply CAA policy │ ├─ critical unknown tag → refuse issuance │ └─ iodef or unknown tags only → treat as Empty, continue to parent │ ├─ NOERROR + no CAA records (Empty)? │ └─ continue to Parent(X) │ └─ Reached root "." and still Empty? └─ CAA does not restrict issuance ```
On Tuesday, March 24, 2026 at 10:54:18 AM UTC+8 Peter Bowen wrote: > On Tue, Mar 17, 2026 at 7:56 AM Michael Stone <[email protected]> wrote: > > 3. Bug 1695786 (SECOM) > > > > In Bug 1695786, SECOM treated NXDOMAIN for the non-existent domain > sgnwffw001 as permission to issue. Ryan and Paul clarified that when the > root zone has a DNSSEC validation chain, a CA must not treat a lookup > failure (including NXDOMAIN) as permission to issue — i.e., it must fail > closed. > > > 4. The apparent tension > > > > Subdomain NXDOMAIN (e.g., sub.example.com): RFC 8659 and the Oct 4 > thread suggest we continue to the parent example.com — NXDOMAIN = "no CAA > here" = keep climbing. > > Non-existent domain NXDOMAIN (e.g., sgnwffw001): Bug 1695786 indicates > that when DNSSEC is present, NXDOMAIN must not be treated as permission — > fail closed. > > Signed NXDOMAIN (Oct 9 thread): The question of whether "signed > NXDOMAIN" is a failure suggests DNSSEC-authenticated NXDOMAIN may have > different handling than unsigned NXDOMAIN. > > > > 5. Questions: > > > > Q1 — Subdomain NXDOMAIN: > > We are issuing for www.example.com. The parent example.com exists. CAA > lookup for www.example.com returns NXDOMAIN. Should the CA: > > (a) Continue to query CAA for example.com, and allow issuance only if > example.com also has no CAA records; or > > (b) Treat NXDOMAIN as a lookup failure and deny issuance? > > > > Q2 — Non-existent domain with DNSSEC: > > We are issuing for sgnwffw001 (the domain does not exist in DNS). The > root zone has a DNSSEC validation chain. CAA lookup returns NXDOMAIN. Must > the CA deny issuance (fail closed), and must it NOT treat NXDOMAIN as "no > CAA restriction" and allow issuance? > > I think Q2 is misleading because you are using an unqualified name, > which confuses things. I think you are calling out a disagreement > about signed vs. unsigned. > > Consider requests for the following, both of which are FQDNs that do > not exist where the parents exist. > > demo.example.com > demo.atomicpath.com > > In the first case, example.com is a signed zone that chains back to > the root, so the result is a Trusted Existence denied. > > In the second case, atomicpath.com is an unsigned zone, so the result > is an Unsigned No data found. com returned a Trusted Existence > denied: atomicpath.com. DS, so we have trusted confirmation that com > does not expect atomicpath.com to be signed. > > There are no CAA records for example.com, atomicpath.com, or com. > > Is the CA allowed to issue for both names? > > Thanks, > Peter > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/79f4765e-9f51-4cc1-ba9f-43ea6799820bn%40mozilla.org.
