Subject: [lamps] Fwd: [pkix] [Technical Errata Reported] RFC6844 (5200)

From: Russ Housley <[email-masked]>
Date: Fri, 8 Dec 2017 13:16:29 -0500

> From: RFC Errata System <[email-masked]>
> Subject: [pkix] [Technical Errata Reported] RFC6844 (5200)
> Date: December 8, 2017 at 1:00:55 PM EST
> To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
> Cc: [email-masked], [email-masked], [email-masked]
> 
> The following errata report has been submitted for RFC6844,
> "DNS Certification Authority Authorization (CAA) Resource Record".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5200
> 
> --------------------------------------
> Type: Technical
> Reported by: Richard Gibson <[email-masked]>
> 
> Section: 3
> 
> Original Text
> -------------
> <Issuer Domain Name> [; <name>=<value> ]*
> 
> Corrected Text
> --------------
> <Issuer Domain Name> [; [ <name>=<value> ]* ]
> 
> Notes
> -----
> For values of the "issue" and "issuewild" property tags, section 3 specifies [; <name>=<value> ]* (which seems to indicate that every parameter is preceded by a semicolon) but the grammar in section 5.2 specifies [";" *(space parameter) space] (in which parameters are separated by whitespace and the entire list is preceded by a single semicolon). Presumably, the formal grammar is definitive and the preceding shorthand should be updated to better express it.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC6844 (draft-ietf-pkix-caa-15)
> --------------------------------------
> Title               : DNS Certification Authority Authorization (CAA) Resource Record
> Publication Date    : January 2013
> Author(s)           : P. Hallam-Baker, R. Stradling
> Category            : PROPOSED STANDARD
> Source              : Public-Key Infrastructure (X.509)
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG
>

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 15 Dec 2017 20:05:57 -0800

> http://www.rfc-editor.org/errata/eid5200

The question here is whether CAA records with property tags should look
like:

example.com. IN CAA 0 issue "example.net; foo=bar bar=qux"

or:

example.com. IN CAA 0 issue "example.net; foo=bar; bar=qux"

(note the second semicolon)

I think the original text is ambiguous on the point, and since property
tags are not yet widely deployed this is a somewhat free choice. I think
the version where property tags are separated by semicolons makes more
sense and is less error prone. It also happens to be what Hugo Landau's
draft for CAA Record Extensions uses:
https://tools.ietf.org/html/draft-ietf-acme-caa-03#page-9

And what was briefly implemented in Let's Encrypt's Boulder (since
rolled back due to a bug):

https://github.com/letsencrypt/boulder/pull/3145/files#diff-3efab53f2bcc543ac2e771ec882c57c1L310

So my feeling is we should reject this erratum and clarify in the other
direction, requiring semicolons between property tags. Thoughts?

---

From: Tim Hollebeek <[email-masked]>
Date: Mon, 18 Dec 2017 14:40:51 +0000

As pointed out on the cabf_validation list, the original text isn't just
ambiguous, the RFC contradicts itself.  I don't feel too strongly either
way, as long as it gets resolved soon, as property tags are about to become
commonly deployed (there were several proposed uses discussed at the Taipei
face-to-face meeting of the CA/Browser forum).

I do however have a slight preference for only having a single separator
(whitespace), not two in order to avoid confusion about what to do about
whitespace after semicolons and around = signs.

The semicolon doesn't really serve a useful purpose, though we do have to
keep one since there are existing CAA records out there that use it.  I'd
like the grammar to essentially be:

    domain ; [name = value]+

with the clarification that whitespace is ignored.

So my personal preference is the first style you mentioned, in line with the
submitted errata:

It's the style I used in my proposal for industry standard property tag
names on cabf_validation last week.

-Tim

> -----Original Message-----
> From: Spasm [mailto:[email-masked]] On Behalf Of Jacob Hoffman-
> Andrews
> Sent: Friday, December 15, 2017 9:06 PM
> To: [email-masked]
> Subject: Re: [lamps] Fwd: [pkix] [Technical Errata Reported] RFC6844
(5200)
> I think the original text is ambiguous on the point, and since property
tags are
> not yet widely deployed this is a somewhat free choice. I think the
version
> where property tags are separated by semicolons makes more sense and is
> less error prone. It also happens to be what Hugo Landau's draft for CAA
> Record Extensions uses:
> And what was briefly implemented in Let's Encrypt's Boulder (since rolled
> back due to a bug):
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Corey Bonnell <[email-masked]>
Date: Wed, 20 Dec 2017 16:03:31 +0000

After thinking about this further, I’m in favor of using semicolons to delimit parameters, as Tim mentioned that we likely need to continue using the semicolon to delimit the identifying domain name from the parameter list due to its current ubiquity. It would be inconsistent to use a semicolon to delimit the identifying domain name from the parameter list but also mandate that parameter name/value pairs be delimited using whitespace. That being said, I like the idea that non-significant whitespace can be used in records to improve human readability.

Given that RFC 5234 prohibits the use of implicit “linear white space” in section 3.1 (http://www.rfcreader.com/#rfc5234_line204), RFC 6844 must explicitly state in the production rules that non-significant whitespace is supported. With that in mind, I believe that the ABNF production rules in RFC 6844 section 5.1 (http://www.rfcreader.com/#rfc6844_line447) for “issuevalue” should be modified to something similar to this:

issuevalue = *WSP [domain] *WSP [";" *WSP [parameters] *WSP]
parameters = (parameter *WSP “;” *WSP parameters) / parameter
parameter = tag "=" value
tag = 1*(ALPHA / DIGIT)
value = *(%x21-3A / %x3C-7E)

(The “parameter” and “tag” production rules are unchanged but I listed them here to list the relevant rules in one place.)

Note that I removed the “space” production rule, as RFC 5234 provides us with a nearly identical (differing only in the number of allowed repetitions, but the character class is the same) “WSP” rule in its core module (http://www.rfcreader.com/#rfc5234_line520). Also note that I modified the “value” rule, as we need to exclude the semicolon (ASCII code 0x3B) from the set of allowed characters in parameter values.

Thanks,
Corey
 
Corey Bonnell
Senior Software Engineer

Trustwave | SMART SECURITY ON DEMANDwww.trustwave.com <http://www.trustwave.com/>
 
2017 Best Managed Security Service Winner – SC Media

On 12/18/17, 9:41 AM, "Spasm on behalf of Tim Hollebeek" <[email-masked] on behalf of [email-masked]> wrote:

    
    
        domain ; [name = value]+

    
        http://scanmail.trustwave.com/?c=4062&d=gNO32sFHeluIcLm6XdmrAg7jw4lzJFuSdgMZzyv9PQ&s=5&u=http%3a%2f%2fexample%2ecom IN CAA 0 issue "http://scanmail.trustwave.com/?c=4062&d=gNO32sFHeluIcLm6XdmrAg7jw4lzJFuSdldOn33-ag&s=5&u=http%3a%2f%2fexample%2enet%3b foo=bar bar=qux"

    -Tim
    
    (5200)
    > > http://scanmail.trustwave.com/?c=4062&d=gNO32sFHeluIcLm6XdmrAg7jw4lzJFuSdlJPySquaA&s=5&u=http%3a%2f%2fwww%2erfc-editor%2eorg%2ferrata%2feid5200
    > 
    > http://scanmail.trustwave.com/?c=4062&d=gNO32sFHeluIcLm6XdmrAg7jw4lzJFuSdgMZzyv9PQ&s=5&u=http%3a%2f%2fexample%2ecom IN CAA 0 issue "http://scanmail.trustwave.com/?c=4062&d=gNO32sFHeluIcLm6XdmrAg7jw4lzJFuSdldOn33-ag&s=5&u=http%3a%2f%2fexample%2enet%3b foo=bar bar=qux"
    > 
    > or:
    > 
    > http://scanmail.trustwave.com/?c=4062&d=gNO32sFHeluIcLm6XdmrAg7jw4lzJFuSdgMZzyv9PQ&s=5&u=http%3a%2f%2fexample%2ecom IN CAA 0 issue "http://scanmail.trustwave.com/?c=4062&d=gNO32sFHeluIcLm6XdmrAg7jw4lzJFuSdldOn33-ag&s=5&u=http%3a%2f%2fexample%2enet%3b foo=bar; bar=qux"
    > 
    tags are
    version
    > https://scanmail.trustwave.com/?c=4062&d=gNO32sFHeluIcLm6XdmrAg7jw4lzJFuSdlFIyn6uOA&s=5&u=https%3a%2f%2ftools%2eietf%2eorg%2fhtml%2fdraft-ietf-acme-caa-03%23page-9
    > 
    > https://scanmail.trustwave.com/?c=4062&d=gNO32sFHeluIcLm6XdmrAg7jw4lzJFuSdgQUz3v8bQ&s=5&u=https%3a%2f%2fgithub%2ecom%2fletsencrypt%2fboulder%2fpull%2f3145%2ffiles%23diff-
    > 3efab53f2bcc543ac2e771ec882c57c1L310
    > 
    > https://scanmail.trustwave.com/?c=4062&d=gNO32sFHeluIcLm6XdmrAg7jw4lzJFuSdgofny-qPw&s=5&u=https%3a%2f%2fwww%2eietf%2eorg%2fmailman%2flistinfo%2fspasm

---

From: Tim Hollebeek <[email-masked]>
Date: Wed, 20 Dec 2017 17:28:14 +0000

This looks good to me.  I could get behind this.

-Tim

> From: Corey Bonnell [mailto:[email-masked]]
> Sent: Wednesday, December 20, 2017 9:04 AM
> To: Tim Hollebeek <[email-masked]>; Jacob Hoffman-Andrews
> <[email-masked]>; [email-masked]
> Subject: Re: [lamps] Fwd: [pkix] [Technical Errata Reported] RFC6844 (5200)
> 
> After thinking about this further, I’m in favor of using semicolons to delimit
> parameters, as Tim mentioned that we likely need to continue using the
> semicolon to delimit the identifying domain name from the parameter list due
> to its current ubiquity. It would be inconsistent to use a semicolon to delimit
> the identifying domain name from the parameter list but also mandate that
> parameter name/value pairs be delimited using whitespace. That being said, I
> like the idea that non-significant whitespace can be used in records to
> improve human readability.
> 
> Given that RFC 5234 prohibits the use of implicit “linear white space” in
> section 3.1 (https://clicktime.symantec.com/a/1/223l-
> OOuL7oxSQZbmNPzrW-fzlB3ZyRehuXa1uhXQ_0=?d=RZrpddyRRTQ154PRoAlI-
> Q9RbRRqmTet1Xm0uCdsU_76X79txFJWMGdDB2vayT_egarHUxCPBwWT5eHf
> BNnpKlx7W1mdGFJxIUnhYLisSSX6EqRMdSKRkKNx4wnVnB7zbllNvijPQiAP0aw
> sDHbVIPazzk2B2mld5wAzznIvkCABWKNmv4EtLSB2Azz831XxmyzQpAOPgdhU
> GamB8As9HkVGdCAEm0-
> YzoAiCxR7FclB5StDbL8Rhxz6EWTqb4AvPLqa_SpYOcFuWsXrevKnJKyzleaW6qb
> Vgl8UPOOx53m6f4Rl0caquHZPVvYzzuh59qwvG64WcemTGe_h9duJ0pbCj-
> UYAwwzKOTBdAqtmAxXqS9xB80aaCuRw8cEMCdeJXpEhXH0x9p045zQRtLwqq
> BgWx9UwSIkOYJT331aaaas4Q%3D%3D&u=http%3A%2F%2Fwww.rfcreader.c
> om%2F%23rfc5234_line204), RFC 6844 must explicitly state in the production
> rules that non-significant whitespace is supported. With that in mind, I believe
> that the ABNF production rules in RFC 6844 section 5.1
> (https://clicktime.symantec.com/a/1/QXA3DmFxWmhgnol1OsR_jPGPFCJRny
> 0xy6bKiW3sKgo=?d=RZrpddyRRTQ154PRoAlI-
> Q9RbRRqmTet1Xm0uCdsU_76X79txFJWMGdDB2vayT_egarHUxCPBwWT5eHf
> BNnpKlx7W1mdGFJxIUnhYLisSSX6EqRMdSKRkKNx4wnVnB7zbllNvijPQiAP0aw
> sDHbVIPazzk2B2mld5wAzznIvkCABWKNmv4EtLSB2Azz831XxmyzQpAOPgdhU
> GamB8As9HkVGdCAEm0-
> YzoAiCxR7FclB5StDbL8Rhxz6EWTqb4AvPLqa_SpYOcFuWsXrevKnJKyzleaW6qb
> Vgl8UPOOx53m6f4Rl0caquHZPVvYzzuh59qwvG64WcemTGe_h9duJ0pbCj-
> UYAwwzKOTBdAqtmAxXqS9xB80aaCuRw8cEMCdeJXpEhXH0x9p045zQRtLwqq
> BgWx9UwSIkOYJT331aaaas4Q%3D%3D&u=http%3A%2F%2Fwww.rfcreader.c
> om%2F%23rfc6844_line447) for “issuevalue” should be modified to
> something similar to this:
> 
> (The “parameter” and “tag” production rules are unchanged but I listed them
> here to list the relevant rules in one place.)
> 
> Note that I removed the “space” production rule, as RFC 5234 provides us
> with a nearly identical (differing only in the number of allowed repetitions, but
> the character class is the same) “WSP” rule in its core module
> (https://clicktime.symantec.com/a/1/-0fHBEr5CPqHK4BAN-1-SoYnA0YT-
> 6fhfpIyNPkPvE4=?d=RZrpddyRRTQ154PRoAlI-
> Q9RbRRqmTet1Xm0uCdsU_76X79txFJWMGdDB2vayT_egarHUxCPBwWT5eHf
> BNnpKlx7W1mdGFJxIUnhYLisSSX6EqRMdSKRkKNx4wnVnB7zbllNvijPQiAP0aw
> sDHbVIPazzk2B2mld5wAzznIvkCABWKNmv4EtLSB2Azz831XxmyzQpAOPgdhU
> GamB8As9HkVGdCAEm0-
> YzoAiCxR7FclB5StDbL8Rhxz6EWTqb4AvPLqa_SpYOcFuWsXrevKnJKyzleaW6qb
> Vgl8UPOOx53m6f4Rl0caquHZPVvYzzuh59qwvG64WcemTGe_h9duJ0pbCj-
> UYAwwzKOTBdAqtmAxXqS9xB80aaCuRw8cEMCdeJXpEhXH0x9p045zQRtLwqq
> BgWx9UwSIkOYJT331aaaas4Q%3D%3D&u=http%3A%2F%2Fwww.rfcreader.c
> om%2F%23rfc5234_line520). Also note that I modified the “value” rule, as we
> need to exclude the semicolon (ASCII code 0x3B) from the set of allowed
> characters in parameter values.
> 
> Thanks,
> Corey
> 
> Corey Bonnell
> Senior Software Engineer
> 
> Trustwave | SMART SECURITY ON DEMANDwww.trustwave.com
> <https://clicktime.symantec.com/a/1/WBsY-
> EHcHWXZ8gHVn_TTn1EioTncr2wyhIBkPnoJz5U=?d=RZrpddyRRTQ154PRoAlI-
> Q9RbRRqmTet1Xm0uCdsU_76X79txFJWMGdDB2vayT_egarHUxCPBwWT5eHf
> BNnpKlx7W1mdGFJxIUnhYLisSSX6EqRMdSKRkKNx4wnVnB7zbllNvijPQiAP0aw
> sDHbVIPazzk2B2mld5wAzznIvkCABWKNmv4EtLSB2Azz831XxmyzQpAOPgdhU
> GamB8As9HkVGdCAEm0-
> YzoAiCxR7FclB5StDbL8Rhxz6EWTqb4AvPLqa_SpYOcFuWsXrevKnJKyzleaW6qb
> Vgl8UPOOx53m6f4Rl0caquHZPVvYzzuh59qwvG64WcemTGe_h9duJ0pbCj-
> UYAwwzKOTBdAqtmAxXqS9xB80aaCuRw8cEMCdeJXpEhXH0x9p045zQRtLwqq
> BgWx9UwSIkOYJT331aaaas4Q%3D%3D&u=http%3A%2F%2Fwww.trustwave.c
> om%2F>
> 
> On 12/18/17, 9:41 AM, "Spasm on behalf of Tim Hollebeek" <spasm-
> [email-masked] on behalf of [email-masked]> wrote:
> 
>         https://clicktime.symantec.com/a/1/guXt-
> wbIajcv9dPXp03AETYKnnGzu7bRQAzwwoTu1BQ=?d=RZrpddyRRTQ154PRoAlI-
> Q9RbRRqmTet1Xm0uCdsU_76X79txFJWMGdDB2vayT_egarHUxCPBwWT5eHf
> BNnpKlx7W1mdGFJxIUnhYLisSSX6EqRMdSKRkKNx4wnVnB7zbllNvijPQiAP0aw
> sDHbVIPazzk2B2mld5wAzznIvkCABWKNmv4EtLSB2Azz831XxmyzQpAOPgdhU
> GamB8As9HkVGdCAEm0-
> YzoAiCxR7FclB5StDbL8Rhxz6EWTqb4AvPLqa_SpYOcFuWsXrevKnJKyzleaW6qb
> Vgl8UPOOx53m6f4Rl0caquHZPVvYzzuh59qwvG64WcemTGe_h9duJ0pbCj-
> UYAwwzKOTBdAqtmAxXqS9xB80aaCuRw8cEMCdeJXpEhXH0x9p045zQRtLwqq
> BgWx9UwSIkOYJT331aaaas4Q%3D%3D&u=http%3A%2F%2Fscanmail.trustwa
> ve.com%2F%3Fc%3D4062%26d%3DgNO32sFHeluIcLm6XdmrAg7jw4lzJFuSdg
> MZzyv9PQ%26s%3D5%26u%3Dhttp%3A%2F%2Fexample.com IN CAA 0 issue
> "https://clicktime.symantec.com/a/1/WSJJP7Kr5g1Ihc2JaYcIqr4LdXmpgvuwtx
> BN746PBxk=?d=RZrpddyRRTQ154PRoAlI-
> Q9RbRRqmTet1Xm0uCdsU_76X79txFJWMGdDB2vayT_egarHUxCPBwWT5eHf
> BNnpKlx7W1mdGFJxIUnhYLisSSX6EqRMdSKRkKNx4wnVnB7zbllNvijPQiAP0aw
> sDHbVIPazzk2B2mld5wAzznIvkCABWKNmv4EtLSB2Azz831XxmyzQpAOPgdhU
> GamB8As9HkVGdCAEm0-
> YzoAiCxR7FclB5StDbL8Rhxz6EWTqb4AvPLqa_SpYOcFuWsXrevKnJKyzleaW6qb
> Vgl8UPOOx53m6f4Rl0caquHZPVvYzzuh59qwvG64WcemTGe_h9duJ0pbCj-
> UYAwwzKOTBdAqtmAxXqS9xB80aaCuRw8cEMCdeJXpEhXH0x9p045zQRtLwqq
> BgWx9UwSIkOYJT331aaaas4Q%3D%3D&u=http%3A%2F%2Fscanmail.trustwa
> ve.com%2F%3Fc%3D4062%26d%3DgNO32sFHeluIcLm6XdmrAg7jw4lzJFuSdld
> On33-
> ag%26s%3D5%26u%3Dhttp%253a%252f%252fexample%252enet%253b
> foo=bar bar=qux"
> 
>     > > https://clicktime.symantec.com/a/1/P19HMr1W_-AM1Bgx1hv9xaT-
> Y052koOWPbFvWFXceKc=?d=RZrpddyRRTQ154PRoAlI-
> Q9RbRRqmTet1Xm0uCdsU_76X79txFJWMGdDB2vayT_egarHUxCPBwWT5eHf
> BNnpKlx7W1mdGFJxIUnhYLisSSX6EqRMdSKRkKNx4wnVnB7zbllNvijPQiAP0aw
> sDHbVIPazzk2B2mld5wAzznIvkCABWKNmv4EtLSB2Azz831XxmyzQpAOPgdhU
> GamB8As9HkVGdCAEm0-
> YzoAiCxR7FclB5StDbL8Rhxz6EWTqb4AvPLqa_SpYOcFuWsXrevKnJKyzleaW6qb
> Vgl8UPOOx53m6f4Rl0caquHZPVvYzzuh59qwvG64WcemTGe_h9duJ0pbCj-
> UYAwwzKOTBdAqtmAxXqS9xB80aaCuRw8cEMCdeJXpEhXH0x9p045zQRtLwqq
> BgWx9UwSIkOYJT331aaaas4Q%3D%3D&u=http%3A%2F%2Fscanmail.trustwa
> ve.com%2F%3Fc%3D4062%26d%3DgNO32sFHeluIcLm6XdmrAg7jw4lzJFuSdlJ
> PySquaA%26s%3D5%26u%3Dhttp%3A%2F%2Fwww.rfc-
> editor.org%2Ferrata%2Feid5200
>     >
>     > https://clicktime.symantec.com/a/1/guXt-
> wbIajcv9dPXp03AETYKnnGzu7bRQAzwwoTu1BQ=?d=RZrpddyRRTQ154PRoAlI-
> Q9RbRRqmTet1Xm0uCdsU_76X79txFJWMGdDB2vayT_egarHUxCPBwWT5eHf
> BNnpKlx7W1mdGFJxIUnhYLisSSX6EqRMdSKRkKNx4wnVnB7zbllNvijPQiAP0aw
> sDHbVIPazzk2B2mld5wAzznIvkCABWKNmv4EtLSB2Azz831XxmyzQpAOPgdhU
> GamB8As9HkVGdCAEm0-
> YzoAiCxR7FclB5StDbL8Rhxz6EWTqb4AvPLqa_SpYOcFuWsXrevKnJKyzleaW6qb
> Vgl8UPOOx53m6f4Rl0caquHZPVvYzzuh59qwvG64WcemTGe_h9duJ0pbCj-
> UYAwwzKOTBdAqtmAxXqS9xB80aaCuRw8cEMCdeJXpEhXH0x9p045zQRtLwqq
> BgWx9UwSIkOYJT331aaaas4Q%3D%3D&u=http%3A%2F%2Fscanmail.trustwa
> ve.com%2F%3Fc%3D4062%26d%3DgNO32sFHeluIcLm6XdmrAg7jw4lzJFuSdg
> MZzyv9PQ%26s%3D5%26u%3Dhttp%3A%2F%2Fexample.com IN CAA 0 issue
> "https://clicktime.symantec.com/a/1/WSJJP7Kr5g1Ihc2JaYcIqr4LdXmpgvuwtx
> BN746PBxk=?d=RZrpddyRRTQ154PRoAlI-
> Q9RbRRqmTet1Xm0uCdsU_76X79txFJWMGdDB2vayT_egarHUxCPBwWT5eHf
> BNnpKlx7W1mdGFJxIUnhYLisSSX6EqRMdSKRkKNx4wnVnB7zbllNvijPQiAP0aw
> sDHbVIPazzk2B2mld5wAzznIvkCABWKNmv4EtLSB2Azz831XxmyzQpAOPgdhU
> GamB8As9HkVGdCAEm0-
> YzoAiCxR7FclB5StDbL8Rhxz6EWTqb4AvPLqa_SpYOcFuWsXrevKnJKyzleaW6qb
> Vgl8UPOOx53m6f4Rl0caquHZPVvYzzuh59qwvG64WcemTGe_h9duJ0pbCj-
> UYAwwzKOTBdAqtmAxXqS9xB80aaCuRw8cEMCdeJXpEhXH0x9p045zQRtLwqq
> BgWx9UwSIkOYJT331aaaas4Q%3D%3D&u=http%3A%2F%2Fscanmail.trustwa
> ve.com%2F%3Fc%3D4062%26d%3DgNO32sFHeluIcLm6XdmrAg7jw4lzJFuSdld
> On33-
> ag%26s%3D5%26u%3Dhttp%253a%252f%252fexample%252enet%253b
> foo=bar bar=qux"
>     >
>     > or:
>     >
>     > https://clicktime.symantec.com/a/1/guXt-
> wbIajcv9dPXp03AETYKnnGzu7bRQAzwwoTu1BQ=?d=RZrpddyRRTQ154PRoAlI-
> Q9RbRRqmTet1Xm0uCdsU_76X79txFJWMGdDB2vayT_egarHUxCPBwWT5eHf
> BNnpKlx7W1mdGFJxIUnhYLisSSX6EqRMdSKRkKNx4wnVnB7zbllNvijPQiAP0aw
> sDHbVIPazzk2B2mld5wAzznIvkCABWKNmv4EtLSB2Azz831XxmyzQpAOPgdhU
> GamB8As9HkVGdCAEm0-
> YzoAiCxR7FclB5StDbL8Rhxz6EWTqb4AvPLqa_SpYOcFuWsXrevKnJKyzleaW6qb
> Vgl8UPOOx53m6f4Rl0caquHZPVvYzzuh59qwvG64WcemTGe_h9duJ0pbCj-
> UYAwwzKOTBdAqtmAxXqS9xB80aaCuRw8cEMCdeJXpEhXH0x9p045zQRtLwqq
> BgWx9UwSIkOYJT331aaaas4Q%3D%3D&u=http%3A%2F%2Fscanmail.trustwa
> ve.com%2F%3Fc%3D4062%26d%3DgNO32sFHeluIcLm6XdmrAg7jw4lzJFuSdg
> MZzyv9PQ%26s%3D5%26u%3Dhttp%3A%2F%2Fexample.com IN CAA 0 issue
> "https://clicktime.symantec.com/a/1/WSJJP7Kr5g1Ihc2JaYcIqr4LdXmpgvuwtx
> BN746PBxk=?d=RZrpddyRRTQ154PRoAlI-
> Q9RbRRqmTet1Xm0uCdsU_76X79txFJWMGdDB2vayT_egarHUxCPBwWT5eHf
> BNnpKlx7W1mdGFJxIUnhYLisSSX6EqRMdSKRkKNx4wnVnB7zbllNvijPQiAP0aw
> sDHbVIPazzk2B2mld5wAzznIvkCABWKNmv4EtLSB2Azz831XxmyzQpAOPgdhU
> GamB8As9HkVGdCAEm0-
> YzoAiCxR7FclB5StDbL8Rhxz6EWTqb4AvPLqa_SpYOcFuWsXrevKnJKyzleaW6qb
> Vgl8UPOOx53m6f4Rl0caquHZPVvYzzuh59qwvG64WcemTGe_h9duJ0pbCj-
> UYAwwzKOTBdAqtmAxXqS9xB80aaCuRw8cEMCdeJXpEhXH0x9p045zQRtLwqq
> BgWx9UwSIkOYJT331aaaas4Q%3D%3D&u=http%3A%2F%2Fscanmail.trustwa
> ve.com%2F%3Fc%3D4062%26d%3DgNO32sFHeluIcLm6XdmrAg7jw4lzJFuSdld
> On33-
> ag%26s%3D5%26u%3Dhttp%253a%252f%252fexample%252enet%253b
> foo=bar; bar=qux"
>     >
>     > https://clicktime.symantec.com/a/1/oeSHiU8l3ajgJiEMVtTF83-
> EFY63Rq8bkGOhkAfEU4w=?d=RZrpddyRRTQ154PRoAlI-
> Q9RbRRqmTet1Xm0uCdsU_76X79txFJWMGdDB2vayT_egarHUxCPBwWT5eHf
> BNnpKlx7W1mdGFJxIUnhYLisSSX6EqRMdSKRkKNx4wnVnB7zbllNvijPQiAP0aw
> sDHbVIPazzk2B2mld5wAzznIvkCABWKNmv4EtLSB2Azz831XxmyzQpAOPgdhU
> GamB8As9HkVGdCAEm0-
> YzoAiCxR7FclB5StDbL8Rhxz6EWTqb4AvPLqa_SpYOcFuWsXrevKnJKyzleaW6qb
> Vgl8UPOOx53m6f4Rl0caquHZPVvYzzuh59qwvG64WcemTGe_h9duJ0pbCj-
> UYAwwzKOTBdAqtmAxXqS9xB80aaCuRw8cEMCdeJXpEhXH0x9p045zQRtLwqq
> BgWx9UwSIkOYJT331aaaas4Q%3D%3D&u=https%3A%2F%2Fscanmail.trustw
> ave.com%2F%3Fc%3D4062%26d%3DgNO32sFHeluIcLm6XdmrAg7jw4lzJFuSdl
> FIyn6uOA%26s%3D5%26u%3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdra
> ft-ietf-acme-caa-03%23page-9
>     >
>     > https://clicktime.symantec.com/a/1/e4GMdQoD7tFbx08-
> UGuLKKtPdCFSB5rS2W-lBYmcerE=?d=RZrpddyRRTQ154PRoAlI-
> Q9RbRRqmTet1Xm0uCdsU_76X79txFJWMGdDB2vayT_egarHUxCPBwWT5eHf
> BNnpKlx7W1mdGFJxIUnhYLisSSX6EqRMdSKRkKNx4wnVnB7zbllNvijPQiAP0aw
> sDHbVIPazzk2B2mld5wAzznIvkCABWKNmv4EtLSB2Azz831XxmyzQpAOPgdhU
> GamB8As9HkVGdCAEm0-
> YzoAiCxR7FclB5StDbL8Rhxz6EWTqb4AvPLqa_SpYOcFuWsXrevKnJKyzleaW6qb
> Vgl8UPOOx53m6f4Rl0caquHZPVvYzzuh59qwvG64WcemTGe_h9duJ0pbCj-
> UYAwwzKOTBdAqtmAxXqS9xB80aaCuRw8cEMCdeJXpEhXH0x9p045zQRtLwqq
> BgWx9UwSIkOYJT331aaaas4Q%3D%3D&u=https%3A%2F%2Fscanmail.trustw
> ave.com%2F%3Fc%3D4062%26d%3DgNO32sFHeluIcLm6XdmrAg7jw4lzJFuSdg
> QUz3v8bQ%26s%3D5%26u%3Dhttps%3A%2F%2Fgithub.com%2Fletsencrypt%
> 2Fboulder%2Fpull%2F3145%2Ffiles%23diff-
>     > https://clicktime.symantec.com/a/1/Op2fbuRdBuUkj-Y9VkPB3yT4ud-
> Nr0bBS0NRCEoC6mQ=?d=RZrpddyRRTQ154PRoAlI-
> Q9RbRRqmTet1Xm0uCdsU_76X79txFJWMGdDB2vayT_egarHUxCPBwWT5eHf
> BNnpKlx7W1mdGFJxIUnhYLisSSX6EqRMdSKRkKNx4wnVnB7zbllNvijPQiAP0aw
> sDHbVIPazzk2B2mld5wAzznIvkCABWKNmv4EtLSB2Azz831XxmyzQpAOPgdhU
> GamB8As9HkVGdCAEm0-
> YzoAiCxR7FclB5StDbL8Rhxz6EWTqb4AvPLqa_SpYOcFuWsXrevKnJKyzleaW6qb
> Vgl8UPOOx53m6f4Rl0caquHZPVvYzzuh59qwvG64WcemTGe_h9duJ0pbCj-
> UYAwwzKOTBdAqtmAxXqS9xB80aaCuRw8cEMCdeJXpEhXH0x9p045zQRtLwqq
> BgWx9UwSIkOYJT331aaaas4Q%3D%3D&u=https%3A%2F%2Fscanmail.trustw
> ave.com%2F%3Fc%3D4062%26d%3DgNO32sFHeluIcLm6XdmrAg7jw4lzJFuSdg
> ofny-
> qPw%26s%3D5%26u%3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistin
> fo%2Fspasm
>