[cabfpub] Pre-Ballot 125 - CAA Records

Tue Jul 15 19:42:25 UTC 2014

See Ben’s email with alternative text below:

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Ben Wilson
Sent: Wednesday, May 14, 2014 5:46 PM
To: 'CABFPub'
Subject: Re: [cabfpub] Revisiting CAA

For consideration and discussion tomorrow as an alternative
wording/structure to Rick’s proposed ballot:

Add new definition

CAA: From RFC 6844 (http:tools.ietf.org/html/rfc6844):
<http://tools.ietf.org/html/rfc6844):>  “The Certification Authority
Authorization (CAA) DNS Resource Record allows a DNS domain name holder to
specify the Certification Authorities (CAs) authorized to issue certificates
for that domain. Publication of CAA Resource Records allows a public
Certification Authority to implement additional controls to reduce the risk
of unintended certificate mis-issue.”

Amend subparagraph 2 of 7.1.2 as follows: 

2.            Authorization for Certificate:  That, at the time of issuance,
the CA (i) implemented a procedures for verifying that the Subject
authorized the issuance of the Certificate, including procedures to (a)
consider the CAA record of each Domain Name to be listed in the
Certificate’s subject field or subjectAltName extension, and that (b) to
establish that the Applicant Representative is authorized to request the
Certificate on behalf of the Subject; (ii) followed the procedures when
issuing the Certificate; and (iii) accurately described the procedures in
Section 4.2 of  the CA’s Certificate Policy and/or Certification Practices
Statement;

[Note that regardless of whether it is RFC 2527 or RFC 36547, CAA processes
should appear in section 4.2 of a CP or CPS (Certificate Application
Processing, when based on RFC 3647, and Certificate Issuance, when based on
RFC 2527).]

Add a new 7.1.3 CAA Disclosure

Section 4.2 of the CA’s Certificate Policy or Certification Practice
Statement SHALL either describe or disclaim the CA’s procedures undertaken
to check CAA records.  A CA MAY disclaim that it considers CAA records, as
long as that disclaimer appears in Section 4.2 of that CA’s Certificate
Policy or Certification Practice Statement. 

From: Rick Andrews [mailto:Rick_Andrews at symantec.com] 
Sent: Tuesday, July 15, 2014 4:40 PM
To: Stephen Davidson; Geoff Keating
Cc: cabfpub
Subject: RE: [cabfpub] Pre-Ballot 125 - CAA Records

Stephen, what in the proposed text leads you to believe that it’s not clear
we’re talking about (a)?

From: Rick Andrews 
Sent: Tuesday, July 15, 2014 12:39 PM
To: 'Stephen Davidson'; Geoff Keating
Cc: cabfpub
Subject: RE: [cabfpub] Pre-Ballot 125 - CAA Records

Stephen, IMO the intent of the ballot has always been (a). If anyone
disagrees, please speak up.

-Rick

From: Stephen Davidson [mailto:S.Davidson at quovadisglobal.com] 
Sent: Tuesday, July 15, 2014 12:31 PM
To: Rick Andrews; Geoff Keating
Cc: cabfpub
Subject: RE: [cabfpub] Pre-Ballot 125 - CAA Records

Thanks guys.  I think it still needs to be resolved which approach the
ballot will take: a) CAs needing to state their CAA approach, or b) CAs
needing to implement auditable CAA checks and state their policies for
handling the info.

Regards, Stephen

From: Rick Andrews [mailto:Rick_Andrews at symantec.com] 
Sent: Tuesday, July 15, 2014 4:05 PM
To: Geoff Keating; Stephen Davidson
Cc: cabfpub
Subject: RE: [cabfpub] Pre-Ballot 125 - CAA Records

I agree with Geoff. CAs will typically issue a DNS query for just CAA
records, not ANY. And if you’re worried about the impact to the client
that’s looking up the address for www.example.com in DNS, they also will not
be affected by the addition of CAA records because they’ll be asking for A
or AAAA records, not ANY.

I believe there’s no technical size concern here. I think the original
comment came from Sigbjørn at Opera. If you’re still on the list, Siggy,
would you please comment? Or perhaps someone else from Opera can comment?

I know of no other issues, so perhaps we can proceed with balloting this?

-Rick

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Geoff Keating
Sent: Monday, June 30, 2014 10:18 AM
To: Stephen Davidson
Cc: cabfpub
Subject: Re: [cabfpub] Pre-Ballot 125 - CAA Records

On 30 Jun 2014, at 8:17 am, Stephen Davidson <S.Davidson at quovadisglobal.com>
wrote:

During the CABF discussion about CAA in June 2013, a browser representative
pointed out that companies may hit against size constraints when using CAA:

Adding the records increased our authoritative nameserver's DNS response
from an already juicy 458 bytes to supreme juicyness of 506 bytes (512 bytes
is still somewhat of the limit, at the very least resource usage will
increase when topping that).

And besides, we've seen that before of course, and our TXT SPF record is the
main offender here, but 506 byte responses is probably on the "winning" side
when it comes to selecting authoritative DNS servers for DNS amplification
attacks. Or spoken more generally: Maybe the CABForum should discuss how
eager the community is to add a potential massive load of additional records
to the root element of a zone/"domain".

If you use more than one CA for signing "https" certs, this can quickly
explode in size all on itself, without the help of SPF entries in the zone.
I'd guess this needs to be discussed.

The technical discussion dropped off at this point.  I believe it bears
further analysis.

I presume here we're talking about an ANY query, since a CAA response itself
is usually small by itself.  In that case it should be considered that an
ANY query for icann.org is 5278 bytes, and even TLDs like com. or us. are
1555 bytes and 538 bytes respectively.

In actual use there should be no problem since real queries (as opposed to
those intended for DoS) will not ask for the CAA record and so won't get it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140715/a0313e67/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5494 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140715/a0313e67/attachment-0001.p7s>