Subject: [Cbor] draft-ietf-cbor-tags-oid, applicability to Private Enterprise Numbers

From: Brendan Moran <[email-masked]>
Date: Thu, 29 Oct 2020 16:56:06 +0000

It seems to me that Private Enterprise Numbers (PENs) are a particularly unique use case. It seems reasonable to predict that users of PENs will want the ability to encode these in CBOR. Given that there is a large number of registrations under the PEN prefix, it seems to me that this is a reasonable case in which to allocate a tag.

I propose that we add a new tag, 112, with the same semantics as 110 except that the OID is always relative to the IANA PEN OID (1.3.6.1.4.1)

While it would be preferable to encode a simple number, IANA’s PEN registration page says:

If you are not sure whether your organization has registered a PEN, please check the registry<http://www.iana.org/assignments/enterprise-numbers>. If your organization does have a PEN, we recommend obtaining a sub-assignment from the contact listed in the registry.

This means that we should probably maintain X.690 Clause 8.20 semantics in the body.

If this proposal is adopted, I intend to write it into SUIT manifests. While it makes no size or semantic difference in SUIT—using tag 110 is fine and unambiguous in this context—I think that a dedicated tag is a better option.

Best Regards,
Brendan
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 29 Oct 2020 12:30:33 -0700

I have some interest in PENs as an EAT claim to identify manufacturers. It has the advantage over the IEEE OUI/MAA-L/MAC registry in that it is free. I’d expect it to work like this:

- There would be a claim called “oem_pen” or such
- It would have a label/key to identify the claim in the claims map
- It would “borrow” the content from tag 112 so the CBOR bytes representing #6.112 is unnecessary
- It would typically encode as 4 bytes for a typical PEN value like 50,000, rather than 8 bytes for the full OID (content borrowed so no bytes for #6.112)

It is tempting to just define the oem_pen claim as a simple integer ignoring that it is defined as part of an OID, but this would disallow organizations from use the OID structure to identify sub organizations (that’s what you are referring to by X6.90 Clause 8.20, right?). It’s a little awkward that you have to apply OID encoding rules to the assigned integer, but that is OK.

So, this does seem useful to me.

LL

> On Oct 29, 2020, at 9:56 AM, Brendan Moran <[email-masked]> wrote:
> 
>> If you are not sure whether your organization has registered a PEN, please check the registry <http://www.iana.org/assignments/enterprise-numbers>. If your organization does have a PEN, we recommend obtaining a sub-assignment from the contact listed in the registry.
> 
> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor

---

From: Michael Richardson <[email-masked]>
Date: Thu, 29 Oct 2020 18:34:59 -0400

Brendan Moran <[email-masked]> wrote:
    > It seems to me that Private Enterprise Numbers (PENs) are a
    > particularly unique use case. It seems reasonable to predict that users
    > of PENs will want the ability to encode these in CBOR. Given that there
    > is a large number of registrations under the PEN prefix, it seems to me
    > that this is a reasonable case in which to allocate a tag.

    > I propose that we add a new tag, 112, with the same semantics as 110
    > except that the OID is always relative to the IANA PEN OID
    > (1.3.6.1.4.1)

I agree.

    > If this proposal is adopted, I intend to write it into SUIT
    > manifests. While it makes no size or semantic difference in SUIT—using
    > tag 110 is fine and unambiguous in this context—I think that a
    > dedicated tag is a better option.

good.

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

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 30 Oct 2020 07:56:32 +0100

> I agree.

Now https://github.com/cbor-wg/cbor-oid/issues/7

Grüße, Carsten