Re: [Iotops] [Anima] what to call different RFC8366 format artifacts

Toerless Eckert <tte@cs.fau.de> Fri, 06 November 2020 16:06 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: iotops@ietfa.amsl.com
Delivered-To: iotops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF21E3A07CE; Fri, 6 Nov 2020 08:06:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.869
X-Spam-Level:
X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 UQ_HbrNohsJc; Fri, 6 Nov 2020 08:06:05 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51E4B3A07C4; Fri, 6 Nov 2020 08:06:03 -0800 (PST)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 58ED8548658; Fri, 6 Nov 2020 17:05:58 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 502E7440059; Fri, 6 Nov 2020 17:05:58 +0100 (CET)
Date: Fri, 06 Nov 2020 17:05:58 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: anima@ietf.org, netconf@ietf.org, iotops@ietf.org
Message-ID: <20201106160558.GA48249@faui48f.informatik.uni-erlangen.de>
References: <19352.1604423135@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <19352.1604423135@localhost>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/iotops/L5r25FPTnjIS-tgJZDpVHacGUvc>
Subject: Re: [Iotops] [Anima] what to call different RFC8366 format artifacts
X-BeenThere: iotops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IOT Operations <iotops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iotops>, <mailto:iotops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iotops/>
List-Post: <mailto:iotops@ietf.org>
List-Help: <mailto:iotops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iotops>, <mailto:iotops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Nov 2020 16:06:07 -0000

I like FOO-signed-BAR better because it reminds readers whose life does
not enter around FOO or BAR what this is about (signed object).

Maybe some time there are different options how FOO can sign BAR,
then we may need to add additional distinctions

On Tue, Nov 03, 2020 at 12:05:35PM -0500, Michael Richardson wrote:
> 
> 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
> 
> 
> 
> 



> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima


-- 
---
tte@cs.fau.de