[Servercert-wg] Future Cleanup Items

[Ryan Sleevi]

I just wanted to let folks know I filed two new issues on GitHub to track
potential cleanups for the future, including suggested fixes. These aren't
as pressing as other matters, but I wanted to make sure we don't lose sight
of them.

The first, https://github.com/cabforum/documents/issues/159 , is hopefully
minor - just a small typo in Section 7.1.5.

The second, https://github.com/cabforum/documents/issues/160 , is
potentially more meaningful, and relates to the use of Internal Names and
Reserved IP Addresses within the nameConstraints extension, particularly
the permittedSubtrees.

While we have a prohibition on the use of such names, they're placed within
the subjectAltName section of the profile, while also expressing a
requirement on the commonName. The added requirement on the commonName
isn't inherently problematic, since a commonName must be a value from the
subjectAltName, but it leaves it ambiguous whether or not a CA can issue a
subordinate CA with a nameConstraint indicating an Internal Name or
Reserved IP Address.

The common-sense approach would say that, even if they could, if that
subordinate CA issued any such certificates within any name or IP in that
range, they would be misissued, because of the SAN constraint. As such, no
CA should ever do so. However, that wording may not be clear to folks, and
so I filed an issue to track resolving it.

As suggested on that issue, the easiest answer would be to lift that
restriction out of the certificate profile (Section 7) and move it into the
validation requirements (Section 3.2.2.4/3.2.2.5). The profile could, for
each of the applicable fields (SAN, CN, NC:PermittedSubtrees) require all
iPAddresses/dNSNames be validated according to 3.2.2.4 / 3.2.2.5

This would also resolve an issue where 3.2.2.5 attempts to restrict the
profile for name Constraints, but in a way that is ambiguous, given that it
starts with "Note:" and says "may", leaving the interpretation of 7.1.5's
validation requirements somewhat ambiguous.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200228/2af3e85c/attachment.html>