Re: [smime] Problems with versions
Peter Gutmann <pgut001@cs.auckland.ac.nz> Fri, 06 May 2022 11:59 UTC
Return-Path: <pgut001@cs.auckland.ac.nz>
X-Original-To: smime@ietfa.amsl.com
Delivered-To: smime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEC3AC157B5B for <smime@ietfa.amsl.com>; Fri, 6 May 2022 04:59:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Level:
X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable 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 mrhB6bdH6bXt for <smime@ietfa.amsl.com>; Fri, 6 May 2022 04:59:39 -0700 (PDT)
Received: from au-smtp-delivery-117.mimecast.com (au-smtp-delivery-117.mimecast.com [103.96.23.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13EEFC157B54 for <smime@ietf.org>; Fri, 6 May 2022 04:59:38 -0700 (PDT)
Received: from AUS01-ME3-obe.outbound.protection.outlook.com (mail-me3aus01lp2240.outbound.protection.outlook.com [104.47.71.240]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id au-mta-88-g6oSfYBKOay6KnqDjDnjgQ-1; Fri, 06 May 2022 21:59:32 +1000
X-MC-Unique: g6oSfYBKOay6KnqDjDnjgQ-1
Received: from SY4PR01MB6251.ausprd01.prod.outlook.com (2603:10c6:10:10b::10) by MEYPR01MB6680.ausprd01.prod.outlook.com (2603:10c6:220:12f::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5206.12; Fri, 6 May 2022 11:59:31 +0000
Received: from SY4PR01MB6251.ausprd01.prod.outlook.com ([fe80::4d78:e58:4ae1:d3ec]) by SY4PR01MB6251.ausprd01.prod.outlook.com ([fe80::4d78:e58:4ae1:d3ec%7]) with mapi id 15.20.5206.027; Fri, 6 May 2022 11:59:31 +0000
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: Russ Housley <housley@vigilsec.com>
CC: IETF SMIME <smime@ietf.org>, LAMPS <spasm@ietf.org>
Thread-Topic: [smime] Problems with versions
Thread-Index: AQHYXXIMHf7j2iQTy0ie4a2+MgHkeK0LkVWAgASshiGAACZXAIABYdOo
Date: Fri, 06 May 2022 11:59:31 +0000
Message-ID: <SY4PR01MB6251A8BAFF80ECC2B8BC8862EEC59@SY4PR01MB6251.ausprd01.prod.outlook.com>
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>
In-Reply-To: <4447881C-4DEA-48E1-9767-9A6DA2AD07B0@vigilsec.com>
Accept-Language: en-NZ, en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 755664cc-0d46-4068-e6ab-08da2f57e10f
x-ms-traffictypediagnostic: MEYPR01MB6680:EE_
x-ms-exchange-atpmessageproperties: SA|SL
x-microsoft-antispam-prvs: <MEYPR01MB66809C84879A6FADE4D5C731EEC59@MEYPR01MB6680.ausprd01.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0
x-microsoft-antispam-message-info: 2cQ38tBI4T3dASXksX+5ziZ+4h7bN7HIi98nsWvJQy1M1bLWO1O1l0nkbWfQZgvldfD8Ae1EQpYYiKcnlq3p0Uke6J0Fc28y1HmBJ3IrYJr6SQxpao40GiwSe635dsr+83sV2iILmJMYCym4QWSY4q9bJqAMH4VSctj/fy771GPO79Swsi3309LIh/DnHp2tmMRIQAL7sVeQ4DyC4fg8qqFbl9srJWC6jAFKYWjZSZMRhKF/GddZXOURG2Tec8WE0XeC9Z8klFlzNtashf3MkzAu2kyzQ94j9dGDsEEqEYf3zQ35K3suKzBSCl95DIazReBzKCvYsKIZonthVxQ9g0VHfwtMX8wDyZ1SLH5N1hccxK5Ys8OirD7kzSfqDIUDZAuZIJXWB9f+wf4Bg0bxJYGZ+TehAFjEe76Wy65qDrT7llIrCziVMize6z5BsQpXZs/Z5+yQ+HYlBBlgBhCVAI9Ys+ysmsJ0ya6SwfgSo4dNxDdbEgDNufXphli8Ttk6CI+cPovHuOHpDnFup7YLByRGNGBee5CkujtkE/rPpjpZf1q+uCXEIpPw7tzaA4XylkbDJpNeiikezKFxTUufip3khRe0HCPU616IL57NBQ4oFa57I8IsCZyc+iDvqrnddEzcEwQ4VW+45YpT+IxhkYtASWZBjwe+b2K1XZXanXaK3KKTp4qDimR6lfkXn3UTxo+RZuPUw0T0rf9jDOURPw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SY4PR01MB6251.ausprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(186003)(6506007)(2906002)(5660300002)(9686003)(76116006)(7696005)(83380400001)(26005)(55016003)(52536014)(33656002)(66556008)(66476007)(66946007)(786003)(508600001)(316002)(8936002)(66446008)(4326008)(71200400001)(64756008)(38070700005)(38100700002)(6916009)(54906003)(86362001)(122000001)(8676002); DIR:OUT; SFP:1101
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 2tKqWqvTv2lgT/beKHww1H/j6bGNIbU2E6xCCgSjOughBd5dQjck8uCIeRqCteFHYI8R9rRM6cSwMjOt34JCcODBORjyPtNxCU7Tld13vfAeh+iHJt4zbj1JwPfuIWjYLq2TxlAtCY9rlummUm2geWWGxE3+Vr5tlHUArmq8mcyOTeSUX0uFDVZFR+KqVt4yGAXUu4j1aGKjZbsx9nJQ3f/WUp1p0lNXCurHWgJawO2IS/5KnMghi0FZ77T0zAVYfTVWoPr8LbDla7XFQXLyO0cTrLStAZ8cqB8N1LkTdo/dUwbRqmeRS07k5XJBTZJgJ/HBqvq7ddL3gTSGtCsche5CBsRBtyNmtfzj4H52Qu8weDjxwm1iXo6gSulOwxyB1d3m2IHyVca874gT/4KbdhKkey+RvG5i/YFjrD/1TuBCWKnGdYbKWrYd7SQU3c8S1HKPGEy4zoqYe5fI9k/8g110UWIyd47UBK3VlQoKS/dMirEIXN/Oiy/Of10KW7IR2LSPbmo/82gIGClZEhIREoi4PhVUXzOAs1cuB0Y64jxulm986XmgTasWpAR5Hdp5H6aZFYc1aeZhAShDQqT3HOUN5VKZwRme0F8ZhrwE5WrKJH1CzPpwpG7xkD3oSmTJAQ5E3EgQu/K1nEpnLRZSYfHndqlIZYL/bVD3IOPfoneGxkAXojLR0yq55MnzproqiCMDr6fGGg57mOWvMOKMgeAYUlcxBaIWGKn6tNzNDVrreT0yqKMMpiD+isoH6Zctx4SnGCLD0t80L7NYkep+dSeH1lW05wHG3ojjyUSyWxzQpZfjGd5ejHwJGnB3WHZK7VuUxFhjXm3Jhy2hJ56/ljC/BlYFGEt++uF+jp27FPntv46SyltZGSUDJUSh1H8+BgqcFSVGH5PnIb7KaIGAqip/58ZOcLBHWVZtMy3bpK9WVWUOfw7FjFsJd6wKy98HqvvKMQNs1QmJIwDmqsRiDZhkbJrpuw6mIAbjGTdk0R2Q+En/ZD0lfDwAjDpMBqBZN0VDX5WBQM0E48dHfep3JVfu+T0PMjLU2FQSEkq4IEdBdLtSQ644zF2aSSVdahTiwwVk2a/BEmt+Gpzjbc/ec4cWBpzH42eMIsLN8k0vHLkMpMwPza1vtVmNqznDDZMFnMJONy9L+qejxoVviRUWRPkExehDnOn7IRYHRX8sk+Qa8rkX6Afs1DxTuCVhiq+AQZbD2PzFzq3e0nZlX0lB1jgCi/TGmiHkN51RfU2OAH4kBrgl+wXhCMTMcPzJeiinFYzPFL9cUDrifYMbaW2qye+RzDem/DCeY1bTCC3QLeyUagNJ8/+OfhTFuj6tJoOL02/NLa6/oxWfWNYzBfPXH/ZE5tB40J29NrIlVB54PGN2iaQcallVu2z2lBKbByUpL1iAmLztCeDH4SHORbSoDSRJns5tVpFShpqbciNALwZlHZ/AjmENkQPe+jDva8FwrWp5kWXgmV/Kb3gi3hi/mHt3Vsn7KLKSP0GXbCB0QdvRbv1/UYyA9b+Qrkf1L5SuT+INl0s9KA0Z37H3UI5W6JPq5Dx2eIcrv0z7aizCec9JMohpIsiMAX14XBeDcW+HFQHHSnISajhB/W82l1XQ/DeAwidA1A0AThPrOc8Tbhcyb/p2TqgyiRvX2WJ15hT4jJN36UsF1DNZoAm7mYU4Bc5+dJyGEzYCaWur4iIam06tzgzbFqEszD2D14oEqL0OxpGfj/4fSCTW0XZIANcAeMS81U/Ce3z9ufrJZdqA2ho=
MIME-Version: 1.0
X-OriginatorOrg: cs.auckland.ac.nz
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SY4PR01MB6251.ausprd01.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 755664cc-0d46-4068-e6ab-08da2f57e10f
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2022 11:59:31.0766 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: d1b36e95-0d50-42e9-958f-b63fa906beaa
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: SW/A6MJgjGILaRC2tDf2lioNN2HBx8Z+2YA6M3L034i6Bv/g00rswPgZOhjq1lMJ3U2DOZP31Bxyeu/V0uD3qUYOE2u2A7Y0N/Ljohd9wRQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MEYPR01MB6680
Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CAU17A13 smtp.mailfrom=pgut001@cs.auckland.ac.nz
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: cs.auckland.ac.nz
Content-Language: en-NZ
Content-Type: text/plain; charset="WINDOWS-1252"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/smime/JEX6KtSIZb-k-_agMTLvRZJAb34>
Subject: Re: [smime] Problems with versions
X-BeenThere: smime@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: SMIME Working Group <smime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/smime>, <mailto:smime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/smime/>
List-Post: <mailto:smime@ietf.org>
List-Help: <mailto:smime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/smime>, <mailto:smime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 May 2022 11:59:42 -0000
Russ Housley <housley@vigilsec.com> writes: >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. From looking at the current text: IF ((certificates is present) AND (any certificates with a type of other are present)) OR ((crls is present) AND (any crls with a type of other are present)) THEN version MUST be 5 ELSE IF (certificates is present) AND (any version 2 attribute certificates are present) THEN version MUST be 4 ELSE IF ((certificates is present) AND (any version 1 attribute certificates are present)) OR (any SignerInfo structures are version 3) OR (encapContentInfo eContentType is other than id-data) THEN version MUST be 3 ELSE version MUST be 1 what it's saying is: IF a certificate or CRL type that no-one can define is present THEN version MUST be 5 ELSE IF an attribute certificate but not quite the same attribute certificate that would require a version of 3 is present THEN version MUST be 4 ELSE IF an attribute certificate is present OR (some stuff that seems irrelevant at this point in the processing) THEN version MUST be 3 ELSE version MUST be 1 which simplifies to: IF an attribute certificate is present THEN version MUST be 3 ELSE version MUST be 1 although even then I can't see why the presence of an attribute certificate somewhere further down or a non-data eContentType would require a change in the SignedData version. To illustrate why requirements to set arbitrary implementation-breaking versions is a problem, here's the SignedData from PKCS #7 in 1992: SignedData ::= SEQUENCE { version Version, digestAlgorithms DigestAlgorithmIdentifiers, contentInfo ContentInfo, certificates [0] IMPLICIT ExtendedCertificatesAndCertificates OPTIONAL, crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, signerInfos SignerInfos } And here's SignedData from RFC 5652 (and in between 2630, 3369, and 2853) as it applies thirty years later: SignedData ::= SEQUENCE { version CMSVersion, digestAlgorithms DigestAlgorithmIdentifiers, encapContentInfo EncapsulatedContentInfo, certificates [0] IMPLICIT CertificateSet OPTIONAL, crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, signerInfos SignerInfos } Apart from some fiddling with the ASN.1, e.g. deprecation of obsolete ASN.1 '88 forms, and changing of names, it's the same thing. SignedData version 1 is the same as SignedData version 2 is the same as SignedData version 3 is the same as SignedData version 4 is the same as SignedData version 5, the only thing that's changed each time is a requirement to (potentially) set the version field to something that ensures an existing implementation can't process it any more. Peter.
- [smime] Problems with versions Peter Gutmann
- Re: [smime] Problems with versions Russ Housley
- Re: [smime] Problems with versions Peter Gutmann
- Re: [smime] Problems with versions Carl Wallace
- Re: [smime] Problems with versions Russ Housley
- Re: [smime] Problems with versions Russ Housley
- Re: [smime] Problems with versions Carl Wallace
- Re: [smime] Problems with versions Peter Gutmann
- Re: [smime] Problems with versions Peter Gutmann
- Re: [smime] [lamps] Problems with versions Russ Housley
- Re: [smime] [lamps] Problems with versions Peter Gutmann