SC-XX: Process RFC 8657 CAA Parameters #567
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
robstradling
requested changes
Jan 3, 2025
Co-authored-by: Rob Stradling <[email protected]>
Co-authored-by: Rob Stradling <[email protected]>
- validationmethod labels must comply with section 4 of RFC 8657 - Update effective date format - Add 'this section' to CPS requirements.
geegeea
reviewed
Jan 8, 2025
wthayer
changed the title
wthayer
changed the title
Contributor
Author
|
Updated based on 24-Jan Validation meeting:
|
Contributor
|
This also seems to address #352 |
CBonnell
reviewed
Feb 11, 2025
Co-authored-by: Corey Bonnell <[email protected]>
shuvosarker22
approved these changes
Feb 27, 2025
wthayer
changed the title
aarongable
reviewed
Mar 13, 2025
docs/BR.md
Outdated
|
|
||
| In addition, *Effective March 15, 2026*, if the CA processes the accounturi and validationmethods parameters: | ||
| * If the CA accepts certificate requests via any protocol other than the ACME protocol defined in RFC 8555, the CA MUST define the supported format(s) of the accounturi in Section 4.2 of their CP and/or CPS. | ||
| * If the CA accepts certificate requests via any protocol other than the ACME protocol defined in RFC 8555, the CA MUST interpret and process validationmethods labels formed by concatenating the string ‘ca-tbr-’ with the BR 3.2.2.4 subsection number, e.g. ‘ca-tbr-7’ represents the DNS method described in TLS BR 3.2.2.4.7. If a CA performs domain validation using a mechanism that can be represented by multiple labels (e.g. 'dns-01' and 'ca-tbr-7'), the CA SHOULD accept any of the labels as granting permission to issue. |
Contributor
There was a problem hiding this comment.
Echoing my comment from the call this morning: I think this sentence comes a little close to the line of "well, CA Foo doesn't quite implement RFC 8555 (e.g. they don't provide a list of all orders for an account), so they qualify here and need to support these validationmethods labels". I think it's clear that this is not the intent of this sentence, so I'm wondering if there's any minor change we can make to make this clear.
orangepizza
reviewed
Apr 18, 2025
docs/BR.md
Outdated
|
|
||
| In addition, *Effective March 15, 2026*, if the CA processes the accounturi and validationmethods parameters: | ||
| * If the CA accepts certificate requests via any protocol other than the ACME protocol, the CA MUST define the supported format(s) of the accounturi in Section 4.2 of their CP and/or CPS. | ||
| * If the CA accepts certificate requests via any protocol other than the ACME protocol, the CA MUST interpret and process validationmethods labels formed by concatenating the string ‘ca-tbr-’ with the BR 3.2.2.4 subsection number, e.g. ‘ca-tbr-7’ represents the DNS method described in TLS BR 3.2.2.4.7. If a CA performs domain validation using a mechanism that can be represented by multiple labels (e.g. 'dns-01' and 'ca-tbr-7'), the CA SHOULD accept any of the labels as granting permission to issue. |
There was a problem hiding this comment.
- Can 'http-01' considered to represent 3.2.2.4.18? while it'd strictly mean 3.2.2.4.19, it's reasonable to assume user meant any http update challenges.
- Can ACME running CA use 'ca-tbr-19' as permission to use http-01 challenge? this paragraph doesn't apply if a CA doesn't offer something else, isn't it?
Contributor
There was a problem hiding this comment.
- Can 'http-01' considered to represent 3.2.2.4.18? while it'd strictly mean 3.2.2.4.19, it's reasonable to assume user meant any http update challenges.
No, 3.2.2.4.18 and 3.2.2.4.19 are in fact different validation methods (the expect the token to be in a different location and to look different) so permission to use one method cannot be interpreted as permission to use the other.
- Can ACME running CA use 'ca-tbr-19' as permission to use http-01 challenge? this paragraph doesn't apply if a CA doesn't offer something else, isn't it?
Yes, this paragraph simply says that non-ACME CAs MUST respect those designations; therefore an ACME CA MAY also respect them, as long as it appropriately documents that fact in its CPS.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Update 3.2.2.8 to require that CAs process CAA accounturi and validationmethod parameters defined in RFC 8657
Fixes #353