Re: [Cbor] draft-ietf-cbor-tags-oid-00.txt

[Sean Leonard <[e-mail]>]

On 8/1/2020 10:42 AM, Dale R. Worley wrote:
> Reading this (and having read an earlier version), I really like the
> concept because I have a fondness for OIDs and think they should be used
> to name everything.

Yep, me too. :-)


>
> But there is a welter of problems around being able to "factor" an OID
> tag out of an array or map.
>
> Abstractly, if one can factor, one should be able to factor the tag out
> of any number of layers of structure.  The trouble with that is that it
> makes decoding difficult, as the decoder needs to keep the application
> of the tag in mind as it descends through structures.
>
> It would seem consistent that other tags might be defined with this
> behavior, in which case a decoder might need to keep several factored
> tags in mind as it is descending through structures.

I believe in several earlier drafts (like the one from a couple of years 
ago), there was a lot more text on the issue of tag factoring in 
general--of which OIDs were just a notable example. See below.


>
> Comparing with other types, a homogeneous array of OIDs is very like a
> homogeneous array of integers, for which we already have a mechanism for
> one-dimensional arrays.  OID arrays could be handled similarly, although
> things are more complex because OIDs don't have a fixed-length encoding.

The byte 0x80 *never* appears in an OID or Relative-OID ("ROID"). 
Therefore, the byte 0x80 can be used in a byte string to delimit 
multiple OIDs. In that regard it is similar to JSON Sequences (RFC 7464).

> What isn't parallel with previous mechanisms is factoring from *maps*.
> And that's novel because the factored tag applies to the keys but not
> the values.  The reason for that is a bit arbitrary, and seems to be
> because that's convenient for encoding X.500 certificates.
>
> Factoring seems to be hard to do; trying to make it semantically
> consistent and aligned with possible future tags with similar behavor
> seems to require complex behaviors in the decoder.

The original goal of the prior text was to come up with a semantically 
consistent way to factor tags out of arrays and maps, with the specific 
intention of saying "this is an array of identifiers" (e.g., OIDs or 
UUIDs) with one byte at the front, rather than an array with N tag bytes 
for N items. I believe the last extended discussion about this was in 
draft-bormann-cbor-tags-oid-06, which was considerably longer.

Whether tags should be factored as a general semantic thing, might be 
more appropriately a topic of a different Internet-Draft.


> Though this proposal
> saves about 10% in X.500 distinguished name encoding.  Then again, are
> distinguished names ever used when they aren't paired with keys (which
> are much longer)?

It looks like draft-bormann-cbor-tags-oid-06 from a long time ago has an 
example of a distinguished name semantically transposed into CBOR, in 
Section 8.2.

I am aware of two interchange formats for distinguished names: X.680 DER 
(aka "ASN.1") and LDAP string format, RFC 4514. I once wrote a parser 
that could go between the two with ease.

Although I wrote the example of DN in CBOR in 
draft-bormann-cbor-tags-oid-06, I am not sure what other implementations 
would prefer to do. If the DN is (from that application's perspective) 
just a binary blob to lob over to the crypto stack, maybe a tag for a 
DER-encoded distinguished name would be better than a CBOR 
transliteration. In such a case, the distinguished name tag could be 
defined as <<TBD>> bstr = DER, <<TBD>> tstr = LDAP string format, and 
<<TBD>> array of maps of OIDs to values = CBOR structured format.

Sean