Payload formats should explicitly mention CBOR-encoded objects

[malishav]

Table 2 ({{table_mediatypes}}) currently gives a summary of media types carried within request and responses for each of the supported EST functions:

|  URI  | Content-Format                                       | #IANA |
| /crts | N/A                                            (req) |   -   |
|       | application/pkix-cert                          (res) |  287  |
|       | application/pkcs-7-mime;smime-type=certs-only  (res) |  281  |
| /sen  | application/pkcs10                             (req) |  286  |
|       | application/pkix-cert                          (res) |  287  |
|       | application/pkcs-7-mime;smime-type=certs-only  (res) |  281  |
| /sren | application/pkcs10                             (req) |  286  |
|       | application/pkix-cert                          (res) |  287  |
|       | application/pkcs-7-mime;smime-type=certs-only  (res) |  281  |
| /skg  | application/pkcs10                             (req) |  286  |
|       | application/multipart-core                     (res) |   62  |
| /skc  | application/pkcs10                             (req) |  286  |
|       | application/multipart-core                     (res) |   62  |
| /att  | N/A                                            (req) |   -   |
|       | application/csrattrs                           (res) |  285  |

The Content-Format identifiers are however all related to ASN.1-encoded structures:

• PKCS#7
• PKCS#10
• PKCS#8

We should have the equivalents for CBOR-encoded objects. I-D.ietf-cose-cbor-encoded-cert currently defines Media Type application/cose-c509 with a usage parameter that allows to indicate a certificate chain. Media Type for PKCS#10 is missing. CBOR encoding and media type for PKCS#8 is also missing in I-D.ietf-cose-cbor-encoded-cert.

Once this is added in I-D.ietf-cose-cbor-encoded-cert, this document should register appropriate CoAP Content-Format identifiers for a given media type.

CC: @gselander @emanjon

[EskoDijk]

Should a CBOR version of application/csrattrs also be considered? That format had an issue that the semantics were not understood by most people and not clearly defined as well; see https://www.ietf.org/id/draft-ietf-lamps-rfc7030-csrattrs-07.html So not sure if that's something to stir into now.

[gselander]

See update to https://github.com/cose-wg/CBOR-certificates/issues/136

[malishav]

Should a CBOR version of application/csrattrs also be considered? That format had an issue that the semantics were not understood by most people and not clearly defined as well; see https://www.ietf.org/id/draft-ietf-lamps-rfc7030-csrattrs-07.html So not sure if that's something to stir into now.

@EskoDijk what is in your opinion the best way forward regarding csrattrs? Note that draft-ietf-cose-cbor-encoded-cert-07 already specifies the CBOR versions of different attributes, so what remains to be done seems to be the specification of the high-level csrattrs structure. Does this belong to EST-oscore?

[EskoDijk]

@EskoDijk what is in your opinion the best way forward regarding csrattrs? ... Does this belong to EST-oscore?

If the csrattrs (att) format and resource is included in EST-oscore in any way (currently as OPTIONAL) then the draft must also define the format of this resource. It can re-use the existing format from EST-coaps for sure. However, since C509 "CBOR versions" are provided for all the other resources/payloads it would be strange to not offer this for the att resource. It could be noted that this is left for future work (in this case it would be less strange -- understandable, since it's an optional feature, and there's some ongoing work still to clarify its use.)

And it would then belong to EST-oscore, since the original application/csrattrs format is also specified purely in EST scope in RFC 7030. (Or else it could go into a followup document of EST-oscore.)

I agree that the CBOR version of the format itself should be easy to define, re-using the already specified CBOR versions of the different attributes. So the syntax should be good - semantics is still to be clarified further in another document then.