Re: [lamps] [smime] Problems with versions

Russ Housley <housley@vigilsec.com> Fri, 06 May 2022 15:04 UTC

Return-Path: <housley@vigilsec.com>
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 E68EDC14F73D; Fri, 6 May 2022 08:04:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IrEaraYFhCa; Fri, 6 May 2022 08:04:15 -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 RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A852C14F736; Fri, 6 May 2022 08:04:15 -0700 (PDT)
Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id 37D5113BF87; Fri, 6 May 2022 11:04:14 -0400 (EDT)
Received: from [10.0.1.2] (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 213F413BDC3; Fri, 6 May 2022 11:04:14 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <BD061240-FAF1-4219-B72B-69B0F9A8459C@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_60A0CB7E-847B-454C-9FAE-E7DBF2CFEBB8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
Date: Fri, 06 May 2022 11:04:13 -0400
In-Reply-To: <SY4PR01MB6251A8BAFF80ECC2B8BC8862EEC59@SY4PR01MB6251.ausprd01.prod.outlook.com>
Cc: IETF SMIME <smime@ietf.org>, LAMPS <spasm@ietf.org>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
References: <SY4PR01MB6251E381603FAFE558685D86EEFE9@SY4PR01MB6251.ausprd01.prod.outlook.com> <CA16AFE1-CB97-4134-8FC9-4B8B964ACD6E@vigilsec.com> <SY4PR01MB62512D541C42E6873562A17CEEC29@SY4PR01MB6251.ausprd01.prod.outlook.com> <4447881C-4DEA-48E1-9767-9A6DA2AD07B0@vigilsec.com> <SY4PR01MB6251A8BAFF80ECC2B8BC8862EEC59@SY4PR01MB6251.ausprd01.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.104.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/zlz0jYDPS1hYRVRCUfTjKaifnGE>
Subject: Re: [lamps] [smime] Problems with versions
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.34
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: Fri, 06 May 2022 15:04:18 -0000

Peter:

>> I realize that your example is hypothetical.  However it cannot happen under
>> RFC 5652.
> 
> It can't happen if the spec never, ever changes, but it will happen if changes
> are necessary at some point, e.g. due to PQC.  As I mentioned in my original
> message, this is exactly what the OpenPGP folks have run into right now as
> they're trying to update RFC 4880, amd which the TLS folks ran into in spades
> and had to add all sorts of kludges to deal with.  I was pointing out that if
> there's ever a need to update CMS, or even there isn't and someone figures out
> what a "certificate with a type of other" or "crl with a type of other" is for
> the current RFC, it'll run into the same issues that TLS and OpenPGP have run
> into.


I think we should hold this discussion for the day that CMS is updated.  At least one one the proposals for PQC algorithms does not need any changes in the RecipientInfos.  In that proposal, the structures used for RSA-KEM (RFC 5990) is used. We'll see if that holds.

Russ