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.web09.1775.1571969540493742545 for ; Thu, 24 Oct 2019 19:12:20 -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 fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Oct 2019 19:12:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,226,1569308400"; d="scan'208";a="197295166" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by fmsmga008.fm.intel.com with ESMTP; 24 Oct 2019 19:12:19 -0700 Received: from fmsmsx123.amr.corp.intel.com (10.18.125.38) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 24 Oct 2019 19:12:19 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by fmsmsx123.amr.corp.intel.com (10.18.125.38) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 24 Oct 2019 19:12:19 -0700 Received: from shsmsx107.ccr.corp.intel.com ([169.254.9.33]) by SHSMSX151.ccr.corp.intel.com ([10.239.6.50]) with mapi id 14.03.0439.000; Fri, 25 Oct 2019 10:12:17 +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//++8YCAAByLAIAAJ70AgA34VPA= Date: Fri, 25 Oct 2019 02:12:16 +0000 Message-ID: <895558F6EA4E3B41AC93A00D163B727416F846DF@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> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOTYxMTNhYjQtZjMxNi00ZWQyLThlZmEtM2JjNGRkNGVhZjYzIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiQ1p1MGpWQjVzVWFpSXRsaHM0YW1wbDJ5YVV1Mm13UmdcL3VObWFBc2VRNVVaYjZiNW1IM2tVWGdaSURFdXBkY00ifQ== 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 >=20 > However. When I wanted to include a reference to RFC6125, I looked more > closely at the section that Jiaxin quoted. More specifically, the > surroundings of that section. >=20 > It turns out that the quoted section "3.1. Server Identity" is actually > part of Appendix B.2 ("HTTP (2000)"): >=20 > https://tools.ietf.org/html/rfc6125#appendix-B.2 >=20 > which is further part of Appendix B ("Prior Art"): >=20 > https://tools.ietf.org/html/rfc6125#appendix-B >=20 > Appendix B starts with the statement >=20 > > (This section is non-normative.) >=20 > and Appendix B.2 starts with >=20 > > In 2000, [HTTP-TLS] specified the following text regarding > > application service identity verification in HTTP: >=20 > Thus, Appendix B of RFC6125 doesn't require us to do anything! (Other > specs may still require us, of course.) >=20 > Now, does RFC6125 say anything about IP addresses? Yes, it does, in > section 1.7.2, "Out of Scope": >=20 > https://tools.ietf.org/html/rfc6125#section-1.7.2 >=20 > > o Identifiers other than fully qualified DNS domain names. > > > > Some certification authorities issue server certificates based on > > IP addresses, but preliminary evidence indicates that such > > certificates are a very small percentage (less than 1%) of issued > > certificates. Furthermore, IP addresses are not necessarily > > reliable identifiers for application services because of the > > existence of private internets [PRIVATE], host mobility, multiple > > interfaces on a given host, Network Address Translators (NATs) > > resulting in different addresses for a host from different > > locations on the network, the practice of grouping many hosts > > together behind a single IP address, etc. Most fundamentally, > > most users find DNS domain names much easier to work with than IP > > addresses, which is why the domain name system was designed in th= e > > first place. We prefer to define best practices for the much mor= e > > common use case and not to complicate the rules in this > > specification. > > > > Furthermore, we focus here on application service identities, not > > specific resources located at such services. Therefore this > > document discusses Uniform Resource Identifiers [URI] only as a > > way to communicate a DNS domain name (via the URI "host" > component > > or its equivalent), not as a way to communicate other aspects of = a > > service such as a specific resource (via the URI "path" component= ) > > or parameters (via the URI "query" component). > > > > We also do not discuss attributes unrelated to DNS domain names, > > such as those defined in [X.520] and other such specifications > > (e.g., organizational attributes, geographical attributes, compan= y > > logos, and the like). >=20 > So... I think we can (and should) proceed just the same, but we should > reference: >=20 > https://tools.ietf.org/html/rfc2818#section-3.1 >=20 > rather than RFC6125. >=20 > Accordingly, I've filed the curl report with reference to RFC-2818: >=20 > https://hackerone.com/reports/715413 >=20 > [...] >=20 Yeah, agree, Good Catch! Thanks.=20