Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45EB3C013D1E for ; Mon, 21 Oct 2024 12:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 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, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com 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 ihQnYeP-yjxv for ; Mon, 21 Oct 2024 12:46:54 -0700 (PDT) Received: from BYAPR05CU005.outbound.protection.outlook.com (mail-westusazolkn19010021.outbound.protection.outlook.com [52.103.2.21]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36980C28EB05 for ; Mon, 21 Oct 2024 12:46:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=mcyELHyiGAxB0CVN6ovdzHip9JNrwj7q3umY09EMvoaXNKHCCZUW0CgOS8U0rk2SS+6EX38R8Y0JWQUteIgsw9AGJsqGYQc+ULDo+qRPiIYIv2jt8H/3rLI/ry15/HyAujCub+cmwCeF+uv0tU6f4/p1L5mGLMcf7kRm0a5YQ5Vwf4SgXN4SKhm253J3RFQr4eGwFWzOpTyHwtrIF7gqHClinwtE1j2BfN3BcGY2aeJKkM2Mk6/vMk4WV7u+YrPTAV5x4lqcoImjgEJWdz1f31wP+Zayq5wU/yxAyPmyGMQ9jAODWjMJr5Og2HLgBjvhCJE/6h+0L7VvKeSAtbP6cQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=k9bUNnkD0OGApjkGr2nyaeIT54Ms1dK/dnWK/qAzX3Q=; b=ytWM4AdCS8WoocnPcq4RKybvIxezGtIe6K+Qx8jCq4Tx8+JWU+dDesmSBZhW964eFKwj/Mgv41HSasuo1TTFS/ZaTNpaDXEBYH7uONEmbnkn+92iiTuIPn5QYyHEHEHfXz7gQT1MWhCsaiq8qCMigcKIVD6gicko5Vy2rWyAwxUcPAYjMibffoRZjBuGXQ9/HGKbXJAjkSWePfbA34IR5+SvctoNRQMAuXMYO9NA8YDCsq5JE/sRys5n4Rd6qoyygCdQqczmb8As6sMS9vS/GSDgj9v0kcvik7isSXG/zEX5kEfnC/M81T0VZpvOWhTOQh6Pyg0+TEm9vweBWV5fZA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=k9bUNnkD0OGApjkGr2nyaeIT54Ms1dK/dnWK/qAzX3Q=; b=PtcT2zhdmJvaN5RyMFjZs4mOPs6jx8DjAx87Y0nSeal42cgUlj71Avom3rUKVM9UtitnaU8rqVpQM6tR4yk7L6Z31F7v4eamNmx4hVWqTEou35Y72fMQ4zuhuYYxK28w9JeWXBYMK7zXgIpkeY4PfC/I4YsjHbuzClncUUiIojQQdRXdx99UFNs8zvn+DzTlPIW1gYFXNwxAVl4KUCaHVn5NSYDSvmOoye9YS5Y3f1oMM7meJzpcsJJrQdOYTd8kA6FEvaI1yQ7RVd8zlPDjzcFNY7nAsjoimUgvtFyJvFV3jjgX5WhgqND6w3n9mMEakiuaq+DVfmfOFfAUL/KOMw== Received: from PH0PR07MB9077.namprd07.prod.outlook.com (2603:10b6:510:107::13) by BLAPR07MB7570.namprd07.prod.outlook.com (2603:10b6:208:29d::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8069.29; Mon, 21 Oct 2024 19:46:52 +0000 Received: from PH0PR07MB9077.namprd07.prod.outlook.com ([fe80::5075:92e8:a12d:d85f]) by PH0PR07MB9077.namprd07.prod.outlook.com ([fe80::5075:92e8:a12d:d85f%5]) with mapi id 15.20.8069.016; Mon, 21 Oct 2024 19:46:52 +0000 From: Michael Jones To: Neil Madden , Karen ODonoghue Thread-Topic: [jose] Re: 2nd WGLC for draft-ietf-jose-fully-specified-algorithms (Fully Specified Algorithms) Thread-Index: AQHa/rEfQIT8z7ELOUeOF5vdytT8k7KQQE4g Date: Mon, 21 Oct 2024 19:46:51 +0000 Message-ID: References: <83704458-AC56-4CD1-9E7F-2875671FC2D8@gmail.com> In-Reply-To: <83704458-AC56-4CD1-9E7F-2875671FC2D8@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PH0PR07MB9077:EE_|BLAPR07MB7570:EE_ x-ms-office365-filtering-correlation-id: e1ac3d41-b752-46d8-4a32-08dcf2091c0e x-microsoft-antispam: BCL:0;ARA:14566002|12050799009|8060799006|461199028|8062599003|19110799003|7092599003|15080799006|9400799024|4302099013|3412199025|440099028|10035399004|102099032|56899033|1602099012; x-microsoft-antispam-message-info: dIKTYbHB1GmKWLdqGTY+DVIVl3k2wb7a1/ZqEOb7KMkvnUDjWWDrNchK+9+shTGcG9+ECfk1OvvlI7ZwDVY+nX9D7hGubMS8ht5bB+hxu1v5zPzP4CPdj88isxeD517+cknu0ZRhDiZvpOx0xr4ApJSfdnM8v+CL4C7ZhHvafvUTCbEC6Bwyeek0Qgo4LXdaWshB9L3CoBpJGiF6d8OpQQXJMy/k/sx5kyWlc7Sf+4RNKYbU6ccbj69PzSjDu7+cfUdEgu0X3GetZyHmDU66vBdpat5P8vJdgQ5cEKHalSOtfniigCVvCwMoXl8x+SHtnhx8vPvymh7x8S3IlSKP2gYSWZAerx7mFsE7pAsnOW+zNDPZGLJ8UGcvpyzn84uOzvBdZoMNiW0ejkQYW1ueNKjmgkzOi0/xtD33ozbrLYHP1x/66tTbTmfbzVRduYQjHIPboiB5H5fxjQlcHiEnGEkTGLm8Z2z4J14xQGIeyecJIeNrWsT08ow6sHSxrW3qToMYRUQIOEACrsLgmS2t4GXgvYW8TqRM+isiw4ofhZ7eYxiFXuYf2scoK0/wSSoFoH01GbzS0B5bG9S/v/FXHtcewNtdiCNloONSHeJetUjJEfGbQpMAaVJCUwvS6ULpWrnZGO53Dn7fsDbgAWNSvmVTMjNUctf/+HhRTx4fPVX1laSQJnQvKrHl+JQNRKyxQgdit8LUhQ9fq8K6AlF8Tl7aTDlPKkIID8CvVphqtb/tHKNC9xi2/rgK3I6ighx/OGtrL7dog8qabr/5SkhAtLPmCpnH26eP6ujcT2vmXgsPHs/GGpc0WkPaSrI0ued8WPgTSqSNbzddAT15m8ZCDuhfcGH8KzppXFhRcZhPD4KXuBWChIqwb/7Q+r7Gd+SGkadM7Gm5fScMoR5rb5Rra3yGWfROgkfVxOsnb+dyVA88LPrX5XYj9pRXuFEOq7wm x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?41Rp6D6wgxaksPd6ELWMl7DMLOI54JtmzXKM6eU8zTd/w+/uZKrkxBIw0o?= =?iso-8859-1?Q?Uf/Hgvg+pU88uxDTlaYbzPid7nIs+npXO7FJHdUkTTJ4ZXKZWqklqA+t58?= =?iso-8859-1?Q?6U1S+cp/iE63nwnWkl6jqTfTpYxj6cG5wS4WWoWXJicFyHnB9R3UkMkscb?= =?iso-8859-1?Q?swsi79l5LQ4TaWW07hT7cNdy4amzMfrobXFU0cM4PYHqGFjTEbCwocNSo3?= =?iso-8859-1?Q?NsDJItUPRt2BwrpppV06u0MxNwXykwwzVkfiVKzw9UgATg/b6Fospy94e2?= =?iso-8859-1?Q?altUbd39X9RiMkpoZvE+gtuussvas0FZv2QsOw20qYONcZZoA0PHCpyOv+?= =?iso-8859-1?Q?CCQnbedM8kU2osp7Q74zpTr6hTDnXTSuT51FhPt7185LaNsUfphrUJCvCG?= =?iso-8859-1?Q?9aERHM+q0wENIRBNkxkRd5wfyCt3hor2biIHubhVuv74NICo1/VMQnJK4m?= =?iso-8859-1?Q?ixhYmf0hxNDmYBLIBwqLbpRgHTZI9Y0d3ivaPrqYMhe56VJeeEUr3cG4R9?= =?iso-8859-1?Q?FtXvxdoimCUsHrV235HH78FK7OdQ3Wfwe/bhyDjXrnvAcMuZMdlJGT4fc/?= =?iso-8859-1?Q?TYwncJ1QRS2Y7YHJzlbtUQ/yZtTiEiAXzj49kNjDmEGbpJjB4sl/d0T3dI?= =?iso-8859-1?Q?R5c6AiJqs/U1DiIXUMucG63UwuEfYcjxFQ6PnL4YIAzyTpGDce6vxw6gcV?= =?iso-8859-1?Q?52F1aAkpiiRyXBlE5to/y9npUV5AecfoRSXzSHOkrp10o9rpnHfLIOQ3Q+?= =?iso-8859-1?Q?byinHZdnadsZJ7TaqfF1nlSOmPeOcRAycEqkO4yrRKt32nDpf3TXg34r9Q?= =?iso-8859-1?Q?puf61DP6YRhO2RS0JeuaKmSeCM4OvJD7S/r9KY5Xy6FtOOGwOWIH912SDC?= =?iso-8859-1?Q?yjEFawSEHdXTQJqHrXvEzzpR+xZTLwretUH7IBrSJ7BsSP7a5V00/au3gQ?= =?iso-8859-1?Q?seG0I+lHQJKqn5hK5sjRs8seVr7LElkeSMy4ae55IvHVJSL7DYUfD8ZgDU?= =?iso-8859-1?Q?BZSjFXgHrTRljTN2+ac+TFWaN6BpEDqA4i3kP69O9qSPPO9HgYaX1qLjaL?= =?iso-8859-1?Q?42YkvXLGhkfRKRMH67QeSIZxZs2+qLDKKGQKa0spS492/PUXuthmWmjHVz?= =?iso-8859-1?Q?bgk8ZM3GPTeW0TCZoOViBcAd3b08Mi1zcFVOKcJqxp7LZ60LYisYtX40QO?= =?iso-8859-1?Q?DqRffMg5kz3JnpDPHBa8e4CaZIekhIoSPia3mBrlb05l99yIcm2JccOn6h?= =?iso-8859-1?Q?AxmqQA0Rjt68eNky5ePnT7zj/JSRzbaiU6g9dnsV9SSdvuWQpc2A68DMN8?= =?iso-8859-1?Q?O4QYEXDCpXwunBbyP0paEhqBud3onTAZ+UY7DaCbiHTXypfEqM+FkBFKAx?= =?iso-8859-1?Q?k0zFmvn6Tl?= Content-Type: multipart/alternative; boundary="_000_PH0PR07MB9077A3B719F24AC49AEC0B7AB7432PH0PR07MB9077namp_" MIME-Version: 1.0 X-OriginatorOrg: sct-15-20-7741-18-msonline-outlook-99cdb.templateTenant X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR07MB9077.namprd07.prod.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: e1ac3d41-b752-46d8-4a32-08dcf2091c0e X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2024 19:46:51.8775 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR07MB7570 Message-ID-Hash: S7T6FXCTZYK2M2Y7FOD7CQVDAXN2YS4J X-Message-ID-Hash: S7T6FXCTZYK2M2Y7FOD7CQVDAXN2YS4J X-MailFrom: michael_b_jones@hotmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-jose.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: JOSE WG X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bjose=5D_Re=3A_2nd_WGLC_for_draft-ietf-jose-fully-specified-algo?= =?utf-8?q?rithms_=28Fully_Specified_Algorithms=29?= List-Id: Javascript Object Signing and Encryption Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --_000_PH0PR07MB9077A3B719F24AC49AEC0B7AB7432PH0PR07MB9077namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for your comments, Neil. See the updates to the specification in ht= tps://www.ietf.org/archive/id/draft-ietf-jose-fully-specified-algorithms-06= .html. My replies are inline below, prefixed by "Mike>". -- Mike From: Neil Madden Sent: Wednesday, September 4, 2024 2:59 AM To: Karen ODonoghue Cc: JOSE WG Subject: [jose] Re: 2nd WGLC for draft-ietf-jose-fully-specified-algorithms= (Fully Specified Algorithms) It might be helpful if the authors could describe how they have addressed t= he feedback received? Mike> See below >From my point of view, there are still many problems with this document. AF= AICT, almost none of the points I've raised previously have been addressed.= Although the document no longer deprecates encryption algorithms, it still= contains problematic statements about them, and clauses like this one in s= ection 3.1: "Each of these multiple algorithms must be independently fully specified. T= he operations performed by each of them MUST NOT vary when used alongside o= ther algorithms. So for instance, for JOSE, alg values and enc values MUST = each be fully specified, and their behaviors MUST NOT depend upon one anoth= er." These requirements would make ECDH-ES with direct key agreement unusable, b= ecause it includes the "enc" value in the KDF context info, so very directl= y depends on the specific content encryption algorithm. (And this kind of c= ontext inclusion absolutely *should* be done for security). IMO most of sec= tion 3 is wrong or misleading and should be removed entirely. Mike> We removed the incorrect text. Thanks for catching this. As for rem= oving all the text about encryption, other reviewers explicitly thanked us = for our treatment of encryption and consider it to be in scope. That said,= we have significantly tightened the exposition but left the encryption sec= tion in the specification. Section 5 should say how implementations that want to support old and new a= lgorithms for a transition period should handle this: publish the same key = twice with different "alg" values, remove the "alg" field entirely (not a g= ood idea), etc. Mike> We've added text on continuing to use deprecated algorithms, per your= and G=F6ran's comments. We also added security considerations text on inc= luding "alg" values in JWKs and COSE Keys. Section 6.1 on RSA states: "This is not a problem in practice, because RSA libraries accommodate keys = of different sizes without having to use different code. Therefore, for exa= mple, there are not known cases in the wild where it would be useful to hav= e different algorithm identifiers for RSASSA-PKCS1-v1_5 with SHA-256 and 20= 48-bit keys versus 4096-bit keys or 8192-bit keys. Therefore, the RSA signa= ture algorithms are not replaced by this specification." But, as I've pointed out multiple times now, this is not the case. Many FIP= S-compliant HSMs limit RSA key sizes, e.g.: https://thalesdocs.com/gphsm/ptk/5.9/docs/Content/PTK-C_Admin/Sec_Policies_= User_Roles/Typ_Sec_Policies/FIPS.htm "RSA: must be 2048, 3072, or 4096 bits" I'm not pointing this out because I think we need to specify RSA key sizes = in algorithm identifiers, but to again point out that the definition of "fu= lly-specified" that this draft proposed is arbitrary and inconsistent. As I= 've said many times before, I would have far less concern about a document = that simply registers Ed25519/Ed448 and marks EdDSA as discouraged. Mike> Thanks for the FIPS reference. We've incorporated a FIPS 140-3 citat= ion and updated the RSA text accordingly. The first paragraph of the security considerations section 7 is outright wr= ong and should be removed. There is no additional attack surface before the= se changes. If anything, this spec introduces more attack surface! Mike> We've removed this paragraph. Appendix A is entirely opinion and should be removed - there is no consensu= s about which combinations of ECDH-ES algorithms should be considered and t= his document shouldn't make any statement about it. Mike> Appendix A reflects the state of the working group discussions on ECD= H. Others wanting to create fully-specified ECDH algorithms in the future = will have an easier job with this as a starting point. And again, there wa= s explicit support in the working group for continuing to discuss fully-spe= cified encryption algorithms. - Neil On 21 Aug 2024, at 15:10, Karen ODonoghue > wrote: JOSE working group members, This email initiates a second working group last call for the Fully Specified Algorithms document: https://datatracker.ietf.org/doc/draft-ietf-jose-fully-specified-algorithms= / The authors have updated the draft based on WGLC comments and discussions at IETF 120, and the chairs have polled the working group about the readiness for WGLC. Seeing no opposition, we've decided to proceed with a second WGLC. Please review the document in detail and reply to this message (keeping the subject line intact) with your opinion on the readiness of this document for publication and any additional comments that you have. This will be a three week WGLC. Please submit your responses by 13 September 2024. Thank you, Karen (for the JOSE WG chairs) _______________________________________________ jose mailing list -- jose@ietf.org To unsubscribe send an email to jose-leave@ietf.org --_000_PH0PR07MB9077A3B719F24AC49AEC0B7AB7432PH0PR07MB9077namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks for your com= ments, Neil.  See the updates to the specification in https://www.ietf.org/archive/id/draft-ietf-jose-fully-specified-algorithms-= 06.html.  My replies are inline below, prefixed by “Mike>= ”.

 

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;          -- Mike

 

From: Neil Madden <neil.e.madden@= gmail.com>
Sent: Wednesday, September 4, 2024 2:59 AM
To: Karen ODonoghue <kodonog@pobox.com>
Cc: JOSE WG <jose@ietf.org>
Subject: [jose] Re: 2nd WGLC for draft-ietf-jose-fully-specified-alg= orithms (Fully Specified Algorithms)

 

It might be helpful if the authors could describe how they have addressed the feedback received?

 

Mike> See below<= o:p>

 

From my point of view, there are still many problems= with this document. AFAICT, almost none of the points I’ve raised pr= eviously have been addressed. Although the document no longer deprecates en= cryption algorithms, it still contains problematic statements about them, and clauses like this one in section 3.1:

 

"Each of these m= ultiple algorithms must be independently fully specified. The operations pe= rformed by each of them MUST NOT vary when used alongside other algorithms.= So for instance, for JOSE, alg<= /span> values and enc valu= es MUST each be fully specified, and their behaviors MUST NOT depend upon o= ne another."

These requirements would make ECDH-ES with direct ke= y agreement unusable, because it includes the “enc” value in th= e KDF context info, so very directly depends on the specific content encryp= tion algorithm. (And this kind of context inclusion absolutely *should* be done for security). IMO most of section 3 is wrong = or misleading and should be removed entirely. 

 

Mike> We removed= the incorrect text.  Thanks for catching this.  As for removing = all the text about encryption, other reviewers explicitly thanked us for ou= r treatment of encryption and consider it to be in scope.  That said, we have significantly tightened the exposition but= left the encryption section in the specification.

 

Section 5 should say how implementations that want t= o support old and new algorithms for a transition period should handle this= : publish the same key twice with different “alg” values, remov= e the “alg” field entirely (not a good idea), etc.

 

Mike> We’v= e added text on continuing to use deprecated algorithms, per your and G=F6r= an’s comments.  We also added security considerations text on in= cluding “alg” values in JWKs and COSE Keys.

 

Section 6.1 on RSA states:

 

"This is not a problem in prac= tice, because RSA libraries accommodate keys of different sizes without hav= ing to use different code. Therefore, for example, there are not known cases in the wild where it would be useful to have dif= ferent algorithm identifiers for RSASSA-PKCS1-v1_5 with SHA-256 and 2048-bi= t keys versus 4096-bit keys or 8192-bit keys. Therefore, the RSA signature = algorithms are not replaced by this specification.”



But, as I’ve pointed out mult= iple times now, this is not the case. Many FIPS-compliant HSMs limit RSA ke= y sizes, e.g.: 



"RSA: must be 204= 8, 3072, or 4096 bits”



I’m not pointing this out because I think we need = to specify RSA key sizes in algorithm identifiers, but to again point out t= hat the definition of “fully-specified” that this draft proposed is arbitrary and inconsistent. As I’ve said many times befo= re, I would have far less concern about a document that simply registers Ed= 25519/Ed448 and marks EdDSA as discouraged.

 

Mike> Thanks for= the FIPS reference.  We’ve incorporated a FIPS 140-3 citation a= nd updated the RSA text accordingly.

 

The first paragraph of the security considerations s= ection 7 is outright wrong and should be removed. There is no additional at= tack surface before these changes. If anything, this spec introduces more a= ttack surface!

 

Mike> We’v= e removed this paragraph.

 

Appendix A is entirely opinion and should be removed= - there is no consensus about which combinations of ECDH-ES algorithms sho= uld be considered and this document shouldn’t make any statement abou= t it.

 

Mike> Appendix A= reflects the state of the working group discussions on ECDH.  Others = wanting to create fully-specified ECDH algorithms in the future will have a= n easier job with this as a starting point.  And again, there was explicit support in the working group for continuing = to discuss fully-specified encryption algorithms.

 

— Neil



On 21 Aug 2024, at 15:10, Karen ODonoghue <kodonog@pobox.com> wrote:<= /p>

 

JOSE working group members,

This email initiates a second working group last call for the Fully
Specified Algorithms document:
https://datatracker.ietf.org/doc/draft-ietf-jose-fully-specif= ied-algorithms/

The authors have updated the draft based on WGLC comments and
discussions at IETF 120, and the chairs have polled the working group
about the readiness for WGLC. Seeing no opposition, we've decided to
proceed with a second WGLC.

Please review the document in detail and reply to this message
(keeping the subject line intact) with your opinion on the readiness
of this document for publication and any additional comments that you
have.

This will be a three week WGLC. Please submit your responses by 13
September 2024.

Thank you,
Karen (for the JOSE WG chairs)

_______________________________________________
jose mailing list -- jose@ietf.org
To unsubscribe send an email to jose= -leave@ietf.org

 

--_000_PH0PR07MB9077A3B719F24AC49AEC0B7AB7432PH0PR07MB9077namp_--