[cabfpub] IP addresses in SANs
sleevi at google.com
Tue Aug 18 17:13:26 MST 2015
On Tue, Aug 18, 2015 at 8:13 AM, Gervase Markham <gerv at mozilla.org> wrote:
> Hi everyone,
> https://bugzilla.mozilla.org/show_bug.cgi?id=1148766 is Mozilla's
> investigation of certs using IP addresses in SANs.
> Our engineer says that as long as you do the proper SANs first and the
> ones with IP addresses encoded as DNS names last, then it should work
> everywhere, presumably as Firefox will find the good ones (which match)
> and accept them, and software which doesn't understand them will skip
> over them and use the broken ones.
> Please let us know if your testing says something different.
Are you suggesting/endorsing that CAs violate the Baseline Requirements,
which requires RFC 5280 conformance, by improperly encoding IP addresses
into the dNSName field?
Section 126.96.36.199 of RFC 5280 has this to say:
When the subjectAltName extension contains a domain name system
label, the domain name MUST be stored in the dNSName (an IA5String).
The name MUST be in the "preferred name syntax", as specified by
Section 3.5 of [RFC1034] and as modified by Section 2.1 of
That statement doesn't leave any room for encoding an IPv4 address - and
especially not an IPv6 address - within that field. Any CA that does do
that, while understandably targeted at compatibility reasons, is failing to
adhere to the Baseline Requirements. For those who haven't read RFC1034, it
establishes the LDH syntax and notion of labels. A label must begin with a
letter according to 1034 rules. 1123 relaxed this to allow labels to begin
with a letter or digit, but this introduction of ambiguity (is it a label
or an IP octet) was only permitted because of the presumption of IANA TLD
policies (since reflected by ICANN's TLD policies) that no TLD will begin
with a digit. This comes from Section 2.1. of RFC 1123,
However, a valid host name can never
have the dotted-decimal form #.#.#.#, since at least the
highest-level component label will be alphabetic.
The argument seemingly provided on the bug is for compatibility with
Microsoft products prior to Windows 10 - which lack support for iPAddress
subjectAltNames, but which accept IP addresses in both the common name and
in the dNSName subjectAltNames because they treat the name to match as a
(mostly) opaque string. However, the compatibility issue does not
necessitate violating the Baseline Requirements or RFC 5280, as a CA could
fully adhere to the BRs by expressing an iPAddress SAN with the IP in the
common name. The absence of a dNSName SAN (and the lack of support for
iPAddress SAN) will result in the CN being treated as a "domain", and then
matching with the opaque string.
It does mean that you _cannot_ mix and match hostnames and IP addresses in
publicly trusted certificates, due to the compatibility issues, but I
thought it was well understood by CAs as a necessary tradeoff in order to
conform to the relevant technical standards and audit criteria.
While Mozilla's handling of such improperly formed certificates for
non-publicly trusted certificates is arguably entirely reasonable (given
how awful many such internal systems are at producing RFC-conforming
certificates), for publicly trusted CAs, non-conformance is a serious issue.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public