Hi! first off, thanks a lot for putting in the work. I'm not in the office this week, but I do have some notes, though: * this kind of feature should be gated behind a config setting. i'd like to have a key `identifierTypes` that defaults to `dns` only, and the admin must explicitly enable `ip`s. this is because this doesn't mesh well with the `verifyPTR` (et.al) restrictions we allow to place on potential acme clients. * by introducing the ChallengeIdentifier class (replacing plain `str`s) the interface between serles-core and the backends change. as you probably noticed, that forced you to modify the code in a bunch of places. we must avoid this change at all costs, as this interface is publicly documented and external/private backends (which we know exist) depend on this API not to change. essentially, this class implements a named tuple for ident type and value; we already track that information in the DB/models Identifier class. there are also a bunch of seemingly redundant isinstance checks * as a consequence of not breaking API, the backend-specific stuff e.g. happening in ejbca_identifier() must be contained within that backend. * as far as i can see, the rfc only allows ip *addresses*, not networks! * the spec is also pretty keen on making sure that the formatting of ip addresses is well-defined - this needs to be ensured by the code. * §6 talks about some special requirements in the alpn challenge, which we need to handle. * please keep this PR focused on the feature and don't add type hints at the same time. (i personally am not very fond of them, since they add a lot of noise. independent of that, it makes diffs larger and following them harder) * i know this is still wip, but just so we don't forget: this feature needs tests (we aim for 100% code coverage through unit tests) * if you can, i'd prefer rebased commits between reviews :) * note to self: the new models.IdentifierType entry causes a change in the generated SQL schema. this is unavoidable. we must document that properly in changelog, because users might need to `ALTER TABLE identifier`! please don't be discouraged by the length of my notes - adding this feature requires us to remove a number of implicit assumptions in the code base. I'm sure we can work though this together :)

yes, you'll have to pass strings around and check their contents in the backend(s).

they support a lot of stuff that's not covered by ACME :^) let's stick to adresses only.

we check the requested identifiers earlier, when creating the order. no need to check the csr, since if it contains additional identifiers, we will reject it anyways Message ID: ***@***.***>