From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by mx.groups.io with SMTP id smtpd.web10.1715.1571969565368426451 for ; Thu, 24 Oct 2019 19:12:45 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 134.134.136.20, mailfrom: jiaxin.wu@intel.com) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Oct 2019 19:12:45 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,226,1569308400"; d="scan'208";a="398623736" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by fmsmga005.fm.intel.com with ESMTP; 24 Oct 2019 19:12:44 -0700 Received: from fmsmsx118.amr.corp.intel.com (10.18.116.18) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 24 Oct 2019 19:12:44 -0700 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by fmsmsx118.amr.corp.intel.com (10.18.116.18) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 24 Oct 2019 19:12:44 -0700 Received: from shsmsx107.ccr.corp.intel.com ([169.254.9.33]) by SHSMSX152.ccr.corp.intel.com ([10.239.6.52]) with mapi id 14.03.0439.000; Fri, 25 Oct 2019 10:12:42 +0800 From: "Wu, Jiaxin" To: Laszlo Ersek , David Woodhouse , "devel@edk2.groups.io" CC: Bret Barkelew , "Wang, Jian J" , Richard Levitte , "Sivaraman Nainar" Subject: Re: [edk2-devel] [RFC v1 5/4] CryptoPkg/TlsLib: accept peer certs via both DNS names and IP addresses Thread-Topic: [edk2-devel] [RFC v1 5/4] CryptoPkg/TlsLib: accept peer certs via both DNS names and IP addresses Thread-Index: AQHVg62DZ6WOVWxXskyQgy9MaFNi8adcnJFA//++8YCAAByLAIAAJ70AgAAf7oCAABMIAIAAC5yAgAGVDACAAAPtgIABalyAgArHbvA= Date: Fri, 25 Oct 2019 02:12:42 +0000 Message-ID: <895558F6EA4E3B41AC93A00D163B727416F84704@SHSMSX107.ccr.corp.intel.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> <139da0c5a4684b76809fa19acc007f4699e3eb28.camel@infradead.org> <81cf523b-1cc0-9df1-cbb3-c16a78e26a55@redhat.com> <64366517-6a4e-41da-0ab5-6dea3580bf30@redhat.com> <7e15bed3-ef3c-0609-e720-e35ffcfc3a0e@redhat.com> In-Reply-To: <7e15bed3-ef3c-0609-e720-e35ffcfc3a0e@redhat.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYThkMmRkZDMtMWNlNC00ZjU1LTk1MjAtZTBhOWJhZmEwYjczIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiZTRUQTVLVStWcllZa2JCcm9cL0h0QzBneWVWNVI1cUdkOXpqdFJnZFNyVEw3Q0Q0UDRxWDYxUnN0MGZ6MTdWK0cifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Return-Path: jiaxin.wu@intel.com Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > >> 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 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. > > Okay, good point here, it's also make sense to me. >=20 > Personally I'm OK with this. >=20 > Thanks > Laszlo