Cryptographic Message Syntax (CMS) Content Types for Concise Binary Object Representation (CBOR)
draft-schaad-cbor-content-02

[Ballot comment]
Simple and easy to read document. But, as expressed by Mirja, I would really appreciate an explanation why this document was not even submitted to the CBOR mailing list.

Is "getting it done quickly" the only reason ?

Regards

-éric

[Ballot comment]
Just one minor comment:

Section 2

  The CBOR content type is intended to be encapsulated in the signed
  data and auth-enveloped data, but can be included in any CMS wrapper.
  It cannot be predicted if the compressed CMS encapsulation will
  provide compression as the content may be binary rather than text.

I might reword the "provide compression" bit, perhaps "produce a smaller
encoding" or "provide usable compression".  (Similarly for the CBOR sequence case.)

[Ballot comment]
Thanks for creating this document. I only have minor editorial comments.

---------------------------------------------------------------------------

Please expand "CMS" and "CBOR" in the title, the abstract, and the
introduction.

---------------------------------------------------------------------------

i-d nits reports:

  ** There are 8 instances of too long lines in the document, the longest one
    being 7 characters in excess of 72.

---------------------------------------------------------------------------

>  CborContentTypes { iso(1) member-body(2) usa(840)
>          rsadsi(113549) pkcs(1) pkcs9(9) smime(16) 0 id-mod-cbor-2019(TBD3) }

Wouldn't this conventionally be the following?

  "... smime(16) modules(0) id-mod-cbor-2019(TBD3) ..."
                  ^^^^^^^^^^

[Ballot comment]
No objection on the publication of this document but I really wonder why this was not just published as a document by the cbor working group...? Was there a review by the working group or an announcement on the mailing list?

[Ballot comment]
Editorial Nits
* Abstract. s/message based/message-based/

* Section 1. s/self describing/self-describing/

* Section 1. s/message based/message-based/

* Section 6.  Use of ‘does’ twice
OLD:
The new content
  types does mean that id-data does not need to be used to identify
  these content types and thus can reduce confusion.

NEW:
The new content
  types mean that id-data does not need to be used to identify
  these content types and thus can reduce confusion.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-schaad-cbor-content-01. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0) registry in the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry page at

https://www.iana.org/assignments/smi-numbers/

a single new registration will be made:

Decimal: [ TBD-at-Registration ]
Description: id-mod-cbor-2019
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review should be completed before your document is approved for publication as an RFC.

Second, in the SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1) registry in the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry page at

https://www.iana.org/assignments/smi-numbers/

two new registrations are to be made:

Decimal: [ TBD-at-Registration ]
Description: id-ct-cbor
Reference: [ RFC-to-be ]

Decimal: [ TBD-at-Registration ]
Description: id-ct-cborSequence
Reference: [ RFC-to-be ]

As this also requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review should be completed before your document is approved for publication as an RFC.

Third, in the CMS Inner Content Types registry on the MIME Media Type Sub-Parameter Registries registry page at

https://www.iana.org/assignments/media-type-sub-parameters/

two new registrations are to be made:

Name: cbor
Object identifier: 1.2.840.113549.1.9.16.1.TBD
Reference: [ RFC-to-be ]

Name: cborSequence
Object identifier: 1.2.840.113549.1.9.16.1.TBD
Reference: [ RFC-to-be ]

The value of TBD for each of these registrations will be set to match the registrations in the SMI Security for S/MIME CMS Content Type registry that are made in step two of the IANA actions (above).

As this also requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. We are currently requesting that an expert be designated for this registry.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Amanda Baber
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-11-22):

From: The IESG
To: IETF-Announce
CC: Sean Turner , alexey.melnikov@isode.com, sean+ietf@sn3rd.com, draft-schaad-cbor-content@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (CMS Content Types for CBOR) to Informational RFC


The IESG has received a request from an individual submitter to consider the
following document: - 'CMS Content Types for CBOR'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2019-11-22. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  CBOR is becoming a widely used method of doing content encoding.  CMS
  is still a widely used method of doing message based security.  This
  document defines a set of content types for CMS that hold CBOR
  content.

Contributing to this document

  This note is to be removed before publishing as an RFC.

  The source for this draft is being maintained in GitHub.  Suggested
  changes should be submitted as pull requests at TBD.  Editorial
  changes can be managed in GitHub, but any substantial issues need to
  be discussed on the COSE mailing list.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-schaad-cbor-content/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-schaad-cbor-content/ballot/


No IPR declarations have been submitted directly on this I-D.

# Summary

Sean Turner is the Document Shepherd.
Alexey Melnikov is the Sponsoring AD.

This is a short document that defines CMS content types for CBOR and CBOR Sequence. The former defines a content type for a single CBOR-encoded object and the later defines a content type for a sequence of CBOR-encoded objects.

The document is intended for Informational status because that is all that is needed.

# Review and Consensus

To the best of my knowledge there has been no extensive discussion about this draft.  That's not necessarily a bad thing because there's not really a lot of discussion necessary to define a CMS content type for these two CBOR-encoded objects.

# Intellectual Property

The Shepherd confirmed with the author that to his direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79.

# Other Points

Three OIDs need to be registered for this document: 1 for the ASN.1 module in Section 4 and one for each of the Content Type OIDs in Sections 2 and 3 (and technically in 4).  All of these are noted in the IANA Considerations Section.