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

From: [email-masked] (Dale R. Worley)
Date: Sat, 01 Aug 2020 13:42:41 -0400

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.

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.

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.

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.  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)?

Dale

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 1 Aug 2020 16:21:36 +0200

Hi Dale,

> On 2020-08-01, at 19:42, Dale R. Worley <[email-masked]> wrote:
> 

I hope not :-)

> of the tag in mind as it descends through structures.

Indeed.  I think we’ll have to restrict that to exactly one layer, i.e., an OID tag applied to an array or a map influences the elements/entries of that, nothing else.

(Note that this is also related to prefix compression, which is provided by packed cbor [draft-bormann-cbor-packed].)

> tags in mind as it is descending through structures.

I believe that is a complication worth arguing about.

> things are more complex because OIDs don't have a fixed-length encoding.

(Integers also don’t have a fixed length encoding when used in a tag 41 homogeneous array [RFC8746]; but there is no specific processing specified for these.)

> because that's convenient for encoding X.500 certificates.

Exactly.  Maps mapping OIDs to OIDs are not that useful, so applying the factoring to both rarely makes sense, AFAICS.  (Map) keys or values only makes more sense.  And I think keys wins,  because that is a likely case.

> distinguished names ever used when they aren't paired with keys (which

(Crypto) keys don’t have to be much longer, see https://tools.ietf.org/html/draft-mattsson-cose-cbor-cert-compress-01#appendix-A for a worked example.

Grüße, Carsten

---

From: Sean Leonard <[email-masked]>
Date: Sat, 1 Aug 2020 23:22:46 -0700

> concept because I have a fondness for OIDs and think they should be used

Yep, me too. :-)

> 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.

> 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).

> 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

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

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 2 Aug 2020 08:40:52 +0200

> The byte 0x80 *never* appears in an OID or Relative-OID ("ROID"). 

Huh?

1.2.3.16384 == h’2a 03 81 80 00’

Grüße, Carsten

---

From: Sean Leonard <[email-masked]>
Date: Sun, 2 Aug 2020 06:05:48 -0700

> 1.2.3.16384 == h’2a 03 81 80 00’

Whoops, you are right. I think I was thinking of something else, namely, 
that bit 8 cannot appear at the end of an encoded OID: it has to end 
with 0x00-0x7F.

So yeah, 0x80-0xFF at the end of a bstr is an out-of-band signal, but it 
does not appear that it can be followed by a new OID, since 0x00-0x7F 
would just mean a new arc of the current OID.

Sean

>
> Grüße, Carsten
>
> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 03 Aug 2020 03:05:58 -0400

> that bit 8 cannot appear at the end of an encoded OID: it has to end 

Well, you could delimit a sequence of concatenated OIDs by *prefixing*
each one with 0x80, so you can scan the byte string for occurrences of
0x80 immediately preceded by a byte 0x00-0x7F.  That costs 1 byte per
OID, and is probably the best you can do with a simple system.  OTOH, a
sequence of CBOR-encoded octet strings that are less than ~23 octets
only requires a one byte prefix for each as well, if the OID-ness is
implied by some mechanism.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 03 Aug 2020 03:23:12 -0400

Carsten Bormann <[email-masked]> writes:
> (Crypto) keys don't have to be much longer, see
> https://tools.ietf.org/html/draft-mattsson-cose-cbor-cert-compress-01#appendix-A
> for a worked example.

I don't know elliptic-curve crypto well enough to follow that, but it
seems to me that you're going to have a hard time putting a 2048 bit key
in less than about 256 octets, and the signature will need a similar
number of octets.  So all overheads should be counted against a minimum
of 512 octets of essentially binary data.

From: Sean Leonard <[email-masked]> writes:
> The most authoritative dotted-decimal OID style definition that I could 
> find is in the LDAP specs, namely <numericoid> in RFC 4512.

There is an OID namespace for URNs which uses dotted-decimal syntax; the
first version is RFC 3001 (Apr 2000), which refers to RFC 1778 section
2.15 (Mar 1995).

Dale

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 3 Aug 2020 07:38:42 +0200

> seems to me that you're going to have a hard time putting a 2048 bit key

That would be RSA.  Applications that care about certificate size today use ECC, with 256-bit keys (32 bytes).

> of 512 octets of essentially binary data.

Five years ago, yes.  But now it is worth to use ECC as a yard stick.

Grüße, Carsten