[cabfpub] CAA (was RE: Domain Control Validation)

[Ryan Sleevi]

On Aug 25, 2014 11:05 AM, "Ben Wilson" <ben.wilson at digicert.com> wrote:
>
> Wouldn’t adding a pre-negotiated list to the DNS TXT proposal take us in
multiple directions on this issue?

The point is that CAA represents a fixed change, ergo you can't infer from
its presence alone that the requestor is authorized.

For example, compare the CAA records for Google.com. That does not mean
anyone may request a Google.com cert from our CA, nor is any Google user
authorized. But CAA lacks a way to express that, so you need an added
mechanism.

The agreed upon domain control / email validation, however, is something we
can control and ensure only authorized people can access.

>  It gets us back to the arguments about who has the say – it might even
support your earlier argument about the enforceability of the CAA record
(e.g. the people with control over DNS are, by observation of their ability
to control DNS, technically on a “pre-negotiated list) vs. argument from
others who favor the flexible buying decisions by purchasing departments
who don’t have control over DNS but do control buying decisions for
certificates.  Actually, I see myself taking the other side on that issue,
but here, if the CA gives the applicant a code that they need to put in the
TXT record, and that happens, then requiring a new pre-negotiated list
seems like an enhancement over and above what already exists for EV under
section 11.1.

Agreed, and I wasn't suggesting that. I think a CA-generated code with the
DNS admin placing it is equivalent to mechanisms 1-6 for control
demonstration purposes.

> It does re-raise that
>
> issue of “agree-upon change” in #6.   Has anyone had the chance to go
look where/how small changes could be made to that requirement in order to
strengthen it (e.g. by defining a heightened level of sophistication for
the “agreed-upon change”)?
>

I would want to see the equivalence method dropped entirely.
Any/all methods that CAs are presently employing could be explicitly
enumerated.

When methods have broad scope (e.g. email, filesystem), the BRs can
explicitly constrain them (well known emails, well known paths).

The goal is not to "strengthen" DV, but to ensure that DV continues to mean
that a minimal level of domain control and authorization has been
demonstrated.

>
>
> From: Ryan Sleevi [mailto:sleevi at google.com]
> Sent: Monday, August 25, 2014 11:15 AM
> To: Ben Wilson
> Cc: Rick Andrews; CABFPub
> Subject: CAA (was RE: [cabfpub] Domain Control Validation)
>
>
>
>
> On Aug 25, 2014 10:08 AM, "Ben Wilson" <ben.wilson at digicert.com> wrote:
> >
> > What if the allowed procedure required a before and after comparison?
The other alternative is an agreed-upon or CA-generated text string.
> >
> >
> >
> > I was just thinking that it would be a good way to promote CAA (one
could argue that CAA obviates the need to perform domain control checks).
> >
>
> No, it really doesn't.
>
> A key point of the demonstration of control is ensuring the applicant is
authorized for the request.
>
> It would allow _anyone_ to request a cert for that domain, without a
demonstration of control, from any of the CAs listed.
>
> The absolute bare minimum would be to ensure a pre-negotiated list of
authorized contacts for the CA (a provision the BR allows for and requires
that CAs vet), but that still requires establishing at some point in time
that the user supplying the list was authorized.
>
> Not to pick on you, since I think it was a good faith effort to improve
CAA adoption (which I do think would be good, especially if CAs had to
state their policies), but this is exactly why I think Item 7 is far too
dangerous for the BRs.  Good intentions, but certainly not sufficient
security.
>
> >
> >
> > So dropping the CAA suggestion, what if the language said “7.
Having the Applicant demonstrate practical control over the FQDN by adding
a unique, CA-specified TXT record to the DNS zone file.”?
> >
> >
> >
> > From: Rick Andrews [mailto:Rick_Andrews at symantec.com]
> > Sent: Monday, August 25, 2014 11:00 AM
> > To: Ben Wilson; Ryan Sleevi
> > Cc: CABFPub
> > Subject: RE: [cabfpub] Domain Control Validation
> >
> >
> >
> > Ben, I don’t think that would work, because AFAIK there’s no way to
tell when the record was added to DNS.
> >
> >
> >
> > From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
On Behalf Of Ben Wilson
> > Sent: Monday, August 25, 2014 9:42 AM
> > To: Ryan Sleevi
> > Cc: CABFPub
> > Subject: Re: [cabfpub] Domain Control Validation
> >
> >
> >
> > What if it were the simple act of placing a CAA record in the DNS that
identified the CA?
> >
> > Would that be sufficient as a new method to add into section 11.1 of
the BRs that would not be excluded from the EV Guidelines?
> >
> >
> >
> > From: Ryan Sleevi [mailto:sleevi at google.com]
> > Sent: Sunday, August 24, 2014 11:43 AM
> > To: Ben Wilson
> > Cc: CABFPub
> > Subject: Re: [cabfpub] Domain Control Validation
> >
> >
> >
> >
> > On Aug 24, 2014 9:17 AM, "Ben Wilson" <ben.wilson at digicert.com> wrote:
> > >
> > > Does anyone recall whether we have ever discussed domain control
validation by having the Applicant demonstrate practical control over the
FQDN by making a change to information in the DNS zone file?
> > >
> > >
> >
> > Right, this was discussed when we talked about demonstrations of
control via file on disk, and this falls into subsection 7, any other
equivalent.
> >
> > >
> > > The EV Guidelines cross-reference Section 11.1 of the Baseline
Requirements for this, but it seems that this method is not in subsections
1 through 6 (the closest is subsection 6, from which I drew some of the
language for my question), and the EV Guidelines exclude reliance on
subsection 7.   Could this be an item that the EV Guidelines working group
should add to its list of items to review, if it isn’t already on the list?
> > >
> >
> > If they do, I would prefer it be extremely precise and narrowly scoped,
such as email.
> >
> > A site operator MUST be able to take reasonable mitigations against a
lax CA.
> >
> > >
> > >
> > > Thanks
> > >
> > >
> > >
> > > Ben
> > >
> > >
> > > _______________________________________________
> > > Public mailing list
> > > Public at cabforum.org
> > > https://cabforum.org/mailman/listinfo/public
> > >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20140825/68045299/attachment.html