[cabfpub] Ballot 187 - Make CAA Checking Mandatory
doug.beattie at globalsign.com
Mon Feb 27 19:21:57 UTC 2017
> On 22/02/17 22:32, Doug Beattie wrote:
> > I think we need to talk about negative caching TTL. I recommend we add:
> > - In the event there were no CAA records found, the CA may cache
> > the result for 24-hours or the value of the negative caching TTL.
> Hi Doug,
> I thought that Ryan addressed this by explaining the mechanism the DNS
> already provides for caching a negative response. What makes you think that
> mechanism is inappropriate?
> > You reference CT logs, but I think we need to be more clear that they
> > need to be Active logs (anyone of the active logs on this page
> > https://sites.google.com/site/certificatetransparency/known-logs).
> My rationale in not doing this was that I wanted to avoid referencing a list of
> logs provided by any one particular vendor or CAB Forum member.
> > Not
> > doing so could allow someone to generate a pre-cert and post it to
> > their development CT log then wait a month/year before issuing the
> > real cert at which point the CAA check is long over the time limit.
> This is possible, I suppose; what would a CA have to gain from such strange
> behaviour? The log is required to be "public"; I expect that to mean that the
> CT community is aware of its existence and that its endpoints respond
> appropriately to calls.
I just wanted to be sure that the undefined term "two public logs" was sufficiently clear. If you feel it is, then fine.
> > I think we need to update the EVGL, section 11.7.1
> > - For each Fully-Qualified Domain Name listed in a Certificate,
> > other than a Domain Name with .onion in the right-most label of the
> > Domain Name, the CA SHALL confirm that, as of the date the Certificate
> > was issued, the Applicant (or the Applicant’s Parent Company,
> > Subsidiary Company, or Affiliate, collectively referred to as
> > “Applicant” for the purposes of this section) either is the Domain
> > Name Registrant or has control over the FQDN using a procedure
> > specified in Section 184.108.40.206 of the Baseline Requirements _and has
> > checked CAA in accordance with Section 220.127.116.11 of the Baseline
> > Requirements_. For a Certificate issued to a Domain Name with .onion
> > in the right-most label of the Domain Name, the CA SHALL confirm that,
> > as of the date the Certificate was issued, the Applicant’s control
> > over the .onion Domain Name in accordance with Appendix F.
> Why do you think this update is necessary? The BRs apply to the issuance of
> EV certificates just as much as any other sort, and CAA is mandatory in the
The relationship between the 2 documents is not always clear to me. If the BRs apply then why do we have statements like this in EGVL, seems redundant with your assumption?
9.5 Subscriber Public Key
- The requirements in Section 18.104.22.168 of the Baseline requirements apply equally to EV Certificates.
I can't find any reference in the EVGL that says you cannot issue certificates with IP addresses in them. Is this because we specifically excluded BR section 22.214.171.124 somehow? If so, is the new proposed section 126.96.36.199 also excluded from EV via the same mechanism, assumption or reference?
As long as you feel comfortable that CAA is properly documented as a requirement for EV by adding it to this section then I'm OK with that.
> > Several people have looked at RFC 6844 and have come away with
> > different interpretations of what the processing means, so I HIGHLY
> > recommend we include the CAA processing that MUST be performed so
> > there is no ambiguity and so it’s clear for auditors.
> As noted, I have no wish to "fork" the CAA standard into the BRs. There are six
> months before it is required for all CAs to start checking CAA.
> In that time, I hope that any necessary clarifications to the RFC can be issued.
> If we get closer to the time and a follow-up ballot is deemed necessary
> because the situation is still unclear, we can pass one.
More information about the Public