# CAA validation-methods invalid format **URL:** \ **Category:** Help\ **Created:** [June 6, 2018, 5:43pm UTC](https://community.letsencrypt.org/t/caa-validation-methods-invalid-format/63804 "2018-06-06T17:43:48Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![arkadiyt](https://avatars.discourse-cdn.com/v4/letter/a/278dde/32.png) [@arkadiyt](https://community.letsencrypt.org/u/arkadiyt)\ **Post date:** [June 6, 2018, 5:43pm UTC](https://community.letsencrypt.org/t/caa-validation-methods-invalid-format/63804/1 "2018-06-06T17:43:48Z")
Hi, LetsEncrypt just announced staging support for CAA validation methods here: > [@ACME-CAA "validationmethods" support](https://community.letsencrypt.org/t/acme-caa-validation-methods-support/63125): > > O… I tried to test this out by setting my CAA to `issue "letsencrypt.org\; validation-methods=dns-01"` but Route53 threw a validation error. I thought they were parsing the record incorrectly but after posting on the AWS forums it turns out that they are correct, as the CAA standard only allows alphanumeric characters in the parameter names, so the hyphen in "validation-methods" goes against the spec. Not sure this is the right place to post this (seems like more of a spec issue than a LetsEncrypt issue), but thought I'd raise it here and it might reach the right people ---
**Author:** ![cpu](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/cpu/32/84514_2.png) [@cpu](https://community.letsencrypt.org/u/cpu)\ **Post date:** [June 6, 2018, 5:48pm UTC](https://community.letsencrypt.org/t/caa-validation-methods-invalid-format/63804/2 "2018-06-06T17:48:53Z")
Hi @arkadiyt > [@arkadiyt](#): > > the hyphen in “validation-methods” goes against the spec. 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](https://tools.ietf.org/html/draft-ietf-lamps-rfc6844bis-00) 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](https://www.rfc-editor.org/errata_search.php?rfc=6844) 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](https://tools.ietf.org/html/rfc6844#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! ---
**Author:** ![arkadiyt](https://avatars.discourse-cdn.com/v4/letter/a/278dde/32.png) [@arkadiyt](https://community.letsencrypt.org/u/arkadiyt)\ **Post date:** [June 6, 2018, 6:08pm UTC](https://community.letsencrypt.org/t/caa-validation-methods-invalid-format/63804/3 "2018-06-06T18:08:34Z")
Thanks for the reply @cpu - makes sense. I’m feeling like a bit of a pinball at this point but I’ll reply back on the AWS thread requesting they update their validation ---
**Author:** ![cpu](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/cpu/32/84514_2.png) [@cpu](https://community.letsencrypt.org/u/cpu)\ **Post date:** [June 6, 2018, 6:10pm UTC](https://community.letsencrypt.org/t/caa-validation-methods-invalid-format/63804/4 "2018-06-06T18:10:09Z")
> [@arkadiyt](#): > > I’m feeling like a bit of a pinball at this point Life on the bleeding edge 🙂 ACME-CAA is very new! As far as I know this may be the first concrete implementation. ---
**Author:** ![cpu](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/cpu/32/84514_2.png) [@cpu](https://community.letsencrypt.org/u/cpu)\ **Post date:** [June 28, 2018, 6:31pm UTC](https://community.letsencrypt.org/t/caa-validation-methods-invalid-format/63804/5 "2018-06-28T18:31:26Z")
Hi again @arkadiyt, Good news. The standards community decided that changing the ACME-CAA draft to remove the illegal dash character was the best way to resolve this. A new version of the draft, [draft-05](https://tools.ietf.org/html/draft-ietf-acme-caa-05) was published to change to `validationmethods` and `accounturi` instead of `validation-methods` and `account-uri`. The Let’s Encrypt implementation was updated to use the dash-less parameter names today. You should be able to create your Route53 records without error now. Thanks for your patience! ---
**Author:** ![arkadiyt](https://avatars.discourse-cdn.com/v4/letter/a/278dde/32.png) [@arkadiyt](https://community.letsencrypt.org/u/arkadiyt)\ **Post date:** [June 28, 2018, 6:45pm UTC](https://community.letsencrypt.org/t/caa-validation-methods-invalid-format/63804/6 "2018-06-28T18:45:32Z")
Matt Nordhoff also updated the AWS forums thread - thank you both! ---
**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\ **Post date:** [July 28, 2018, 6:45pm UTC](https://community.letsencrypt.org/t/caa-validation-methods-invalid-format/63804/7 "2018-07-28T18:45:34Z")
Closed on July 28, 2018, 6:45pm UTC This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.