Hey all, Following up on my comments at the mic today... It seems like we have few questions here:
1. What identifiers do we envision going in the certificate? 2. What identifiers should be validated in ACME to support issuance for those identifiers? 3. What challenges should be used to validate the ACME identifiers? I agree with Tim and Alexey that it would be better to validate specific ports, but that may not be the world we live in today. TBH, though, given that people are going to be writing fresh code for ACME, I'm inclined to write the spec for the world we want, with the idea that CAs can update their practices to go with the new code. ISTM the architecturally clean way to do this is as follows: 1. Target the use case where SRVNames are in the certificate 2. Define an "srv" identifier type that encodes a name and a port number 3. Define the challenge types in the document as valid for the "srv" identifier type The main gap that leaves is that it doesn't define how to validate a "dns" identifier with an email protocol. (Here I'm assuming that there are mail agents that can't do SRVName, so you need a dNSName) Maybe you could say that the email protocol challenges are good for "dns" identifiers as well, but in that case, the ports for those challenges should be nailed down to the default ports. Hope that helps, --Richard
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
