From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.120]) by mx.groups.io with SMTP id smtpd.web12.2069.1571991266247583611 for ; Fri, 25 Oct 2019 01:14:26 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=gZT6gi/3; spf=pass (domain: redhat.com, ip: 207.211.31.120, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1571991265; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5fUtjMixLTtJScsBfmLfNg+QyAGwD2wX+wleow4Iqnc=; b=gZT6gi/38z6qZBt3eAQckbQV8YEqXgwIkAebW50pRxKPGGsvb+AtaGejlSXyHzOetPqEEI QFLiBdIAnUsntZ7cKgDnQ0lyxtoeymSMtu6ohm/TCAZYazHN9UNDWcmVLGTD9ftyIbE1rM TWhPNlAT/jl1QLPHS1rZJ8x80QsCPQE= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-7-CVGX98cNP7O24NkFQSz6_Q-1; Fri, 25 Oct 2019 04:14:21 -0400 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 386311005500; Fri, 25 Oct 2019 08:14:20 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-99.ams2.redhat.com [10.36.116.99]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9C3EE600C6; Fri, 25 Oct 2019 08:14:18 +0000 (UTC) Subject: Re: [edk2-devel] [RFC v1 5/4] CryptoPkg/TlsLib: accept peer certs via both DNS names and IP addresses To: "Wu, Jiaxin" , David Woodhouse , "devel@edk2.groups.io" Cc: Bret Barkelew , "Wang, Jian J" , Richard Levitte , Sivaraman Nainar 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> <895558F6EA4E3B41AC93A00D163B727416F84704@SHSMSX107.ccr.corp.intel.com> From: "Laszlo Ersek" Message-ID: Date: Fri, 25 Oct 2019 10:14:17 +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: <895558F6EA4E3B41AC93A00D163B727416F84704@SHSMSX107.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-MC-Unique: CVGX98cNP7O24NkFQSz6_Q-1 X-Mimecast-Spam-Score: 0 Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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(). >=20 > That was also what I suggested before: > "Now, to resolve the problem, I think the *best compatibility* can actual= ly be reached by setting the IP address both as iPAddress and dNSName in SA= N..." >=20 > Above setting means to call X509_VERIFY_PARAM_set1_ip and X509_VERIFY_PAR= AM_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 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