From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28])
 by mx.groups.io with SMTP id smtpd.web11.5772.1571405162227357892
 for <devel@edk2.groups.io>;
 Fri, 18 Oct 2019 06:26:02 -0700
Authentication-Results: mx.groups.io;
 dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com)
Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx1.redhat.com (Postfix) with ESMTPS id 9226C10C0943;
	Fri, 18 Oct 2019 13:26:01 +0000 (UTC)
Received: from lacos-laptop-7.usersys.redhat.com (unknown [10.36.118.33])
	by smtp.corp.redhat.com (Postfix) with ESMTP id F0BC75C223;
	Fri, 18 Oct 2019 13:25:59 +0000 (UTC)
Subject: Re: [edk2-devel] [RFC v1 5/4] CryptoPkg/TlsLib: accept peer certs via both DNS names and IP addresses
To: David Woodhouse <dwmw2@infradead.org>, devel@edk2.groups.io,
 "Wu, Jiaxin" <jiaxin.wu@intel.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>,
 "Wang, Jian J" <jian.j.wang@intel.com>, Richard Levitte
 <levitte@openssl.org>, Sivaraman Nainar <sivaramann@amiindia.co.in>
References: <20190927034441.3096-1-Jiaxin.wu@intel.com>
 <20191015230839.27708-1-lersek@redhat.com>
 <895558F6EA4E3B41AC93A00D163B727416F81251@SHSMSX107.ccr.corp.intel.com>
 <56d17f5f-8433-2ec5-924c-bade642ac5a7@redhat.com>
 <139da0c5a4684b76809fa19acc007f4699e3eb28.camel@infradead.org>
 <f89ddc3b-cbc8-01f7-f419-0984ad168dfb@redhat.com>
 <a83f1ff8059088de69a15edbe02cae3b4faa8173.camel@infradead.org>
 <81cf523b-1cc0-9df1-cbb3-c16a78e26a55@redhat.com>
 <c7e456ec1f6f9b4499df9c3624e933912f303b1e.camel@infradead.org>
 <64366517-6a4e-41da-0ab5-6dea3580bf30@redhat.com>
 <ed1a2af928ab377912936115d1f66e2fd104b4bb.camel@infradead.org>
From: "Laszlo Ersek" <lersek@redhat.com>
Message-ID: <7e15bed3-ef3c-0609-e720-e35ffcfc3a0e@redhat.com>
Date: Fri, 18 Oct 2019 15:25:59 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <ed1a2af928ab377912936115d1f66e2fd104b4bb.camel@infradead.org>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.66]); Fri, 18 Oct 2019 13:26:01 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit

On 10/17/19 17:49, David Woodhouse wrote:
> On Thu, 2019-10-17 at 17:35 +0200, Laszlo Ersek 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().
> 
> 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.
> 

Personally I'm OK with this.

Thanks
Laszlo