[cabfpub] CAA concerns (and potential solutions)
sleevi at google.com
Mon Oct 31 16:09:29 UTC 2016
On Sat, Oct 29, 2016 at 12:59 AM, Gervase Markham <gerv at mozilla.org> wrote:
> On 28/10/16 17:49, Ryan Sleevi wrote:
> > On Fri, Oct 28, 2016 at 7:49 AM, Peter Bowen via Public
> > <public at cabforum.org <mailto:public at cabforum.org>> wrote:
> > I think CAs should track this so we can come back in a year and
> > review how often allowing soft-fail had any impact.
> > We've been spinning our wheels on this point for several years. For four
> > years now, we've been suggesting CAs do just that. They haven't. The
> > closest we've been able to come is for CAs to document their policies on
> > CAA.
> Just to be clear: presumably you are not against CAs documenting and
> reporting implementation experience, you are just against weakening CAA?
> I definitely think we should either require or strongly encourage CAs to
> document the actual problems CAA causes for them, if any, so we can get
> a better picture. Whether we exempt certain categories of issuance from
> CAA while we do that is a separate question.
I'm suggesting that
1) We should not prematurely weaken CAA on the basis of unsubstantiated
concerns (performance, coercion), given that we've been hearing these
concerns for five years, CAs have had ample opportunity to explore them
(which is why we had our previous ballot), and thus owe a higher level of
confidence than "what if"
2) We should not overly complicate CAA on the basis of expected
possibilities, given that CAs have had ample opportunity to explore if
they're a concern, and at least owe to the Forum a more concrete discussion
about use than "maybe this would be useful"
Given that, due to the nature of our IPR policy situation, the earliest
possibility of a new ballot is sometime in January, I don't see any reason
to continue circling the same arguments, versus, say, working with
development teams to get actual experience. Thanks to Let's Encrypt, for
example, we know it's possible to implement a reasonably efficient
implementation, and we also know that, due to Let's Encrypt having
implemented, we can also see more opportunities for specificity - or at
least, concrete examples of risks (in this case, I'm referring to cached
authorizations/cached CAA checks beyond the DNS TTL).
So Let's Encrypt has been helpful in contributing to the discussion, but
there's no reason that other CAs can't be, or can't similarly bring forth
reports of experiences, or for the public to bring forth reports of
challenges. There's been ample opportunity to experiment and work on
solutions based on actual experience, rather than abstract hypotheticals.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public