IETF Logo Mail Archive

Re: [COSE] AD Review of draft-ietf-cose-countersign-05

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 13 May 2022 13:24 UTC

Return-Path: <mcr@sandelman.ca>
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 A40ECC15EB3F for <cose@ietfa.amsl.com>; Fri, 13 May 2022 06:24:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.436
X-Spam-Level:
X-Spam-Status: No, score=-0.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no 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 vkumBQU1fedE for <cose@ietfa.amsl.com>; Fri, 13 May 2022 06:23:59 -0700 (PDT)
Received: from relay.sandelman.ca (unknown [IPv6:2a01:7e00:e000:2bb::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A3AAC159489 for <cose@ietf.org>; Fri, 13 May 2022 06:23:58 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [46.183.103.8]) by relay.sandelman.ca (Postfix) with ESMTPS id 6EFA21F480; Fri, 13 May 2022 13:23:56 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 0DF4E1A01EF; Fri, 13 May 2022 09:23:55 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Russ Housley <housley@vigilsec.com>, "cose@ietf.org" <cose@ietf.org>, "Roman D. Danyliw" <rdd@cert.org>
In-reply-to: <E9F23493-B607-46D0-8B1D-34BFCB451A35@vigilsec.com>
References: <BN2P110MB110783804C36D19F2B440E83DCC39@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM> <E9F23493-B607-46D0-8B1D-34BFCB451A35@vigilsec.com>
Comments: In-reply-to Russ Housley <housley@vigilsec.com> message dated "Thu, 12 May 2022 11:13:42 -0400."
X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Fri, 13 May 2022 09:23:55 -0400
Message-ID: <116824.1652448235@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/PDboWSs7o0DRMGS-dl6TUX9JYx0>
Subject: Re: [COSE] AD Review of draft-ietf-cose-countersign-05
X-BeenThere: cose@ietf.org
X-Mailman-Version: 2.1.34
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, 13 May 2022 13:24:03 -0000

Russ Housley <housley@vigilsec.com> wrote:
    > Assuming that happens soon, should this document now update the RFC
    > that comes from draft-ietf-cose-rfc8152bis-struct-15?

    > If so, then a small rewording to the above paragraph to:

    >    During the process of advancing COSE to Internet Standard, it was
    > noticed the description of the security properties of countersignatures
    > was incorrect for the COSE_Sign1 structure.  Since the security
    > properties that were described, those of a true countersignature, were
    > those that the working group desired, the decision was made to remove
    > all of the countersignature text from
    > [I-D.ietf-cose-rfc8152bis-struct]. This document defines a new
    > countersignature with the desired security properties.

    > Note that [I-D.ietf-cose-rfc8152bis-struct] obsoletes RFC 8152.

    > If you agree, then this document will update the RFC that comes from
    > draft-ietf-cose-rfc8152bis-struct-15, not RFC 8152.

While Updates appear in the document as backwards references, it does result
in meta-data on rfc-editor.org and DT that points forward.

So I think it's really important that RFC8152 receive a forward pointer to
draft-ietf-cose-countersign-05.   Can we list both?

Specifically, in the language of I-D.kuehlewind-update-tag (which I
acknowledge does not yet have IETF Consensus.. but I can still hope), the
Update to RFC8152 is an _Amends_ while the Update to
draft-ietf-cose-rfc8152bis-struct is an Extends.

This is how we handled it in a document in ANMIMA WG:
   https://www.ietf.org/archive/id/draft-ietf-anima-constrained-voucher-17.html#name-updates-to-rfc8366-and-rfc8

-- 
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email