Subject: [core-parameters] Core content-format number allocation

From: peter van der Stok <[email-masked]>
Date: Fri, 25 May 2018 09:27:08 +0200

Dear core parameter experts,

In draft-ietf-ace-coap-est we want to allocate content format numbers to 
4 already existing media formats.
LWM2M people are implementing the est-coaps specification and want to 
deploy it as quickly as possible.
Therefore, they need to know the allocated numbers to write into their 
code.
An early allocation before publication of the draft as RFC will be 
appreciated.

Below the IANA text from the draft, using TBD1 - TBD4 as allocated 
numbers.

Many thanks,

peter

__________________________________________________________________________________________________________

8.1.  Content-Format registry

    Additions to the sub-registry "CoAP Content-Formats", within the
    "CoRE Parameters" registry are needed for the below media types.
    These can be registered either in the Expert Review range (0-255) or
    IETF Review range (256-9999).

    1.

        *  application/pkcs7-mime
        *  Type name: application
        *  Subtype name: pkcs7-mime
        *  ID: TBD1
        *  Required parameters: None
        *  Optional parameters: None
        *  Encoding considerations: binary
        *  Security considerations: As defined in this specification
        *  Published specification: [RFC5751]
        *  Applications that use this media type: EST

    2.

        *  application/pkcs8
        *  Type name: application
        *  Subtype name: pkcs8
        *  ID: TBD2
        *  Required parameters: None
        *  Optional parameters: None
        *  Encoding considerations: binary
        *  Security considerations: As defined in this specification
        *  Published specification: [RFC5958]
        *  Applications that use this media type: EST

    3.

        *  application/csrattrs
        *  Type name: application
        *  Subtype name: csrattrs
        *  ID: TBD3
        *  Required parameters: None
        *  Optional parameters: None
        *  Encoding considerations: binary
        *  Security considerations: As defined in this specification
        *  Published specification: [RFC7030]
        *  Applications that use this media type: EST

    4.

        *  application/pkcs10
        *  Type name: application
        *  Subtype name: pkcs10
        *  ID: TBD4
        *  Required parameters: None
        *  Optional parameters: None
        *  Encoding considerations: binar
        *  Security considerations: As defined in this specification
        *  Published specification: [RFC5967]
        *  Applications that use this media type: EST

___________________________________________________________________________________________

-- 
Peter van der Stok
vanderstok consultancy
mailto: [email-masked]
www: www.vanderstok.org
tel NL: +31(0)492474673     F: +33(0)966015248

---

From: Klaus Hartke <[email-masked]>
Date: Fri, 25 May 2018 09:48:35 +0200

Hi Peter,

I see you’re requesting Content-Format IDs for the following existing media
types:

- application/pkcs7-mime
- application/pkcs8
- application/csrattrs
- application/pkcs10

A Content-Format is the combination of a media type and a content coding.
Please specify the content coding(s) you want to use with each media type.
The possible set of content codings can be found at
https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding

Please format your request as a table that looks like Table 9 in
https://tools.ietf.org/html/rfc7252#section-12.3 (one row for each
combination of a media type and a content coding)

It seems “application/pkcs7-mime“ actually does define a media type
parameter, “smime-type ”. RFC 5751 says:

   Because there are several types of application/pkcs7-mime objects, a
   sending agent SHOULD do as much as possible to help a receiving agent
   know about the contents of the object without forcing the receiving
   agent to decode the ASN.1 for the object.  The Content-Type header
   field of all application/pkcs7-mime objects SHOULD include the
   optional "smime-type" parameter, as described in the following
   sections.

So it seems the parameter is more or less required. Do you want to register
a Content-Format ID for each defined smime-type value? Then the list of
media types (that need to be paired with a content coding) looks like this:

- application/pkcs7-mime; smime-type=“enveloped-data”
- application/pkcs7-mime; smime-type=“signed-data”
- application/pkcs7-mime; smime-type=“certs-only”
- application/pkcs7-mime; smime-type=“compressed-data”
- application/pkcs8
- application/csrattrs
- application/pkcs10

Klaus

On Fri 25. May 2018 at 09:27, peter van der Stok <[email-masked]> wrote:

> _______________________________________________
> core-parameters mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core-parameters
>

---

From: peter van der Stok <[email-masked]>
Date: Fri, 25 May 2018 10:58:28 +0200

HI Klaus,

Thanks for the quick reaction, and thanks for pointing out some existing 
other smime types.
I did a search in RFC 7030, and came up with other necessary smime 
types.

Below the table as required for est-coap draft: (I will change the draft 
accordingly)

- application/pkcs7-mime; smime-type=“server-generated-key”; Encoding = 
"binary"; ID = TBD1; Reference = RFC5751, RFC7030
- application/pkcs7-mime; smime-type=“certs-only”; Encoding = "binary"; 
ID = TBD2; Reference = RFC5751
- application/pkcs7-mime; smime-type=“CMC-request”; Encoding = "binary"; 
ID = TBD3; Reference = RFC5751, RFC5273
- application/pkcs8; smime-type = ---; Encoding = "binary"; ID = TBD4; 
Reference = RFC5958
- application/csrattrs; smime-type = ---; Encoding = "binary"; ID = 
TBD5; Reference = RFC7030
- application/pkcs10; smime-type = ---; Encoding = "binary"; ID = TBD6; 
Reference = RFC5967

I expect the Encoding is orthogonal to the media type and smime type 
specification.

Many thanks,

peter

Klaus Hartke schreef op 2018-05-25 09:48:
> Hi Peter,
> 
> I see you’re requesting Content-Format IDs for the following
> existing media types:
> 
> - application/pkcs7-mime
> - application/pkcs8
> - application/csrattrs
> - application/pkcs10
> 
> A Content-Format is the combination of a media type and a content
> coding. Please specify the content coding(s) you want to use with each
> media type. The possible set of content codings can be found at
> It seems “application/pkcs7-mime“ actually does define a media
> type parameter, “smime-type ”. RFC 5751 says:
> 
> So it seems the parameter is more or less required. Do you want to
> register a Content-Format ID for each defined smime-type value? Then
> the list of media types (that need to be paired with a content coding)
> looks like this:
> 
>> www: www.vanderstok.org [1]
> Links:
> ------
> [1] http://www.vanderstok.org

---

From: Klaus Hartke <[email-masked]>
Date: Fri, 25 May 2018 11:22:35 +0200

What about “CMC-Response”?

There’s a registry for “smime-type” values at
https://www.iana.org/assignments/media-type-sub-parameters/media-type-sub-parameters.xhtml#smime
Would it make sense to simply allocate a Content-Format ID to each of them?

The media type and the content coding are orthogonal. However, “binary” is
not a valid content coding. (It’s really confusing that the column is
labeled “Encoding”; content coding is what is meant.) Possible content
codings are listed in
https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding
You probably want the “identity“ content coding.

“application/pkcs8” and the other two media types don’t have the
“smime-type” parameter defined, so just remove that bit.

Otherwise the table looks good to me.

Klaus

---

From: peter van der Stok <[email-masked]>
Date: Fri, 25 May 2018 11:43:56 +0200

Hi Klaus,

the updated table. some reactions to your very useful remarks further 
below. many thanks,

greetings,

Peter

- application/pkcs7-mime; smime-type=“server-generated-key"; Encoding 
="identity"; ID = TBD1; Reference = RFC5751, RFC7030, RFC7231
- application/pkcs7-mime; smime-type=“certs-only”; Encoding = 
"identity"; ID = TBD2; Reference = RFC5751, RFC7231
- application/pkcs7-mime; smime-type=“CMC-request”; Encoding = 
"identity"; ID = TBD3; Reference = RFC5751, RFC5273, RFC7231
- application/pkcs7-mime; smime-type=“CMC-response”; Encoding = 
"identity"; ID = TBD4; Reference = RFC5751, RFC5273, RFC7231
- application/pkcs8; Encoding = "identity"; ID = TBD5; Reference = 
RFC5958, RFC7231
- application/csrattrs; Encoding = "identity"; ID = TBD6; Reference = 
RFC7030, RFC7231
- application/pkcs10; Encoding = "identity"; ID = TBD7; Reference = 
RFC5967, RFC7231

> What about “CMC-Response”?

thanks, I missed that one.

> Would it make sense to simply allocate a Content-Format ID to each of
I prefer to only specify those used in RFC7030
> 
> The media type and the content coding are orthogonal. However,
> “binary” is not a valid content coding. (It’s really confusing
> that the column is labeled “Encoding”; content coding is what is
> meant.) Possible content codings are listed in

You are right. looks most probable one.
>>> Because there are several types of application/pkcs7-mime
>> objects,
>>> a
>>> On Fri 25. May 2018 at 09:27, peter van der Stok
>> <[email-masked]>
>>> wrote:
>>> 
>>>> LWM2M people are implementing the est-coaps specification and
>> want
>>>> to
>>>> www: www.vanderstok.org [1] [1]

---

From: Klaus Hartke <[email-masked]>
Date: Fri, 25 May 2018 12:00:29 +0200

Thumbs up 👍

On Fri 25. May 2018 at 11:44, peter van der Stok <[email-masked]> wrote:

> >> "binary";
> >> "binary";

---

From: Esko Dijk <[email-masked]>
Date: Fri, 25 May 2018 13:12:12 +0000

Hello Peter & all,

Would it be needed to clarify the (binary) transfer encoding more? RFC 5751 states "If no Content-Transfer-Encoding header field is present, the transfer encoding is presumed to be 7BIT".
For the EST over CoAP case and embedded case in general, I would assume that nodes can assume by default 8-bit encoding is used and accepted.
All parties involved in the exchange would know how to handle 8-bit data and there's no need to assume it will only be 7-bit.  So I would expect one more Content-Transfer-Encoding=X attribute is needed for the pkcs7-mime types? With the right value of X (didn't look this up yet).

Best regards
Esko

-----Original Message-----
From: core-parameters <[email-masked]> On Behalf Of peter van der Stok
Sent: Friday, May 25, 2018 11:44
To: Klaus Hartke <[email-masked]>
Cc: [email-masked]; Hannes Tschofenig <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [core-parameters] Core content-format number allocation

Hi Klaus,

the updated table. some reactions to your very useful remarks further below. many thanks,

greetings,

Peter

- application/pkcs7-mime; smime-type=“server-generated-key"; Encoding ="identity"; ID = TBD1; Reference = RFC5751, RFC7030, RFC7231
- application/pkcs7-mime; smime-type=“certs-only”; Encoding = "identity"; ID = TBD2; Reference = RFC5751, RFC7231
- application/pkcs7-mime; smime-type=“CMC-request”; Encoding = "identity"; ID = TBD3; Reference = RFC5751, RFC5273, RFC7231
- application/pkcs7-mime; smime-type=“CMC-response”; Encoding = "identity"; ID = TBD4; Reference = RFC5751, RFC5273, RFC7231
- application/pkcs8; Encoding = "identity"; ID = TBD5; Reference = RFC5958, RFC7231
- application/csrattrs; Encoding = "identity"; ID = TBD6; Reference = RFC7030, RFC7231
- application/pkcs10; Encoding = "identity"; ID = TBD7; Reference = RFC5967, RFC7231

> https://www.iana.org/assignments/media-type-sub-parameters/media-type-
> sub-parameters.xhtml#smime Would it make sense to simply allocate a 
> Content-Format ID to each of them?
> “binary” is not a valid content coding. (It’s really confusing that 
> the column is labeled “Encoding”; content coding is what is
> https://www.iana.org/assignments/http-parameters/http-parameters.xhtml
> #content-coding You probably want the “identity“ content coding.

>> Thanks for the quick reaction, and thanks for pointing out some 
>> existing other smime types.
>> "binary"; ID = TBD2; Reference = RFC5751
>> "binary"; ID = TBD3; Reference = RFC5751, RFC5273
>> - application/pkcs8; smime-type = ---; Encoding = "binary"; ID = 
>> TBD4; Reference = RFC5958
>> - application/pkcs10; smime-type = ---; Encoding = "binary"; ID = 
>> TBD6; Reference = RFC5967
>> 
>>> sending agent SHOULD do as much as possible to help a receiving 
>>> agent know about the contents of the object without forcing the
>> receiving
>>>> Therefore, they need to know the allocated numbers to write into 
>>>> their code.