From nobody Fri May 6 04:59:44 2022 Return-Path: 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 ; 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 ; 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 ; 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 To: Russ Housley CC: IETF SMIME , LAMPS Thread-Topic: [smime] Problems with versions Thread-Index: AQHYXXIMHf7j2iQTy0ie4a2+MgHkeK0LkVWAgASshiGAACZXAIABYdOo Date: Fri, 6 May 2022 11:59:31 +0000 Message-ID: References: <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: 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: =?iso-8859-1?Q?2tKqWqvTv2lgT/beKHww1H/j6bGNIbU2E6xCCgSjOughBd5dQjck8uCIeR?= =?iso-8859-1?Q?qCteFHYI8R9rRM6cSwMjOt34JCcODBORjyPtNxCU7Tld13vfAeh+iHJt4z?= =?iso-8859-1?Q?bj1JwPfuIWjYLq2TxlAtCY9rlummUm2geWWGxE3+Vr5tlHUArmq8mcyOTe?= =?iso-8859-1?Q?SUX0uFDVZFR+KqVt4yGAXUu4j1aGKjZbsx9nJQ3f/WUp1p0lNXCurHWgJa?= =?iso-8859-1?Q?wO2IS/5KnMghi0FZ77T0zAVYfTVWoPr8LbDla7XFQXLyO0cTrLStAZ8cqB?= =?iso-8859-1?Q?8N1LkTdo/dUwbRqmeRS07k5XJBTZJgJ/HBqvq7ddL3gTSGtCsche5CBsRB?= =?iso-8859-1?Q?tyNmtfzj4H52Qu8weDjxwm1iXo6gSulOwxyB1d3m2IHyVca874gT/4Kbdh?= =?iso-8859-1?Q?Kkey+RvG5i/YFjrD/1TuBCWKnGdYbKWrYd7SQU3c8S1HKPGEy4zoqYe5fI?= =?iso-8859-1?Q?9k/8g110UWIyd47UBK3VlQoKS/dMirEIXN/Oiy/Of10KW7IR2LSPbmo/82?= =?iso-8859-1?Q?gIGClZEhIREoi4PhVUXzOAs1cuB0Y64jxulm986XmgTasWpAR5Hdp5H6aZ?= =?iso-8859-1?Q?FYc1aeZhAShDQqT3HOUN5VKZwRme0F8ZhrwE5WrKJH1CzPpwpG7xkD3oSm?= =?iso-8859-1?Q?TJAQ5E3EgQu/K1nEpnLRZSYfHndqlIZYL/bVD3IOPfoneGxkAXojLR0yq5?= =?iso-8859-1?Q?5MnzproqiCMDr6fGGg57mOWvMOKMgeAYUlcxBaIWGKn6tNzNDVrreT0yqK?= =?iso-8859-1?Q?MMpiD+isoH6Zctx4SnGCLD0t80L7NYkep+dSeH1lW05wHG3ojjyUSyWxzQ?= =?iso-8859-1?Q?pZfjGd5ejHwJGnB3WHZK7VuUxFhjXm3Jhy2hJ56/ljC/BlYFGEt++uF+jp?= =?iso-8859-1?Q?27FPntv46SyltZGSUDJUSh1H8+BgqcFSVGH5PnIb7KaIGAqip/58ZOcLBH?= =?iso-8859-1?Q?WVZtMy3bpK9WVWUOfw7FjFsJd6wKy98HqvvKMQNs1QmJIwDmqsRiDZhkbJ?= =?iso-8859-1?Q?rpuw6mIAbjGTdk0R2Q+En/ZD0lfDwAjDpMBqBZN0VDX5WBQM0E48dHfep3?= =?iso-8859-1?Q?JVfu+T0PMjLU2FQSEkq4IEdBdLtSQ644zF2aSSVdahTiwwVk2a/BEmt+Gp?= =?iso-8859-1?Q?zjbc/ec4cWBpzH42eMIsLN8k0vHLkMpMwPza1vtVmNqznDDZMFnMJONy9L?= =?iso-8859-1?Q?+qejxoVviRUWRPkExehDnOn7IRYHRX8sk+Qa8rkX6Afs1DxTuCVhiq+AQZ?= =?iso-8859-1?Q?bD2PzFzq3e0nZlX0lB1jgCi/TGmiHkN51RfU2OAH4kBrgl+wXhCMTMcPzJ?= =?iso-8859-1?Q?eiinFYzPFL9cUDrifYMbaW2qye+RzDem/DCeY1bTCC3QLeyUagNJ8/+Ofh?= =?iso-8859-1?Q?TFuj6tJoOL02/NLa6/oxWfWNYzBfPXH/ZE5tB40J29NrIlVB54PGN2iaQc?= =?iso-8859-1?Q?allVu2z2lBKbByUpL1iAmLztCeDH4SHORbSoDSRJns5tVpFShpqbciNALw?= =?iso-8859-1?Q?ZlHZ/AjmENkQPe+jDva8FwrWp5kWXgmV/Kb3gi3hi/mHt3Vsn7KLKSP0GX?= =?iso-8859-1?Q?bCB0QdvRbv1/UYyA9b+Qrkf1L5SuT+INl0s9KA0Z37H3UI5W6JPq5Dx2eI?= =?iso-8859-1?Q?crv0z7aizCec9JMohpIsiMAX14XBeDcW+HFQHHSnISajhB/W82l1XQ/DeA?= =?iso-8859-1?Q?widA1A0AThPrOc8Tbhcyb/p2TqgyiRvX2WJ15hT4jJN36UsF1DNZoAm7mY?= =?iso-8859-1?Q?U4Bc5+dJyGEzYCaWur4iIam06tzgzbFqEszD2D14oEqL0OxpGfj/4fSCTW?= =?iso-8859-1?Q?0XZIANcAeMS81U/Ce3z9ufrJZdqA2ho=3D?= 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: Subject: Re: [smime] Problems with versions X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2022 11:59:42 -0000 Russ Housley writes:=0A=0A>I realize that your examp= le is hypothetical. However it cannot happen under=0A>RFC 5652.=0A=0AIt ca= n't happen if the spec never, ever changes, but it will happen if changes= =0Aare necessary at some point, e.g. due to PQC. As I mentioned in my orig= inal=0Amessage, this is exactly what the OpenPGP folks have run into right = now as=0Athey're trying to update RFC 4880, amd which the TLS folks ran int= o in spades=0Aand had to add all sorts of kludges to deal with. I was poin= ting out that if=0Athere's ever a need to update CMS, or even there isn't a= nd someone figures out=0Awhat a "certificate with a type of other" or "crl = with a type of other" is for=0Athe current RFC, it'll run into the same iss= ues that TLS and OpenPGP have run=0Ainto.=0A=0AFrom looking at the current = text:=0A=0A IF ((certificates is present) AND=0A (any certifica= tes with a type of other are present)) OR=0A ((crls is present) = AND=0A (any crls with a type of other are present))=0A T= HEN version MUST be 5=0A ELSE=0A IF (certificates is pre= sent) AND=0A (any version 2 attribute certificates are presen= t)=0A THEN version MUST be 4=0A ELSE=0A = IF ((certificates is present) AND=0A (any version 1 attri= bute certificates are present)) OR=0A (any SignerInfo stru= ctures are version 3) OR=0A (encapContentInfo eContentType= is other than id-data)=0A THEN version MUST be 3=0A = ELSE version MUST be 1=0A=0Awhat it's saying is:=0A=0A IF a certific= ate or CRL type that no-one can define is present=20=0A THEN version MUS= T be 5=0A ELSE=0A IF an attribute certificate but not quite the same at= tribute=20=0A certificate that would require a version of 3 is presen= t=0A THEN version MUST be 4=0A ELSE=0A IF an attribute certifi= cate is present OR=0A (some stuff that seems irrelevant at this poi= nt in the=20=0A processing)=0A THEN version MUST be 3=0A = ELSE=20=0A version MUST be 1=0A=0Awhich simplifies to:=0A=0A = IF an attribute certificate is present=20=0A THEN version MUST b= e 3=0A ELSE=20=0A version MUST be 1=0A=0Aalthough even then I = can't see why the presence of an attribute certificate=0Asomewhere further = down or a non-data eContentType would require a change in=0Athe SignedData = version.=0A=0ATo illustrate why requirements to set arbitrary implementatio= n-breaking=0Aversions is a problem, here's the SignedData from PKCS #7 in 1= 992:=0A=0ASignedData ::=3D SEQUENCE {=0A version Version,=0A digest= Algorithms DigestAlgorithmIdentifiers,=0A contentInfo ContentInfo,=0A = certificates [0] IMPLICIT ExtendedCertificatesAndCertificates OPTIONAL,= =0A crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,=0A signe= rInfos SignerInfos }=0A=0AAnd here's SignedData from RFC 5652 (and in betwe= en 2630, 3369, and 2853) as=0Ait applies thirty years later:=0A=0ASignedDat= a ::=3D SEQUENCE {=0A version CMSVersion,=0A digestAlgorithms Diges= tAlgorithmIdentifiers,=0A encapContentInfo EncapsulatedContentInfo,=0A = certificates [0] IMPLICIT CertificateSet OPTIONAL,=0A crls [1] IMPL= ICIT RevocationInfoChoices OPTIONAL,=0A signerInfos SignerInfos }=0A=0A= Apart from some fiddling with the ASN.1, e.g. deprecation of obsolete ASN.1= =0A'88 forms, and changing of names, it's the same thing. SignedData versi= on 1=0Ais the same as SignedData version 2 is the same as SignedData versio= n 3 is the=0Asame as SignedData version 4 is the same as SignedData version= 5, the only=0Athing that's changed each time is a requirement to (potentia= lly) set the=0Aversion field to something that ensures an existing implemen= tation can't=0Aprocess it any more.=0A=0APeter.