<div dir="ltr">As a follow-up to our call today, I filed <a href="https://github.com/cabforum/servercert/issues/268">https://github.com/cabforum/servercert/issues/268</a> to capture the discussion we had around SRVNames, so that we can explore steps going forward.<div><br></div><div>While it is not a priority of Google to add support for SRVNames, relative to the other important work still to be done in the Forum, we're broadly supportive of the goal.</div><div><br></div><div>Our proposed sequencing is this:</div><div><ol><li>A transition path so that existing technically constrained sub-CAs, which are not constrained by SRVNames, are phased out (e.g. revoked and replaced in time)</li><li>Support for SRVNames added to browser clients. This cannot happen before 1, due to the security risk otherwise.</li><li>Support for CAs issuing SRVNames</li><ul><li>At a minimum, CAs MUST validate the Domain Portion in a manner consistent with validating a dNSName</li><li>It's unclear what policies should be developed for service names, particularly for those using the "host-based" demonstrations of control (e.g. 3.2.2.4.17/.18) - ALPN and .well-known. One path might be mapping the port used for the validation to the IANA well-known port registry (e.g. 80 or 443 becomes "http" SRVName, 465/587 becomes "smtp", etc)</li></ul></ol><div>Since there was a desire to keep discussing, I said I'd file a GitHub issue and discuss on list.</div></div></div>