[cabfpub] CAA look up failures and retry logic
doug.beattie at globalsign.com
Wed Oct 4 13:28:41 MST 2017
From: Jacob Hoffman-Andrews [mailto:jsha at letsencrypt.org]
Sent: Wednesday, October 4, 2017 4:17 PM
To: Doug Beattie <doug.beattie at globalsign.com>; CA/Browser Forum Public Discussion List <public at cabforum.org>
Cc: geoffk at apple.com
Subject: Re: [cabfpub] CAA look up failures and retry logic
You make a good point. To reiterate the language from the BRs:
> CAs are permitted to treat a record lookup failure as permission to issue if:
> • the failure is outside the CA's infrastructure;
> • the lookup has been retried at least once; and
> • the domain's zone does not have a DNSSEC validation chain to the ICANN root.
Specifically, this talks about a single record lookup failure, but allows treating that as permission to issue. I think the behavior we'd really like here is to treat a record lookup failure as equivalent to a successful, empty response if those conditions are met. That way, for instance if a CAA lookup for "nonexistent.example.com<http://nonexistent.example.com>" returns NXDOMAIN, the CA is still required to attempt looking up a CAA record for "example.com<http://example.com>".
So I agree that your "most likely" option is the ideal, and is what CAs should be implementing to be conservative, but the BRs do not currently say that. I would support a ballot to amend it.
CAs might be motivated to run into fewer failures and to issue more certificates, so being conservative might not be what’s happening. I know we’re blocking many more requests than some other CAs (mutual customers have informed us), which is driving this line of questioning for clarity.
- What constitutes a failure?
- How are failures retried and processed?
- What’s an acceptable timeout period?
None of this is called out in the BRs or RFC.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public