[cabfpub] Draft CAA motion

[Ryan Sleevi]

On Wed, Nov 9, 2016 at 10:48 AM, Bruce Morton <
Bruce.Morton at entrustdatacard.com> wrote:

> I do think that the random person executing a contract with a CA is out of
> scope of the CAA discussion. This issue can potentially already happen with
> or without a CAA policy. I do not think this is an issue with OV and EV
> certificates.
>

I think you're missing that it's somewhat core to the discussion.

If I place a CAA record that says "Only Entrust shall issue", then
presumably, I have a contract with you (or will soon have one). If I have a
contract with you, then per 3.2.5 of the BRs, I can further limit that
scope of issuance to just named parties.

If we take CAA out of the equation, then I have no way of notifying you who
the authorized parties are - you could end up signing a contract with
anyone. With CAA, I gain the ability to combine with the existing BRs to
sufficiently prevent against internal misissuance - in *addition* to
preventing external misissuance (as previously discussed with the
Amazon/Microsoft/Google hosting scenarios)


> I think the primary CAA goal is to assure that a random unidentified
> person does not receive a certificate where the CAA record does not
> authorize the CA for issuing.
>

That is a goal, but I think it's unnecessarily crippling to suggest that's
the only goal. As has been discussed in several calls and the F2F, the
flexibility to limit which CAs can issue opens up for a host of new
opportunities for domain holders to specify their policies, and reduce the
risk of a CA being lax, compelled, or fooled into issuing a certificate to
a person not authorized - internally or externally.


> This could also be extended to stopping an random person from creating an
> account where the data is pre-verified if the verification fails the CAA
> check. I also hope the goal is to allow a company to contract a CA to issue
> tens, hundreds or thousands of certificates per year without suddenly being
> blocked by a change to a CAA record.
>

I think the preponderance of evidence on this thread have shown that this
claim - "blocked by a change to a CAA record" - is not supported. If you
have any data or experience to show it is, I think that'd be very useful -
and indeed, I appreciate Gerv's clause that tries to move us beyond the
circular discussions claiming (without evidence or experience) that it will
be a problem.


> There are minimum requirements for an enterprise to open a certificate
> management service, such as:
>
> ·        Accept the Subscriber agreement
>
> ·        All organization names would be pre-validated to OV or EV
> requirements
>
> ·        All Base Domain Names would have to be pre-validated
>
> ·        Enterprise RAs would be validated by contacting the enterprise
> using a Reliable Method of Communication
>
> ·        All certificate requests or API implementations would have to be
> approved by the Enterprise RA
>
>
>
> I think that we should be able to come to an agreement to use CAA to block
> an unauthorized CA from issuing in over 99% of the cases. I’m also hoping
> we can find a way to allow a verified enterprise Subscriber to have
> successful certificate requests without suddenly being blocked by CAA.
>

Again, I think we've spent considerable time trying to unpack what this
"blocked by CAA" claim represents, but so far, all representations have
been shown to either be hypothetical or unsubstantiated, while those
proponents in favor of a harder stance have demonstrated both the value and
the ease at which it can be implemented. I'm unclear if we're simply at the
point where you cannot be convinced it's not an issue, and if so, if you're
willing to offer any ground to compromise by adopting a more secure stance,
given the issues raised.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20161109/351ca036/attachment-0001.html>