[jose] Re: 2nd WGLC for draft-ietf-jose-fully-specified-algorithms (Fully Specified Algorithms)

Brian Campbell <bcampbell@pingidentity.com> Mon, 09 September 2024 21:38 UTC

Return-Path: <bcampbell@pingidentity.com>
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 42A03C14F705 for <jose@ietfa.amsl.com>; Mon, 9 Sep 2024 14:38:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.004
X-Spam-Level:
X-Spam-Status: No, score=-2.004 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.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 pedWcLuCzMw5 for <jose@ietfa.amsl.com>; Mon, 9 Sep 2024 14:38:21 -0700 (PDT)
Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0520C1840FB for <jose@ietf.org>; Mon, 9 Sep 2024 14:38:21 -0700 (PDT)
Received: by mail-vs1-xe2e.google.com with SMTP id ada2fe7eead31-49bc12c0041so1497189137.0 for <jose@ietf.org>; Mon, 09 Sep 2024 14:38:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; t=1725917901; x=1726522701; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Xx84CmIX65amJaw6z+3JD5nj7X+HIAndpVQS6p8aMTU=; b=MlLo0+mmwjSMvGhL8oChI+8W1hLVMfPSAREcX9A8YTBdNv5lB+SPqAWPWWZjpdE4dw 6FN5vjfCU/akGQK/9ZRl5Yuh1nHopORTfCl5Hyy8t32WjicQCNNzqvQw8tm2EIXRJKu1 N9G0/QDfF2Oj0CQF+/Nr2Z4iPGnREY/bjoFJSBZHo4vUQnd6uZUINRJRdYUKdOaiA3Os oaIfTfcri1IcbA+imElD41EnoQ1DKF8cMUbEYFG+NJXaemFB8FUio5UeT8ttMeyoKrAG FIS7QvFvLHDP95RyyaHwQS+WPgk3DjduScOlDrchht5GsvtqmjThvuV0yZ83iCp/R2aX 21/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725917901; x=1726522701; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Xx84CmIX65amJaw6z+3JD5nj7X+HIAndpVQS6p8aMTU=; b=A71cSvI1wyMaGIedRUIpLo1WmjhmKB2jfLj7fH6ZFaTfHs4MpVCvqXTUhzHV4nc7H4 bJTib1bNhWbcUHbW0uijgjIPIJ5RnGA19yIyMe2hFKfps8URB/x4xIt/2srYzCeB+/TM uaW8k8UePgsad5xXsqNB+YD3AF8kvesFyiikDQFOeNkSpty70g1VidPLzYpo0wkbW345 QbVYjAv62mju02Ijvm3cW1sb5vN+OFyNViBuVD0RA6DKcl7z/3IC6Rt0L+n9qgRS497s Drgd6OelxDzCt+GqwCK0vMsGRA3XVcmP/IuJt6cdFUlqWjFCYcus7AKoIITIdVwfj4VF 3lBQ==
X-Gm-Message-State: AOJu0Yx7p29B/9PquBmbK1MTGPEJUHcFC6yDJBrrTRei7A0VwsCdDDA8 rl+AsKAh0ps08ShB1/tyPyJXLIsD2n04RbzQ76MzOkK1uft6EvZweN+0WGTzreHrKXXRVYrH65X vpPah4LEzYbU2bo4z2eWGssAdC7Kst/ekTLbjIxIPmOibInmMACPHhNKf5HvJ0KA22hD9mrAUco Vg/uzKz4t3
X-Google-Smtp-Source: AGHT+IHuxjP2SNGSHQaRkhPZWKuWO05EbLvdM6Lv+uaRxWK2cS81BxCo5bouO7BKrLTdbWfgVFP5b43bkFODso/LDi0=
X-Received: by 2002:a05:6102:942:b0:498:ccd9:5b1e with SMTP id ada2fe7eead31-49bde149e97mr13595663137.4.1725917900429; Mon, 09 Sep 2024 14:38:20 -0700 (PDT)
MIME-Version: 1.0
References: <CA+mgmiOEbk9qjDwNTu198QVWAGqcuKNSPd2F-YtngcLZwjunZw@mail.gmail.com> <GVXPR07MB9678C278636D28A01AA85C44898F2@GVXPR07MB9678.eurprd07.prod.outlook.com> <PAXPR07MB88443BE71B6DDC81F845A2BDF49D2@PAXPR07MB8844.eurprd07.prod.outlook.com> <CALAqi_9-ZDj=nK7BX8T_OW+x4JB-Dq79H6NLhZGVCR3hYT+7vg@mail.gmail.com>
In-Reply-To: <CALAqi_9-ZDj=nK7BX8T_OW+x4JB-Dq79H6NLhZGVCR3hYT+7vg@mail.gmail.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 09 Sep 2024 15:37:54 -0600
Message-ID: <CA+k3eCRBeUXockD5TR+kOHTK-zW+Womds=C5ucrX1oGaQRpTjQ@mail.gmail.com>
To: Filip Skokan <panva.ip@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000005df4420621b69352"
Message-ID-Hash: VUNO4QNOUK2NEHLA3IA2AXVWXVNLWNT4
X-Message-ID-Hash: VUNO4QNOUK2NEHLA3IA2AXVWXVNLWNT4
X-MailFrom: bcampbell@pingidentity.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@ietf.org" <jose@ietf.org>, "cose@ietf.org" <cose@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [jose] Re: 2nd WGLC for draft-ietf-jose-fully-specified-algorithms (Fully Specified Algorithms)
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/6oLu6kaHzGAbNkSP3zfU43YMYYE>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Owner: <mailto:jose-owner@ietf.org>
List-Post: <mailto:jose@ietf.org>
List-Subscribe: <mailto:jose-join@ietf.org>
List-Unsubscribe: <mailto:jose-leave@ietf.org>

I support adoption.

On Mon, Sep 9, 2024 at 2:28 PM Filip Skokan <panva.ip@gmail.com> wrote:

> I would like to thank the authors for their diligent work on the document.
> Here's my 2nd WGLC feedback
>
> I am comparing the document status before the first WGLC (draft 02) and
> now
> <https://author-tools.ietf.org/iddiff?url1=draft-ietf-jose-fully-specified-algorithms-02&url2=draft-ietf-jose-fully-specified-algorithms-05&difftype=--html>.
> I appreciate the new section *4.4. Defining Deprecated and Prohibited* and
> am also recognizing the new COSE ECDSA registrations that enable continued
> use of Brainpool curves with COSE in a fully-specified manner.
>
> I am not certain about which discussion led to the entirety of section 3.
> Fully-Specified Encryption, nevertheless in its language it states
>
> > Each of these multiple algorithms must be independently fully
> specified.  The operations performed by each of them MUST NOT vary when
> used alongside other algorithms.  So for instance, for JOSE, alg values and
> enc values MUST each be fully specified, and their behaviors MUST NOT
> depend upon one another.
>
> This would not be the case for either one of the JOSE ECDH-ES proposed
> algorithms (which were presented at the last meeting), in each of them
> "enc" informs "alg" about the expected CEK length output. Additionally, in
> ECDH-ES direct the "enc" value is directly used in ConcatKDF too.
>
> I'm not sure whether the contradiction between this text in section 3.1.
> and the above is okay or not given that the document no longer specifies
> any new ECDH algorithm identifiers. FWIW in 3.3.1. it clearly states the
> existing algorithms are not fully-specified but are polymorphic so this
> text wouldn't disqualify them. It is nevertheless confusing.
>
> From section 3.3.1.  Elliptic Curve Diffie-Hellman (ECDH)
>
> > While Appendix A describes possible fully-specified ECDH algorithms that
> could be registered for JOSE and COSE, the working group decided to leave
> decisions about which fully-specified ECDH algorithms to register to future
> specifications, if needed.
>
> This is not true because these would not be fully-specified; the "alg"
> ConcatKDF always use of elements from "enc", i.e. they depend on one
> another. While I asked that at least the algorithm identifiers be removed
> from Appendix A (which was done and it fulfilled my feedback from the IETF
> meeting during which granted, I was remote and half asleep), I came to
> think the entirety of Appendix A should probably be removed instead.
>
> From section 3.2. Analysis of Modes of Encryption
>
> > It does register a small set of new fully-specified encryption
> algorithms, so that polymorphic encryption algorithms need not be used.
>
> It doesn't anymore.
>
> Because the list feedback seems to circle around the encryption bits
> over and over again and even contradicting itself at one point, I would
> like to propose to remove section 3 and *only focus on the
> Fully-Specified Digital Signature Algorithm Identifiers. *I'm hoping to
> be able to start transitioning away from the "EdDSA" algorithm identifier
> soon.
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Thu, 5 Sept 2024 at 10:29, Göran Selander <goran.selander=
> 40ericsson.com@dmarc.ietf.org> wrote:
>
>> (About target audience:  This draft is proposing to deprecate algorithms
>> in the COSE IANA registry. It would be great if it by default was
>> circulated also on the COSE WG mailing list to enable a timely discussion
>> among those affected.)
>>
>>
>>
>> With reference to a previous thread on this topic:
>>
>> https://www.mail-archive.com/cose@ietf.org/msg03799.html
>>
>> The term “deprecated” is still used in this draft with a different
>> meaning compared to RFC8996 and RFC9325. It doesn’t help that you in this
>> document point out that you are using the word with a different meaning
>> that people are used to, very much fewer people will read this document
>> than those that stumble on the term used in registries and understand it
>> from other contexts.
>>
>>
>>
>> Moreover, this overload of terminology is actually  unnecessary:
>>
>>
>>
>> Section 4.4
>>
>> > The terms "Deprecated" and "Prohibited" as used by JOSE and COSE
>> registrations are currently undefined.
>>
>>
>>
>> So, in fact this provides a unique opportunity to disambiguate and avoid
>> the otherwise inevitable confusion that will come up over and over again
>> arising from the use of the same term with different meanings. A number of
>> perfectly good alternative terms were suggested in the referenced mail
>> thread.
>>
>>
>>
>> Moreover, for systems that makes use of the COSE IANA registry and
>> specifies algorithms with enough parameters to make them completely
>> determined, for example EDHOC cipher suites, there is no need to change or
>> abandon the use of the current algorithms. Hence the recommendation
>> (“SHOULD”) in the definition does not apply to such systems, and that
>> circumstance should be stated as an exception to the recommendation.
>>
>>
>>
>>
>>
>> In summary
>>
>>
>>
>>    - use a different term
>>    - make it clear that current algorithms may be used in case a
>>    separate specification adds the necessary information to make them fully
>>    specified
>>
>>
>>
>>
>>
>> Göran
>>
>>
>>
>>
>>
>> *From: *John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>
>> *Date: *Thursday, 22 August 2024 at 11:10
>> *To: *cose@ietf.org <cose@ietf.org>
>> *Subject: *[COSE] FW: [jose] 2nd WGLC for
>> draft-ietf-jose-fully-specified-algorithms (Fully Specified Algorithms)
>>
>> Forwarding to the COSE list as the document updates both RFC 8152 and RFC
>> 9053.
>>
>> Cheers,
>> John
>>
>>
>>
>> *From: *Karen ODonoghue <kodonog@pobox.com>
>> *Date: *Wednesday, 21 August 2024 at 16:12
>> *To: *JOSE WG <jose@ietf.org>
>> *Subject: *[jose] 2nd WGLC for
>> draft-ietf-jose-fully-specified-algorithms (Fully Specified Algorithms)
>>
>> JOSE working group members,
>>
>> This email initiates a second working group last call for the Fully
>> Specified Algorithms document:
>>
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-jose-fully-specified-algorithms%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C4d5ca1448df945ce272908dcc1eb446e%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638598463418037480%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=lC1d%2Bvw9fTh%2FG2brNNztghIYFbp4pnGwjqvfN%2Bbqrn8%3D&reserved=0
>> <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
>> _______________________________________________
>> jose mailing list -- jose@ietf.org
>> To unsubscribe send an email to jose-leave@ietf.org
>>
> _______________________________________________
> jose mailing list -- jose@ietf.org
> To unsubscribe send an email to jose-leave@ietf.org
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._