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

What exactly does "share identifiers" mean? #57

Closed
robstradling opened this issue Feb 27, 2024 · 2 comments · Fixed by #64
Closed

What exactly does "share identifiers" mean? #57

robstradling opened this issue Feb 27, 2024 · 2 comments · Fixed by #64

Comments

@robstradling
Copy link
Contributor

I wish I'd seen 8b464ff (Remove "a preponderance of") yesterday, before I spent time mulling over how to interpret it! :-)

I'm not sad to see that somewhat archaic word ditched, but the wording after that commit leaves me even more unsure of what's expected.

With "a preponderance of", I'd concluded yesterday that >50% of the identifiers in the newOrder request must match identifiers in the certificate identified by replaces, or else the Server would ignore replaces. (I'd also concluded that "preponderance" was vague enough that it would also make sense for that ">50%" figure to be configurable, per Server, anywhere between ">50%" and "100%").

But what exactly does "share identifiers" mean?
Does the newOrder request have to have the exact same set of identifiers as the certificate identified by replaces, with zero identifiers dropped and zero identifiers added? (If so, then I'd suggest tightening the wording to "share the exact same set of identifiers" or something similar).
Or is it intended that defining the meaning of "share identifiers" should be left to each individual Server's policy? (If so, then I'd suggest adding to wording to explicitly say this).

@aarongable
Copy link
Owner

Yeah, I changed it from "share a preponderance of identifiers with" to just "share identifiers with" to allow more freedom in server policy. I think that all of the following would be reasonable policies for a server to have:

  1. The replacement must have exactly the same identifiers
  2. The replacement must be a strict subset of the identifiers (i.e. all names have been issued for previously, but allowing names to be discontinued)
  3. The replacement must share most / a preponderance of the identifiers (essentially "shrug, seems like a spiritual successor")
  4. The replacement must share at least one identifier (as long as any name is being renewed, it counts)

I agree that it should be clearer that exactly what approach is taken is left up to server policy. I'll work on some language.

@robstradling
Copy link
Contributor Author

I agree that leaving it up to server policy makes sense, given that what a server should do with an accepted replaces value is also left up to server policy.

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

Successfully merging a pull request may close this issue.

2 participants