[cabfpub] Draft CAA motion

[Gervase Markham]

On 09/11/16 13:40, Doug Beattie wrote:
> 1)      We’ve gone from at the time of validation (up to 39 months,
> which I agree is unreasonable) to a few days (I think Ryan suggested
> this) to 10 minutes.  I recommend we increase this back to a few days
> (let’s say 3).  This will allow more flexibility in the location of this
> check in the overall process, reduce the number duplicate checks CAs
> need to make (one when order is placed, again when validated (maybe) and
> one when issued) and will help reduce the “last minute” checks that need
> to be done and which can impact issuance.  I think a few days still
> allows a sufficiently short cache time that this should address domain
> owners concerns for rolling out updated CAA records.  What’s driving the
> 10 minute requirement?

I agree manual issuance means 10 minutes is overly short, although it
should be achievable for all automatic issuance. Duplicate checks are
cheap, as the analysis on this list showed - even someone issuing 6
million certs an hour can keep up with the amount of CAA required. So
possibly needing multiple checks is not a problem from my perspective.

We could switch to one day.

> 2)      I think there should be a provision that CAA can be done
> contractually such that those customers that own the domain can provide
> CAA approval for their Domain Name to the CA so that each of the FQDNs
> don’t need to be checked at issuance time, for the duration of the
> contract.

I'm sorry, but that moves CAA from the realm of enforced site policy to
the realm of CA policy, which defeats much of the point. We have
discussed this recently on this list, I believe.

> 3)      I strongly object to this statement – why should blocking
> issuance for a CAA record be any different than blocking issuance based
> on key word or high risk checks?  I can’t support this – why does CABF
> need the results of CAA checks?
> 
> ·         CAs MUST log issuances that were prevented by an adverse CAA
> record in sufficient detail *_to provide feedback to the CAB Forum on
> the circumstances_*

It's because people keep saying that CAA will obviously cause all sorts
of problems. This requirement is so the Forum is able to say "OK, then,
show us what the problems were and why they happened". Without this
requirement, it becomes possible for people to spread FUD about CAA.

> 4)      Specifying what is logged is a bit over the top also.  The
> requirement should be to perform CAA and not drive implementation on
> what is logged.  I searched the BRs for logging requirements and there
> no existing logging requirements this specific, so I recommend these
> statements should be dropped:
> 
> ·         CAs MUST keep records of the responses to all CAA DNS requests
> 
> ·         CAs MUST log issuances that were prevented by an adverse CAA
> record
> 
> ·         Section 2.2 “The CA SHALL log all actions taken, if any,
> consistent with its processing practice”

This latter language is already present in the existing wording, so your
grep of the BRs clearly wasn't complete.

I agree that the first logging requirement is beyond what the BRs
specify now, so we can remove that one. However, for reasons given
above, I want to keep the second one.

> 5)      I don’t understand this statement:
> 
> ·         “It shall clearly specify the set of Issuer Domain Names that
> the CA recognises as permitting it to issue.”

The RFC says:

  "A CAA record with an issue parameter tag that specifies a domain name
   is a request that certificate issuers perform CAA issue restriction
   processing for the corresponding domain and grants authorization to
   the certificate issuer specified by the domain name."

This requirement is a requirement that CAs explicitly specify the values
for the issue parameter tag which they consider as being permission to
issue. E.g. "globalsign.com". If you have improved wording, I'm happy to
hear it.

Gerv