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 <[email protected]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide




Attachment: signature.asc
Description: PGP signature

_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima

Reply via email to