[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