Re: [Cbor] OID representation (was: Re: Robert Wilton's Discuss on draft-ietf-cbor-tags-oid-06: (with DISCUSS and COMMENT))

[Francesca Palombini <[e-mail]>]

Hi all,

Any opinions on this? Chairs, it might be good to add this to the agenda tomorrow.

Thanks,
Francesca

On 08/04/2021, 21:45, "CBOR on behalf of Carsten Bormann" <[e-mail] on behalf of [e-mail]> wrote:

    CBOR WG,

    in the IESG processing of draft-ietf-cbor-tags-oid, Rob Wilton raises some questions that I think the WG needs to consider before we reply.

    I’ll include some excerpts from Rob’s message and try to translate this into questions to the WG.

    ## Question that needs to be decided by WG

    > I would like to please see some more clarity or guidance about when TAG TBD112
    > should be used, given that there are two possible encodings of absolute OIDs
    > below "1.3.6.1.4.1".
    > 
    > Specifically, the questions that I have, that probably need to be clarified are:
    > - is a CBOR encoder allowed to optimize a TBD110 tag into a TBD112 tag?
    > - Should CBOR decoder clients always expect to be able to handle both TBD110
    > and TBD112 tags? - Or, it the decision over whether to use TBD110 or TBD112
    > down to the application and the application needs to agree which is use.

    This is indeed a good question (about TBD111 vs. TBD112, actually).
    This can be seen as related to issues about preferred representations, or about minimizing interoperability problems by nailing down exactly one allowed representation.

    So what we could propose as a WG is:

    (1) Not establishing any stronger connection between TBD111 and TBD112, i.e. status quo.
    (2) Declaring TBD112 as the preferred encoding of an absolute OID that starts with 1.3.6.1.4.1 (0x2b06010401), but still allowing the use of TBD111 as non-preferred.   This would mean a requirement on decoders implementing TBD111 to also implement TBD112.
    (3) Outlawing any TBD111 starting with (0x2b06010401) and requiring the use of TBD112 in all such cases.  This would mean a requirement on both encoders and decoders.  It would also mean a slight complication in tag factoring: replace all naked byte strings that start with h’2b06010401’ by TBD112(rest) (saving three bytes), unless *all* such byte strings start with h’2b06010401’, in which case these prefixes would all be removed and an outer tag of TBD112 used.

    (2a) would be (2) with a deterministic encoding requirement to use the shortest form (i.e., (3) in deterministic encoding only).

    ## Other responses, to be vetted by the WG

    > I found this document to be interesting because I knew from the title that it
    > was going to only be 4 pages long and say that OIDs are obviously encoded as a
    > tagged array, hence I was surprised to see that was not the solution and it
    > uses BER encoded OIDs instead.
    > 
    > The document explains, and I think that I understand why this has been done,
    > but I question whether the title of the document and name of the tags is right.
    > Is it really a CBOR representation of OIDs, or is it actually a CBOR
    > representation of BER encoded OIDs?  

    The first, using the technical approach named in the second.

    > I.e., it is plausible that there would
    > ever be a requirement for non BER encoded OIDs.  E.g., I'm not an ASN.1 expert,
    > but say if somewhat wanted to do a CBOR encoding of ASN.1, then it is not
    > obvious to me that they would use a BER encoding for OIDs.  

    One example for a CBOR encoding of something that previously has been encoded in ASN.1 is draft-mattsson-cose-cbor-cert-compress, which normatively references the tags-oid spec.  The certificate spec actually goes ahead and registers translation tables between likely OIDs and small integers.  But if the full range of OIDs is needed, the byte string derived from the BER content indeed is the representation chosen.  (As the C509 certificates are schema-driven, they do not need the actual tags defined here.)

    > Hence the
    > suggestion is to make the title, abstract, and name of the tags clear that it
    > is about the CBOR encoding or BER encoded OIDs.

    The specification proposes to use BER in a number of tags for binary encoding of OIDs.
    The BERness is not a feature that the OIDs already need to have before these tags apply.
    So a title "CBOR encoding of BER encoded OIDs” (which is what I think Rob wanted to say) would be a restriction beyond what this spec is about.

    ## Answers that probably don’t need WG input

    > In the introduction:
    >   Since the semantics of absolute and relative object identifiers
    >   differ, this specification defines two tags, collectively called the
    >   "OID tags" here:
    > 
    > I presume that this should be three tags?

    (Fixed by Ben’s PR, https://protect2.fireeye.com/v1/url?k=ba6fc850-e5f4f150-ba6f88cb-86fc6812c361-13a7df472860fde1&q=1&e=0e7a159f-e848-4868-ba83-77bd15bd7109&u=https%3A%2F%2Fgithub.com%2Fcbor-wg%2Fcbor-oid%2Fpull%2F9 .)

    > In section 4.1.  Tag Factoring Example: X.500 Distinguished Name:
    > 
    > The diagram uses a mix of single letters (e.g. c for country), and a full name
    > "street".  Is this how the X.500 attributes are defined?  

    This uses the naming defined e.g. in RFC 4519, section 2.2 and section 2.34, which has been derived from X.520 and is quite ubiquitous, going back to Table 1 of RFC 1779.

    >    The country and street RDNs are single-valued. The second and fourth RDNs
    >    are multi-valued.
    > 
    > Perhaps:  "The country (first) and street (third) RDNs are single-valued. The
    > second and fourth RDNs are multi-valued."

    Now in https://protect2.fireeye.com/v1/url?k=068b030f-59103a0f-068b4394-86fc6812c361-0b9af94b8776f5cf&q=1&e=0e7a159f-e848-4868-ba83-77bd15bd7109&u=https%3A%2F%2Fgithub.com%2Fcbor-wg%2Fcbor-oid%2Fcommit%2F3d0fd8b .

    >    h'550407': "Los Angeles", h'550408': "CA",
    > 
    > I think that the example would be more clear by splitting the city and county
    > onto separate lines.

    Now in https://protect2.fireeye.com/v1/url?k=1256d235-4dcdeb35-125692ae-86fc6812c361-c69fb84326c526c2&q=1&e=0e7a159f-e848-4868-ba83-77bd15bd7109&u=https%3A%2F%2Fgithub.com%2Fcbor-wg%2Fcbor-oid%2Fcommit%2F3d0fd8b .

    > Finally, the document contains these two sentences that seem to somewhat
    > conflict with each other:
    > 
    > "While these sequences can easily be represented in CBOR arrays of unsigned
    > integers, a more compact representation can often be achieved by adopting the
    > widely used representation of object identifiers defined in BER; this
    > representation may also be more amenable to processing by other software that
    > makes use of object identifiers."
    > 
    > compared to:
    > 
    > "Staying close to the way object identifiers are encoded in ASN.1 BER makes
    > back-and-forth translation easy; otherwise we would choose a more efficient
    > encoding."


    While the BER form is reasonably efficient, a more efficient representation of sequences of unsigned integers that roughly follow Zipf’s law in distribution has been described in  <https://mailarchive.ietf.org/arch/msg/cbor/9owRyOcXdsK7Ooc1S3D9-AImDdU>, which would for instance represent 1.3.6.1.4.1 as 0x136141 and does not need a special case to make absolute OIDs efficient.

    The WG instead decided to follow the existing BER representation because it is so widely implemented and is compatible with SDNVs, which are used in additional applications and often have good platform support (e.g., Ruby pack/unpack(“w*”)).
    For OID-style applications, BER content is often still more compact than a CBOR array of unsigned integers.

    Tagged (homogeneous) arrays of arcs don’t help as the OID arcs vary widely in their range; e.g., the common OID 1.2.840.113549.1.1.1 (*, 2+9 bytes in BER) would need to be an array of seven 32-bit integers (2tag+2head+28 bytes) instead of a basic CBOR array of unsigned integers of 14 bytes.

    In general, I don’t think we need to discuss an extensive set of alternative approaches (paths not taken) in this specification.

    Grüße, Carsten

    (*) {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) rsaEncryption(1)}

    _______________________________________________
    CBOR mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/cbor