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.2775.1571213296692023666
 for <devel@edk2.groups.io>;
 Wed, 16 Oct 2019 01:08:16 -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-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx1.redhat.com (Postfix) with ESMTPS id 28CB8302C08A;
	Wed, 16 Oct 2019 08:08:16 +0000 (UTC)
Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-232.ams2.redhat.com [10.36.116.232])
	by smtp.corp.redhat.com (Postfix) with ESMTP id 9686060C57;
	Wed, 16 Oct 2019 08:08:14 +0000 (UTC)
Subject: Re: [edk2-devel] [RFC v1 5/4] CryptoPkg/TlsLib: accept peer certs via both DNS names and IP addresses
From: "Laszlo Ersek" <lersek@redhat.com>
To: "Wu, Jiaxin" <jiaxin.wu@intel.com>,
 "devel@edk2.groups.io" <devel@edk2.groups.io>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>,
 David Woodhouse <dwmw2@infradead.org>, "Wang, Jian J"
 <jian.j.wang@intel.com>, Richard Levitte <levitte@openssl.org>,
 Sivaraman Nainar <sivaramann@amiindia.co.in>
Reply-To: devel@edk2.groups.io, lersek@redhat.com
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>
Message-ID: <c7a7b892-af26-cd46-f8fd-39298bcfa1f7@redhat.com>
Date: Wed, 16 Oct 2019 10:08:13 +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: <56d17f5f-8433-2ec5-924c-bade642ac5a7@redhat.com>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.46]); Wed, 16 Oct 2019 08:08:16 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit

On 10/16/19 09:36, Laszlo Ersek wrote:
> On 10/16/19 07:18, Wu, Jiaxin wrote:

>> Comment2: do we really need the app_verify_callback function setting?
>> Why not call X509_VERIFY_PARAM_set1_ip_asc (TlsConn->Ssl->param,
>> HostName) in TlsSetVerifyHost directly? anything I missed in the
>> discussion?
> 
> I don't think client code should access "Ssl->param" directly. SSL
> should be treated as an opaque data structure.
> 
> However, I think you may have a point. Formally, the SSL_get0_param()
> function could be called to retrieve X509_VERIFY_PARAM.
> 
>   https://www.openssl.org/docs/man1.1.1/man3/SSL_get0_param.html
> 
> And then we could call X509_VERIFY_PARAM_set1_ip_asc() on that, perhaps.
> This would make both the ExData stuff and the custom certificate
> verification procedure unnecessary.

To be clear, this is meant to say:

Jiaxin, I'm totally fine to drop "RFC v1 5/4".

Just please post a v2, and use

- SSL_get0_param()
- X509_VERIFY_PARAM_set1_ip_asc()
- X509_VERIFY_PARAM_set1_host()

rather than

  SSL_set1_host()

in patch v2 2/4 -- if it works, that is! :)

Thanks!
Laszlo