<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 19, 2017 at 11:25 AM, Gervase Markham via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 19/10/17 15:44, Jeremy Rowley wrote:<br>
> This seems to indicate SRV restrictions are something new compared to domain<br>
> name constraints. I suppose it's largely up to UA's implementing the RFC at<br>
> this point.<br>
<br>
</span>Do we know anyone who has?<br>
<br>
Is strikes me (at first glance, and perhaps someone more technical will<br>
tell me why this is actually a terrible idea) that making DNS name<br>
constraints apply to the DNS portion of SVRNames in implementations<br>
might solve a lot of the problems with "missing restrictions" that we<br>
are otherwise going to have.</blockquote><div><br></div><div>There are two approaches to doing subject name validation (in an RFC 6125 sense):<br></div><div><br></div><div>- Option 1: The API contract of your (hopefully RFC5280) path validator provides the hostname-to-be-verified as well as the presented chain (to do path building and/or validation on)</div><div>  - In this scenario, it's possible to extend the internal library to apply the constraints you mention, although this violates the semantics of RFC5280 (that is, it'd be a non-standard deviation)</div><div>  - Examples of this pattern include Security.framework on macOS and CAPI2 on Windows.</div><div>  - One notable challenge with this is that existing APIs would have to be extended. This is because they presently take a mostly opaque-hostname (assuming that it will be in the 'host' form extracted from a URL) and determine what the appropriate SAN to match against based on the format of the name. That is, some APIs will see if the hostname parses as an IP literal and match against an iPAddress SAN, otherwise match against a dNSName SAN. An SRVName would be indistinguishable from a DNSName, so the API would need to be extended to indicate what the caller's intent was and what service name they're attempting to match against.</div><div><br></div><div>- Option 2: The API contract is such that you use an RFC5280 path validator, and then extract the SANs at an application level to perform matching.</div><div>  - In this scenario, you call into an opaque 5280-box, and then if things validate, you can reliably use the extracted SANs.</div><div>  - Examples of this pattern include many programming languages' libraries (e.g. PHP, Python) and applications based on Open/Boring/LibreSSL</div><div>  - In this scenario, to support the solution you describe, each of these languages would need to implement their own support for nameConstraint parsing to extract the effective DNSName constraints from the validated chain, and then see whether or not those constraints interact with the SRVNames.</div><div><br></div><div>While this may seem appealing, <a href="https://nameconstraints.bettertls.com">https://nameconstraints.bettertls.com</a> demonstrates many implementations' challenges in having commonNames subject to the dNSName or iPAddress name constraints - and the security risks created - so one might assume the same situation would be prevalent, especially for Option 2-style implementors. That's not to say it's impossible - just that it adds considerable complexity.</div><div><br></div><div>There has been various interest in the past in exploring the functionality of nameConstraints in particular to support such extensions. One consideration would be the introduction of an (optionally-critical) new extension that indicates whether nameConstraints behave as specified in 5280 (a blacklist - that is, everything not specifically enumerated is permitted) to a new form of whitelist - in which only the names that are constrained are permitted. The behaviour of such an extension would work as follows:</div><div>- If marked non-critical, implementations which don't recognize this extension would behave as 5280</div><div>- If marked non-critical, Option 1 implementations which recognize this extension can reject certificates that contain other name types that are not constrained, whether or not they recognize the underlying name type.</div><div>- If marked non-critical, Option 2 implementations which recognize this extension can scan the extensions in the verified chain and determine a non-overlapping set of nameConstraints, without having to fully reimplement nameConstraint logic</div><div>- If marked critical, implementations which don't recognize this extension would reject the chain (which would be the intended behaviour, as part of a security-critical restriction)</div><div>- If marked critical, Option 1 implementations would work as if non-critical</div><div>- If marked critical, Option 2 implementations would likely fail to work, due to the underlying 5280 validation library failing to detect this extension</div><div><br></div><div>In any event, that at least hopefully captures the challenge, and why the 'simple' solution is likely not as simple as it appears.</div></div><br></div></div>