Re: [Suit] Review of draft-ietf-suit-manifest-09

[Brendan Moran <[e-mail]>]

I raised two orthogonal issues regarding PEN. I don’t think that either of them are blockers. I just want to make sure we get them right.

1) We need a way to declare sub-assignments of PENs.
2) We need a way to construct class IDs.


One fairly easy way to deal with all of this at once is to use OIDs. Then, there is no difference between vendor and class: They are arbitrary subdivisions of OID space. We can also state that the IANA PEN arc of 1.3.6.1.4.1 is always present, and omit it.

In this case, my vendor ID might be 13457.3 and my class ID might be 1.7.99. Together, these could form a single OID: 1.3.6.1.4.1.13457.3.1.7.99.

Only the PEN and sub assignments would be actually encoded: 13457.1.1.7.3. These would divided into vendor and class.

I don’t think we can reasonably make arguments about size if we leave the 16 bytes of Class ID on the table. With that in mind, I think we should probably look at Vendor ID and Class ID as relative OIDs. They can be serialised as X.690-encoded OIDs, wrapped in a bstr.

I still worry that this leaves implementors lattitude to abuse Vendor ID and Class ID, ignoring real incompatibilities for the sake of consistent naming, but the size is probably more important overall.



Because both OIDs and UUIDs are serialised as bstr, this would meant that, in order to use a UUID, it would need to be wrapped in a Tag 37, since there is not yet an OID CBOR tag. Alternatively, because a recipient really doesn’t care—it just matches a bstr expressed in the manifest to a bstr asserted by the Manifest Processor—we can leave both un-tagged. Intermediaries may care if they’re trying to present the information to a user, though that is expressly not the purpose of either the vendor ID or the class ID.

This is actually a really nice result. It means that there is no change to the CDDL. There’s a (comparatively small) change to the text to explain that either a relative OID or a UUID can be used to express a vendor ID or a class ID.



I’m fine with defining a PEN Name Space Identifier for UUIDs, provided that the input is defined to be a X.690-encoded relative OID. This means that it can handle sub assignments easily, and it matches the Vendor ID proposal above. This is only necessary in the mixed case: Vendor ID is PEN, Class ID is UUID.


A couple more comments below.


> On 3 Aug 2020, at 01:14, Michael Richardson <[e-mail]> wrote:
> Brendan Moran <[e-mail]> wrote:
>> ClassID = uuid5(uuid5(OID_NAMESPACE_UUID, encode_oid([1,3,6,1,4,1,PEN]), Class-Specific-Information)
>> But then we need to define encode_oid because RFC4122 doesn’t specify which OID encoding to use.
>
> Yeah, I see no advantage to including the OID here.

I don’t have a problem with declaring a new Name Space Identifier for PENs, provided that it can handle sub-assignments.

>> Also, we need to support sub-assignments from a PEN, since large
>> organisations may have policies that require the use of specific
>> sub-assignments.
>
> Since this is just to produce a ClassID, it seems that there could be an
> integer that could be incremented to form sub-assignments.

I think that ClassID and sub-assignments are orthogonal here. Organisations should not be restricted in their ability to specify sub-organisations for the purpose of compatibility checking.

> Second, I believe that for larger organizations, IANA will assign multiple
> PENs to e.g. "ExampleCOM Consumer Devices" vs "ExampleCOM Transportation Systems”

That is good to know, however I don’t understand the reluctance to support sub-assignment.

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.