IETF Logo Mail Archive

Re: [lamps] New drafts available - non-composite hybrid authentication, and binding certs

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 30 March 2022 12:19 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E2F3A120E for <spasm@ietfa.amsl.com>; Wed, 30 Mar 2022 05:19:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.109
X-Spam-Level:
X-Spam-Status: No, score=-7.109 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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSFjWelVsbZR for <spasm@ietfa.amsl.com>; Wed, 30 Mar 2022 05:19:20 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C36843A1200 for <spasm@ietf.org>; Wed, 30 Mar 2022 05:19:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 032A338CE4; Wed, 30 Mar 2022 08:30:04 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UgDkwYLuou0p; Wed, 30 Mar 2022 08:30:02 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3561238CDA; Wed, 30 Mar 2022 08:30:02 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1648643402; bh=dytmLBls6AFQeSV+Kpqq+B82FRcylQJxh3AfhncsGwk=; h=From:To:Subject:In-Reply-To:References:Date:From; b=l83cPG0H+GVgbQ4Vf67NjGzcBYi9DPATkAg6/l3u/wn6ojLjgdBNSGq4T+leHhoZQ JTrT2yJOqJIH6lQEldvy39YHiGIbaGDf1M9RtFgSinaNU582sL4PjqaYP/R21MXHTz +ndZijL6vhuBJH310nCsjjaXee+1QmM4grUuHTmABv8jKF5ar/dAGVEekD+hnG8qLO AFTMoDuhTgUP2We+dxbGV1bR8Xrcp7JfzEFKTQDn9Bs9wn0R7LQHkTYTqpoHeyNO/a tJWHEGSTRxP4Q6m46gL22269AD7cGUGPL/oYak91unOlY4EjLinVfv+gRCRibmZsxP vMrUZKIaNLHAw==
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 115B053F; Wed, 30 Mar 2022 08:19:17 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "aebecke\@uwe.nsa.gov" <aebecke=40uwe.nsa.gov@dmarc.ietf.org>, "spasm\@ietf.org" <spasm@ietf.org>
In-Reply-To: <SA0PR09MB7241A0BD380AC0781D6E31D4F11E9@SA0PR09MB7241.namprd09.prod.outlook.com>
References: <SA0PR09MB72412B7DA4F1DDA68A40AD1EF1179@SA0PR09MB7241.namprd09.prod.outlook.com> <CAErg=HHCo_SSNmq111oUZjw-L+445jQrARUHDzjZExQZr02SJw@mail.gmail.com> <SA0PR09MB7241116708E9B97F14319E21F1199@SA0PR09MB7241.namprd09.prod.outlook.com> <CAErg=HET4kn+zQvYp2thoMsV=GozugsPVRnRmpFxr551=6gwHA@mail.gmail.com> <SA0PR09MB7241A0BD380AC0781D6E31D4F11E9@SA0PR09MB7241.namprd09.prod.outlook.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Wed, 30 Mar 2022 08:19:17 -0400
Message-ID: <23859.1648642757@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/c4iOH12UV0k425AbYMYdKS7adFQ>
Subject: Re: [lamps] New drafts available - non-composite hybrid authentication, and binding certs
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Mar 2022 12:19:26 -0000

aebecke@uwe.nsa.gov <aebecke=40uwe.nsa.gov@dmarc.ietf.org> wrote:
    > If the certs are from different CAs, it is possible they use different
    > practices to issue the certificates. The two certs are independently
    > valid on their own, so if the verifier likes them both - great, if the
    > verifier likes one and not the other, then it depends on if the
    > implementation can fall back to using one cert, and whether or not the
    > appropriate one is agreeable.

It seems to me that we need to be a bit more precise about the "likes them both"
part.

a) we need some words to describe the policies involved.  Why? Because it
   will need to go into requirements, and because people will have to speak
   as to what policy failed when it fails.

b) when it fails back to using one cert, we may need to communicate this fact
   to users and administrators.


Can we use this for two (or n) pre-quantum ("legacy") certificates?
Is this a general mechanism for hedging against expiration?
To avoid keeping ones eggs in one basket?
An advantage of doing that is that it excercises the code paths more
frequently.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

v2.8.7 | Report a Bug | By Email