[Anima] what to call different RFC8366 format artifacts

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 03 November 2020 19:33 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF59F3A10FE; Tue, 3 Nov 2020 11:33:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 Nv8jGMNBEjsh; Tue, 3 Nov 2020 11:33:10 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0227A3A10FD; Tue, 3 Nov 2020 11:33:09 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id BDB0938983; Tue, 3 Nov 2020 14:33:08 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QLdOaT7JMyjY; Tue, 3 Nov 2020 14:33:07 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5F19138982; Tue, 3 Nov 2020 14:33:07 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 164E9134A; Tue, 3 Nov 2020 12:05:35 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: anima@ietf.org, netconf@ietf.org
cc: iotops@ietf.org
X-Attribution: mcr
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Tue, 03 Nov 2020 12:05:35 -0500
Message-ID: <19352.1604423135@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/Sy_9ROYQLEdqfeaK2YQYGprEZuA>
Subject: [Anima] what to call different RFC8366 format artifacts
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Nov 2020 19:33:12 -0000

Hi, RF8366 specifies a YANG module for a voucher, and the format as
serialized to JSON, and signed by CMS.

In section 5.4, it is written:

 5.4.  CMS Format Voucher Artifact
    The IETF evolution of PKCS#7 is CMS [RFC5652].  A **CMS-signed voucher**,

In section 8.3, it is written:
   Encoding considerations:  *CMS-signed JSON* vouchers are ASN.1/DER
      encoded.

So it became natural for me to write "CMS-signed-JSON".
In development of RFC8366, we argued for using JOSE rather than CMS, but
there were, at the time (2016) lack of familiarity with JOSE, and concerns
about having FIPS-140 validation of that code.

In draft-ietf-anima-constrained-voucher, we introduce two new things:
  1) signing with COSE
  2) encoding with CBOR.

A number of people have written, rather than "CMS-signed-JSON", instead,
"JSON in CMS".   I wondered at the BRSKI design team call last Thursday if
perhaps that order of words translates better into Dutch or German, or ???

So to bikeshed the whole thing, please comment on preference in naming:

1) RFC8366:    CMS-signed-JSON  vs JSON-in-CMS.
2) CV:         CMS-signed-CBOR  vs CBOR-in-CMS.
3) CV:         COSE-signed-CBOR vs CBOR-in-COSE.
4) future ID:  JWS-signed-JSON  vs JSON-in-JOSE.

I note that for some of these "signed" is redundant.
We do not have COSE-signed-JSON, or JWS-signed-CBOR.

Which feels more natural to you?

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide