Re: [edk2-devel] [RFC v1 5/4] CryptoPkg/TlsLib: accept peer certs via both DNS names and IP addresses

["Laszlo Ersek" <lersek@redhat.com>]

On 10/25/19 04:12, Wu, Jiaxin wrote:
>>>> Reference [2] advises to put the IP address in both CN and
>>>> SAN.iPAddress
>>>> for best compatibility, and that would be fine, for
>>>> X509_VERIFY_PARAM_set1_ip(). But the word "only" in [3] is really bad
>>>> for X509_VERIFY_PARAM_set1_ip().
> 
> That was also what I suggested before:
> "Now, to resolve the problem, I think the *best compatibility* can actually be reached by setting the IP address both as iPAddress and dNSName in SAN..."
> 
> Above setting means to call X509_VERIFY_PARAM_set1_ip and X509_VERIFY_PARAM_set1_host parallelly instead of exclusively (if else).

I think this is a misunderstanding.

AIUI, the "best compat" idea applies to certificate *creation*. IOW, the
IP address should be placed in both elements, in the certificate.

But it does not apply to certificate *verification*. RFC-2818
<https://tools.ietf.org/html/rfc2818#section-3.1> is clear about the
matching:

    In some cases, the URI is specified as an IP address rather than a
    hostname. In this case, the iPAddress subjectAltName must be present
    in the certificate and must exactly match the IP in the URI.

IIUC this is also what David argues for:

>>> I don't believe it's true, and it conflicts with what's in [2] which
>>> suggests that you do it properly *and* put it in the legacy CN for the
>>> benefit of broken clients.
>>>
>>> None of this convinces me that EDK2 should deliberately be one of those
>>> "broken clients". Just fix it. Let people worry about compatibility
>>> with historical buggy versions of proprietary operating systems when
>>> they issue their certs.
>>>

Ah, I see you commented too:

> Okay, good point here, it's also make sense to me.

OK then!

Thanks
Laszlo