From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DD985E784AC for ; Mon, 2 Oct 2023 13:01:18 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qnIXL-0001vB-1V; Mon, 02 Oct 2023 09:00:35 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qnIXI-0001r0-B2; Mon, 02 Oct 2023 09:00:32 -0400 Received: from bmailout2.hostsharing.net ([83.223.78.240]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qnIX2-0007Xn-Sv; Mon, 02 Oct 2023 09:00:31 -0400 Received: from h08.hostsharing.net (h08.hostsharing.net [83.223.95.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "*.hostsharing.net", Issuer "RapidSSL Global TLS RSA4096 SHA256 2022 CA1" (verified OK)) by bmailout2.hostsharing.net (Postfix) with ESMTPS id 9B6202800B3D2; Mon, 2 Oct 2023 14:50:35 +0200 (CEST) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 8530323B871; Mon, 2 Oct 2023 14:50:35 +0200 (CEST) Date: Mon, 2 Oct 2023 14:50:35 +0200 From: Lukas Wunner To: "Yao, Jiewen" Cc: Alistair Francis , "wilfred.mallawa@wdc.com" , "Jonathan.Cameron@Huawei.com" , "qemu-devel@nongnu.org" , "kbusch@kernel.org" , "its@irrelevant.dk" , "mst@redhat.com" , "marcel.apfelbaum@gmail.com" , "hchkuo@avery-design.com.tw" , "Browy, Chris" , "qemu-block@nongnu.org" , Alistair Francis Subject: Re: [PATCH 3/3] hw/nvme: Add SPDM over DOE support Message-ID: <20231002125035.GA21884@wunner.de> References: <20230915112723.2033330-1-alistair.francis@wdc.com> <20230915112723.2033330-3-alistair.francis@wdc.com> <20231002084753.GA23546@wunner.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Received-SPF: none client-ip=83.223.78.240; envelope-from=foo00@h08.hostsharing.net; helo=bmailout2.hostsharing.net X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org On Mon, Oct 02, 2023 at 11:36:25AM +0000, Yao, Jiewen wrote: > Comment on subjectAltName. > > PCI-SIG realized that it may cause problem for certain device > and decided to remove such requirement in future ECN. > I don't think that is absolutely needed. We have to follow what's in the spec. We can't just leave out certain elements because they might possibly maybe be removed in the future. PCIe r6.1 does require the Subject Alternative Name and that's the latest version, so we follow that. The ECN that you're referring to only exists as a draft in the PCISIG's Review Zone Archive. My understanding is that the Subject Alternative Name's purpose is to eliminate certain threats in the CMA threat model: The Subject Alternative Name is basically a signed version of the device's identity in config space. Without it, a different device might misappropriate a device's certificate + private key. If the Subject Alternative Name requirement is dropped, I would like to know how that threat is prevented instead? I don't quite understand what you mean by "may cause problem for certain device". I've asked the editor of the PCIe Base Spec why they're considering removing the requirement and the gist of the answer was -- I'm paraphrasing here -- that vendors thought the requirement is generally quite narrow and perceived as a straight-jacket and that at this point, more flexibility is desired as to the identification scheme. There was no mention at all of "problems for certain devices". Thanks, Lukas