[lamps] Re: Questions and Comments on draft-ietf-lamps-certificate-discovery

Russ Housley <housley@vigilsec.com> Wed, 08 July 2026 20:28 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: spasm@mail2.ietf.org
Delivered-To: spasm@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id E1FAB113622AB for <spasm@mail2.ietf.org>; Wed, 8 Jul 2026 13:28:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1783542508; bh=EKqJ499L41wlujZe8yU6KzQuOL6FetKkvvrTJ6Z5xJA=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=l+VZRI+AzBMSysbGnk4rBuA8viEmnlFYstc6wYFTt9eqGPt+iOwBzoesNMmoACv+C gDiaamwZlXyXgfAwLcCq15j3mD72kTxVCzqXFCdBZx0ubYa5bHIFU3Z8R//yYpyzo7 cbicyxwhKFHfisn8reIlAFn9yhFTRnOq6fsx3jUQ=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level:
X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=vigilsec.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cfYg6XTQh11 for <spasm@mail2.ietf.org>; Wed, 8 Jul 2026 13:28:28 -0700 (PDT)
Received: from mail3.g24.pair.com (mail3.g24.pair.com [66.39.134.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 6AF09113622A4 for <spasm@ietf.org>; Wed, 8 Jul 2026 13:28:28 -0700 (PDT)
Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id 4CC0E1A1D25; Wed, 8 Jul 2026 16:28:28 -0400 (EDT)
Received: from smtpclient.apple (pfs.iad.rg.net [198.180.150.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail3.g24.pair.com (Postfix) with ESMTPSA id 32C071A1DE7; Wed, 8 Jul 2026 16:28:28 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <06FDF57A-D02B-4152-9317-07189B9D79AD@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_494C8C13-F4DE-49A9-902A-93BF06C51830"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\))
Date: Wed, 08 Jul 2026 16:28:17 -0400
In-Reply-To: <CALZ6fAigQ2DEwU7YmXjgaWaOWrem363n5QPgL7-=eN2MA3C=7Q@mail.gmail.com>
To: suzanne wibada <suzannewibada01@gmail.com>
References: <CALZ6fAigQ2DEwU7YmXjgaWaOWrem363n5QPgL7-=eN2MA3C=7Q@mail.gmail.com>
X-Mailer: Apple Mail (2.3864.600.51.1.1)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vigilsec.com; h=from:message-id:content-type:mime-version:subject:date:in-reply-to:cc:to:references; s=pair-202402141609; bh=3VovMgr+P+UwjgJcy/4689OJZFJQBlbAmQM1HdWBIyY=; b=nWauZohK3hKKUtCwH6soy81uh7SXxg2cE0bA69iYFfpwVHyOwKkj8Hnt4tw2tkby8yDy9g4Wa/hKI9YN86tKkygnuISs333T6a1i6wLeWaR8p/nf+X12ydEaCkNvrnKnY+Fc33lcBAX4MertrN/c7OiJphxF6hUUbUTNWbBpxSjisN/VT9KWtkSsQuA5Oz6nlgY3AjSJNsUpBWPBC7A4lxbxVRbtA4heACyfdIRG+phkhi5/LYEg7QkfnNZpvSlbhUX3zElgopnuesKdXUlaCBSZjl1+ujnxwg0nAq06tEodMcY+9Yd0dlE6afdKuSyL3Fp/8xMJYIfhXmPGvhNTmg==
X-Scanned-By: mailmunge 3.09
Message-ID-Hash: YZNZ63XJZMDV52TZ24GT3YAKLRG6OGE3
X-Message-ID-Hash: YZNZ63XJZMDV52TZ24GT3YAKLRG6OGE3
X-MailFrom: housley@vigilsec.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-spasm.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: IETF LAMPS <spasm@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [lamps] Re: Questions and Comments on draft-ietf-lamps-certificate-discovery
List-Id: This is the mail list for the LAMPS Working Group <spasm.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/bP9ZE2vJIIFvLjf-chtmJC6bdvc>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Owner: <mailto:spasm-owner@ietf.org>
List-Post: <mailto:spasm@ietf.org>
List-Subscribe: <mailto:spasm-join@ietf.org>
List-Unsubscribe: <mailto:spasm-leave@ietf.org>

Suzanne:

> 1. Simultaneous use of multiple certificates/keys
> The abstract mentions support for multi-key/certificate usage, but the current use cases seem to focus primarily on scenarios where one certificate acts as an alternative or backup to another.
> 
> It may be interesting to introduce a Hybrid Certificate use case, where multiple certificates are used simultaneously to authenticate the same session.
> 
> For example, during a post-quantum migration, both a classical certificate and a PQC certificate could contribute to the authentication of a connection. In a TLS context, this could potentially be achieved by introducing a second CertificateVerify message carrying an additional signature generated using the secondary certificate. In this model, both certificates would actively participate in establishing trust rather than serving merely as alternatives to one another.
> 
We need to be careful here.  Some of this is not in scope for the LAMPS WG.  I think it would be fine for LAMPS to provide a mechanism for a relying party to discover that a subject has more than one valid certificate.  However, the use of one or more of those certificate in a security protocol needs to be handeled that the WG that specifies that security protocol.  The exception is S/MIME, as that security protocol is also part of LAMPS,  S/MIME already handles multiple signatures each validated with a separate certificate.

Russ