[COSE] questions for the WG from 8152bis AUTH48
Benjamin Kaduk <kaduk@mit.edu> Fri, 18 February 2022 05:00 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: cose@ietfa.amsl.com
Delivered-To: cose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id 1CBED3A0958
for <cose@ietfa.amsl.com>; Thu, 17 Feb 2022 21:00:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001,
SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001]
autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44])
by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id TEY8nt7T5WWS for <cose@ietfa.amsl.com>;
Thu, 17 Feb 2022 20:59:56 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
(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 9485E3A094A
for <cose@ietf.org>; Thu, 17 Feb 2022 20:59:56 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56)
(User authenticated as kaduk@ATHENA.MIT.EDU)
by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 21I4xnoo032091
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT)
for <cose@ietf.org>; Thu, 17 Feb 2022 23:59:54 -0500
Date: Thu, 17 Feb 2022 20:59:49 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: cose@ietf.org
Message-ID: <20220218045949.GN12881@kduck.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/jKNukDzKx21MDxgGvp7YcFTylCY>
Subject: [COSE] questions for the WG from 8152bis AUTH48
X-BeenThere: cose@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: CBOR Object Signing and Encryption <cose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cose>,
<mailto:cose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cose/>
List-Post: <mailto:cose@ietf.org>
List-Help: <mailto:cose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cose>,
<mailto:cose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Feb 2022 05:00:06 -0000
Hi all, The chairs and I are continuing to work through the AUTH48 process for the 8152bis drafts, and a couple topics have come up that would benefit from some broader input. In https://datatracker.ietf.org/doc/html/draft-ietf-cose-rfc8152bis-struct-15#section-7.1 we we have a table of "Key Operation Values", discussing the various operations that are possible. Some of them include the statement "Requires private key fields", and for operations like "sign" or "unwraap key" this is pretty obviously true. But for "derive key" and "derive bits" this is less clear to me. In particular, my understanding is that I can do the derivation operations by combining a public key I control and a public key received from the peer. That, in turn, seems to imply that the serialized public key that I receive from the peer would be intended to be used for a derivation operation but would not contain the private key fields. Are we supposed to indicate the derivation operations in the "key_ops" field of such a public-key-only COSE_Key? I believe we are supposed to, and so have directed the RFC Editor to just remove the statement about "requires private key fields" for those two entries. This seems low-risk in that the statement itself is mostly informative, so we're either removing a false statement or removing something that's informative but obvious when you go to implement it. Do people agree with that interpretation of the "key_ops" for public-key-only key objects destined for derivation operations? The other question is in -algs; in https://datatracker.ietf.org/doc/html/draft-ietf-cose-rfc8152bis-algs#section-8 we start off with a rather awkward sentence "There are some situations that have been identified where identification of capabilities of an algorithm or a key type need to be specified." In particular (at least to me), the "identification ... needs to be specified" seems like the verb tenses don't even match up properly, or something of that nature, but I can't properly describe exactly what seems off. The current proposal from the RFC Editor is to dramatically replace this sentence with the bland "The capabilities of an algorithm or key type need to be specified in some situations". Does anyone object to that change? Thanks, Ben
- [COSE] questions for the WG from 8152bis AUTH48 Benjamin Kaduk
- Re: [COSE] questions for the WG from 8152bis AUTH… Michael Richardson
- Re: [COSE] questions for the WG from 8152bis AUTH… Ilari Liusvaara
- Re: [COSE] questions for the WG from 8152bis AUTH… Marco Tiloca
- Re: [COSE] questions for the WG from 8152bis AUTH… Göran Selander