From: [email protected] [mailto:[email protected]] 
Sent: Tuesday, October 3, 2017 10:07 PM
To: Doug Beattie <[email protected]>; CA/Browser Forum Public 
Discussion List <[email protected]>
Subject: Re: [cabfpub] CAA look up failures and retry logic

 

 





On Oct 4, 2017, at 12:01 AM, Doug Beattie via Public <[email protected] 
<mailto:[email protected]> > wrote:





The BRs say if a lookup has been retried at least once that is permission to 
issue. Does this mean doing

-          a full CAA lookup, or 

-          re-doing one failed CAA(X) look-up, or 

-          redoing every CAA(X) lookup that failed in the course of doing a 
full CAA validation?

 

If we follow the RFC processing logic and we encounter one failed lookup (e.g., 
SERVFAIL on  <http://shop.example.com/> shop.example.com), then we retry and it 
fails again, then do we exit the CAA checking and issue because the BRs say we 
may issue if we retry the lookup, which we just did?  Reading the specs this 
seems to be permitted (we did “a” retry for a failed lookup), common logic says 
no.

 

That’s an interesting point.  We could treat a (second) failure as meaning:

- Assume there is no CAA record here, continue with the algorithm, and maybe 
find a lower CAA record which denies issuance

- Assume there is a CAA record here which specifically allows issuance.

 

I believe the current wording is the second, not the first.  I think 
considering we’re just getting started with mandatory CAA, it’s OK to have this 
rule at the moment.  Switching to the first rule might be a way to tighten 
things once we’ve gotten some experience.

We run into a lot of failures when looking up the full host name for CAA 
records, but then we find CAA records at the Top Level Domain (where most 
domain administrators put them).  If I’m understanding your comments, I’m not 
sure your second option is good in these cases because the failure would permit 
issuance without looking harder for a CAA record, but this is a good discussion 
point.  Anyone else have a comment?

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public

Reply via email to