[cabfpub] Continuing the discussion on CAA

[Rick Andrews]

Posting to public list (seems to have been dropped)

I'll need to poll folks internally, but Symantec would probably support this. 
How do other CAs feel?

-Rick

-----Original Message-----
From: Jeremy Rowley [mailto:jeremy.rowley at digicert.com]
Sent: Monday, October 17, 2016 7:41 AM
To: Gervase Markham <gerv at mozilla.org>; Bruce Morton 
<Bruce.Morton at entrust.com>; Ryan Sleevi <sleevi at google.com>; Rick Andrews 
<Rick_Andrews at symantec.com>
Subject: RE: [cabfpub] Continuing the discussion on CAA

I'd support a position if CAA was a validation check rather than an issuance
check. That way there isn't a difference between "enterprise" and "retail".
Instead, it's tied to the domain validation process and is required whenever
domain validation is required.

-----Original Message-----
From: Gervase Markham [mailto:gerv at mozilla.org]
Sent: Monday, October 17, 2016 6:36 AM
To: Bruce Morton <Bruce.Morton at entrust.com>; Jeremy Rowley
<jeremy.rowley at digicert.com>; Ryan Sleevi <sleevi at google.com>; Rick Andrews
<Rick_Andrews at symantec.com>
Subject: Re: [cabfpub] Continuing the discussion on CAA

On 14/10/16 20:45, Bruce Morton wrote:
> For retail, perform hard fail CAA record check for all new requests
> and renewals. Do not perform CAA record check for a reissue.

ISTR that previously there has been some controversy about whether "reissue"
is a separate class of thing to a renewal (with some CAs doing "reissues" with
forbidden in-cert constructs that would not be allowed for new issuances or
renewals).

Can you quickly define the difference for us, in words? And how would you
programmatically distinguish between reissues and renewals?

> For enterprise, perform hard fail CAA record check when the domain is
> being pre-validated. Also perform hard fail CAA record check when the
> domain is re-verified in the 13 or 39 month cycle. Do not perform CAA
> record check when an Enterprise RA logs in to approve certificate issuance.

Does such an Enterprise RA issuance come from a name-constrained intermediate,
or not always?

If there are cases where it does not, presumably the CA (but not the RA) has
control over the list of domains for which issuance is permitted.
How is such a list maintained and changed?

> Also, could we create a variable which could be included in the CAA
> record for strict CAA compliance. This variable would be in the CPS
> for all CAs and if used would make the CAA record the superior
> statement for CA authorization. The CA would still follow the checking
> cycle above, so would not impact a currently approved CA without
> re-verification or subscriber agreement cancellation.

The CAA RFC mandates it as a hard-fail thing. Making it default to some form
of softer fail and doing hard fail only with an extra token present would be
semantically very confusing. I would be less concerned with a "soft fail"
token, with hard fail being the default, but I suspect that would not address
the issues you raise.

Gerv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5725 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20161017/dd813ee8/attachment-0001.p7s>