[cabfpub] Draft CAA motion

[Bruce Morton]

I think the “blocked by a change to a CAA record” is important to the discussion and does not need evidence to be supported. I’m looking at this as error handling for an improper CAA record. Experience tells me that since CAA is new there will be errors. I assume that errors have also happened with other controls such as HPKP. I think our policy should consider errors.

I also assume that a person signing a Subscriber agreement is more authorized to accept the agreement than a DNS administrator is at declining an agreement. I do not see agreement, contract, etc. in the RFC.

I would prefer if we started CAA with minimum requirements and then make these requirements more strict over time, rather than creating a policy which is very strict with no back-out clause, when there has not been enough CAA records to gain any new experience.

Bruce.

From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Wednesday, November 9, 2016 1:58 PM
To: Bruce Morton <Bruce.Morton at entrustdatacard.com>
Cc: CA/Browser Forum Public Discussion List <public at cabforum.org>; Doug Beattie <doug.beattie at globalsign.com>
Subject: Re: [cabfpub] Draft CAA motion



On Wed, Nov 9, 2016 at 10:48 AM, Bruce Morton <Bruce.Morton at entrustdatacard.com<mailto: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/893120e6/attachment-0001.html>