Well, unfortunately the situation is a bit awkward. The ACME-CAA draft specifies this parameter with the dash. The CAA RFC (RFC 6844) has contradictory requirements (in addition to other, more significant errata).
RFC 6844 BIS will address the inconsistency by updating the allowed characters in the CAA record.
There’s not a clear right answer here but my own view is that RFC 6844 BIS is the future and we should do our best to plan for that instead of over-fitting the legacy. We need RFC 6844 BIS to address other RFC 6844 errata and since it will allow the
- character there isn’t much value in amending the ACME-CAA draft to remove the hyphen or adjusting our implementation. We would be stuck supporting both the workaround
validationmethods for CAA 6844 and the
validation-methods for CAA 6844 BIS.
I’m sympathetic to Amazon’s decision to strictly enforce the RFC 6844 character set. There’s perhaps an argument to be made that 6844 leaves the door open for the issuer (Let’s Encrypt) to define things as they please: “The semantics of issuer-parameters are determined by the issuer alone” (end of Section 5.2) but that’s pretty obnoxious RFC laywering You might be stuck having to choose a different DNS provider in the short term if you’re interested in testing this feature, it will be some time before CAA 6844 BIS is the law of the land and likely to sway Amazon’s developers.
edit: Most of this reply is no longer accurate. See my updated comment below RE: ACME-CAA draft-05.
Hope that helps!