From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.81]) by mx.groups.io with SMTP id smtpd.web11.4207.1571946465046297847 for ; Thu, 24 Oct 2019 12:47:45 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=XDts+AGr; spf=pass (domain: redhat.com, ip: 207.211.31.81, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1571946464; 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=KzIxMSo00j1GHaJIiJ6zTPRO2tVydsX5hY8xlUVd678=; b=XDts+AGr3sLB7OPQK5smpBazaESqaqq0y0yqL5aqFIF5aZqnKmhlTkR59VJz/XZvGQiusD T4OPOxBxQfmB/i9vKt29PnOxzRguRktiqKXMMb86IPI3JqUffFUWIRFMN00qJPKftUe1IR j+1hFTvnI2U3Xn6KIUX/o9NtsSu0Q0w= 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-117-ap2IhO3NMLSHAOLtrkuK_Q-1; Thu, 24 Oct 2019 15:47:40 -0400 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 mimecast-mx01.redhat.com (Postfix) with ESMTPS id EADD21005500; Thu, 24 Oct 2019 19:47:38 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (unknown [10.36.118.161]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3AB065C1B5; Thu, 24 Oct 2019 19:47:36 +0000 (UTC) Subject: Re: [edk2-devel] [RFC v1 5/4] CryptoPkg/TlsLib: accept peer certs via both DNS names and IP addresses To: devel@edk2.groups.io, dwmw2@infradead.org, "Wu, Jiaxin" 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> From: "Laszlo Ersek" Message-ID: <21320051-2364-803f-8b35-58c3f4323c15@redhat.com> Date: Thu, 24 Oct 2019 21:47:36 +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: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-MC-Unique: ap2IhO3NMLSHAOLtrkuK_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/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(). >=20 > 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. >=20 > 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. I have four patches, to be inserted in the middle (between v1 patches #2 and #3). I plan to submit a v2 series (8 patches in total) this week, after testing. If I can't manage this week, then it'll take a longer (possibly 2+ weeks). Jiaxin, I'm assigning the bug to myself, if that's OK with you. Thanks Laszlo