Subject: [Cbor] 🔔 2nd WGLC on cbor-file-magic-08

From: Christian Amsüss <[email-masked]>
Date: Wed, 9 Feb 2022 16:46:13 +0100

Hello CBOR group,

while the first WGLC on cbor-file-magic showed the WG's approval of the
document in general, there has been a large addition[1] that, even
though not normative, does alter the set of use cases.

Unless any objections are raised before Wednesday 16th (one week from
now), this document will be sent on to the IESG for approval and
publication, along with the shepherd writeup I'm assembling.

Best regards,
Christian

[1]: https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-file-magic-08.txt&url1=draft-ietf-cbor-file-magic-02.txt

  The main addition is appendix C, most other changes are editorial.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 9 Feb 2022 10:50:53 -0500

> publication, along with the shepherd writeup I'm assembling.

A side note here: While we (the chairs) know a week is a short time,
we think the changes are solidly discussed and not controversial, and
working group participants still can review and make comments during
the AD Evaluation and IETF Last Call periods if that's necessary.

Barry

---

From: Christian Amsüss <[email-masked]>
Date: Tue, 22 Feb 2022 14:19:42 +0100

Hello file-magic authors,

as part of my shepherd write-up I'm reviewing the altest file-magic
document as it is passing working group last call. All these comments
are (presumably) editorial in nature and do not alter that outcome.

* "for each major type of object that they might store on disk": It is
  not used as a proper name, but "major type" might ring the bell of
  "first 3 bits" of CBOR, which AIU is not intended here.

  (Suggestion: "for each kind of object that they might store on disk").

* 5.3: At latest here, I'd have expected to read something about the
  information that is lost when using this tag with 2.2. Maybe there
  should be a line (not for IANA but for users, so maybe in a different
  section) that outlines when this works with (non)CBOR content formats
  and with which encodings.

  I think I understand now that the 5.3 tags can be used with either
  2.2, 2.3 or C (55899, 55800 and 55801), but

  * with 55899 the ct tags can only be used if the content format is a
    CBOR content format and coding is identity (and then tags a value)
  * with 55900 the ct tags can only be used if the content format is a
    CBOR-sequence content format and coding is identity (and then tags
    a byte string)
  * with 55901 the ct tags can always be used, and tag a byte string
    (which is also encoded according to the coding that is part of the
    ct)

  If all these should be allowed, I think this should be spelled out
  somewhere -- otherwise the examples appear to be conflicting.

* (Maybe security) considerations: 3.2 talks of trivially concatenated
  data items. If CBOR Tag Sequence is used and the data gets literally
  "concatenated", (say, `cat *.cborseq > outfile`), one might wind up
  with self-described tags in the middle of the sequence. (As we do
  with BOMs).

  Have BOMs caused issues in the past? If so, would you care for grave
  words we can haul against those who repeat inner-BOMs with CBOR?

* A.1: This appears to be in direct conflict with the 2.2.1 example
  (where the same tag is used with a non-bstr content). By the above the
  limitation to bstr may still make sense, but only in the context of a
  55800 or 55801 tag (but there, the tagged value is always not only
  bstr but even precisely 'BOR'). Maybe the example would be clearer if
  it would reference one of 2.2, 2.3 and appendix C.

Best regards
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Michael Richardson <[email-masked]>
Date: Wed, 23 Feb 2022 14:08:07 -0500

https://github.com/cbor-wg/cbor-magic-number/pull/17/files

    >   (Suggestion: "for each kind of object that they might store on

done.

    > and with which encodings.

I've tried how to understand this comment, but I'm failing.
Which information is lost?

    > 2.2, 2.3 or C (55899, 55800 and 55801), but

good...

    > CBOR content format and coding is identity (and then tags a value)

55899 marks CBOR, so the content had better be CBOR.

    > with 55900 the ct tags can only be used if the content format is a
    > CBOR-sequence content format and coding is identity (and then tags a
    > byte string)

    > * with 55901 the ct tags can always be used, and tag a
    > byte string (which is also encoded according to the coding that is part
    > of the ct)

55901 could be used with any content, because it makes no promise about the content.
For CBOR encoded things, any of these tags could be used.
Are you suggesting that we tell people not to use 55901 with CBOR content?

    > with self-described tags in the middle of the sequence. (As we do with
    > BOMs).

I have added:
https://github.com/cbor-wg/cbor-magic-number/commit/23c4176796d83e4d69ba56ab8a9b7f45cd691272

  The program involved may throw errors or warnings on the CBOR Tag Sequence if they have not yet been updated, but this may not be a problem.
  -If it is, then consideration should be given to CBOR Tag Wrapped.

  +There are situations where multiple objects may be concatenated into a single file.
  +If each object is preceeded by a a CBOR Tag Sequence then there may be multiple Tag Sequences in the file.
  +If it is, then consideration should be given to CBOR Tag Wrapped instead.

  +It is even possible that objects are of different types, and this may be a feature or a bug.

  +As an example from legacy PEM encoded PKIX certificates, many programs
  +accept a series of PKIX certificates in a single file in order to set up a
  +certificate chain.
  +The file would contain not just the End-Entity (EE) certificate, but also
  +any subordinate certification authorities (CA) needed to validate the EE.
  +This mechanism actually only works for PEM encoded certificates, and not
  +DER encoded certificates.
  +One of the reasons for this specification is to make sure that CBOR
  +encoded certificates do not suffer from this problem.

  +As an example of mixing of types, some TLS server programs also can accept
  +both their PEM encoded private key, and their PEM encoded certificate in
  +the same file.

    > words we can haul against those who repeat inner-BOMs with CBOR?

I won't talk about BOMs.
My understanding is that they were a problem until people figured out that
they could be dropped.

    > 55800 or 55801 tag (but there, the tagged value is always not only bstr
    > but even precisely 'BOR'). Maybe the example would be clearer if it
    > would reference one of 2.2, 2.3 and appendix C.

I think that you are having a problem with A.1 wrapping a CBOR thing in
55801?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Christian =?iso-8859-1?Q?Ams=FCss?= <[email-masked]>
Date: Thu, 24 Feb 2022 07:55:12 +0100

> Which information is lost?

I've phrased this badly: The ct encoded in the tag gives information
about the (structured) media type and the content coding. In the 2.2 and
2.3 use cases, the information in the content coding is ... discarded
(should be the word to use rather than lost), if it is acceptable that a
ct for application/mine+cbor@gzip is also used in this tag. Or the
content coding is required to be identity, in which case any
non-identity content coding would be ruled out (just like any non-CBOR
media types are ruled out).

> 55899 marks CBOR, so the content had better be CBOR.

any tag tags CBOR, so the content needs to be CBOR.

> Are you suggesting that we tell people not to use 55901 with CBOR content?

I'm not saying that (and am pretty meh about whether it should be).

I'm just saying that the formalities of defining the tags are complex
(because 55799(ct1234(X)) can take anything for X, whereas
55801(ct1234(X)) takes precisely a bytestring ('BOR'). The text in the
IANA section 5.3 reflect that correctly, and I haven't found text that
sets the rules (rather than implying them).

> https://github.com/cbor-wg/cbor-magic-number/commit/23c4176796d83e4d69ba56ab8a9b7f45cd691272

That sounds like accepting such chains; is that really desirable? It
sounds really messy to me.

> I think that you are having a problem with A.1 wrapping a CBOR thing in

I don't care about what is in a 55801, but the CDDL is confusing because
it is unspecific about which use case it is.

Either this tag is for use with 55800/55801, then it can be `senml-cbor
= #6.1668546672('BOR')` right away.

Or it is for use with 55799, then it needs to be `senml-cbor =
#6.1668546672([*record])` or whatever we use for SenML.

BR
c