Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Re-org discussion (Jan 29) #167

Open
ShivanKaul opened this issue Jan 29, 2025 · 1 comment
Open

Re-org discussion (Jan 29) #167

ShivanKaul opened this issue Jan 29, 2025 · 1 comment

Comments

@ShivanKaul
Copy link
Collaborator

ShivanKaul commented Jan 29, 2025

What do we need to have in the document?
Can we live with cutting out the CNAME and time discussion?

In specific (and not in totality), I'd like to see removed:

  • anything about CNAME, other than an explanation about why it is dangerous to rely on
  • anything about intermediaries because they grossly complicate the idea of someone controlling a domain
  • requirements on randomness length; for many scearios, 44 bits of entropy is just fine and can be easily typed
  • requirements on time-bound checking, other than a description of why you might or might not want it

Decision: We should keep delegated domain techniques.

Decision: 5.2.1. Scope Indication just be a different draft, we take that to ACME. See: https://cabforum.org/2025/01/28/ballot-sc084-dns-labeled-with-acme-account-id-validation-method/#ballot-contents talking about our draft.

In 6.4. Domain Control Validation Supporting Multiple Intermediaries, we can say that you can hash the identifier-token, like what's done in https://datatracker.ietf.org/doc/html/draft-ietf-acme-dns-account-label-00#section-3.2.

Remove: A.1.2.4. Constraints on Domains and Subdomains

Delete Appendix? Just ask the WG.

Delete 4. Scope of Validation. Move 4.1. Domain Boundaries to Appendix.

Re-name 5.4. Time-bound checking, to Re-validating control over a domain, and then we should have a SHOULD, and in Recommendations. Just make this more concise.

Delete 5.1.2. Metadata For Expiry? No one is using this today so not a BCP? Other ways of doing expiry. Maybe put in Appendix, as a thing that you could do.

Organization:

  1. Recommendations: DCV record (TODO: metadata?), random token, owner name, delegated, intermediaries,
  2. Operational: time-bound, TTL considerations, 5.6. Specification of Validation Records

Add Tim as co-author!

@moonshiner
Copy link
Contributor

reduce the examples in Metadata For Expiry - one or two at most

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants