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

From: Dave Thaler <[email-masked]>
Date: Fri, 24 Jul 2020 22:51:15 +0000

During the IETF hackathon week, I went through all of the suit manifest draft and kept notes.
My full review in context is at
https://www.microsoft.com/en-us/research/uploads/prod/2017/05/draft-ietf-suit-manifest-09.pdf
which is too long to copy into email here.

Besides lots of editorial comments, there's a few technical comments/questions, including
(but there may be more depending on whether you interpret some others as editorial or technical):

1.      Apparent contradictions about whether on systems with a single component, whether setting the component index should clear the dependency index or not.

2.      What it means to "break" is underspecified (I'm guessing continue on to the next command after try-each, as opposed to go on to the next manifest, but it's not stated in the doc).

3.      Section 6.7 seems to require using multiple processes, not just multiple threads, without justification.

4.      The trust model when multiple manifest processors exist, in two or more security domains, is underspecified, and not mentioned in the Security Considerations section.

5.      Suit-text-version-required expression syntax is underspecified.

6.      SUIT_Report and Reporting Engine text is added but does not appear to be about what goes in a SUIT manifest, so I argue that it doesn't belong in this spec (and is arguable as to whether it's in scope for SUIT at all).  It reads like SUIT_Record is yet another alternative to IPFIX, syslog, etc., and doesn't state the rationale for defining a new format. You might say that it could be used in an octetArray in IPFIX if someone defined such a field, but this document doesn't, and indeed if SUIT_Record is not something that would appear in a SUIT manifest, then I think it should not be in this document.

o   Furthermore, it says SUIT_Report can go in an attestation report.  What's the rationale for that as opposed to some more typical logging/reporting mechanism that might integrate with existing error reporting mechanisms and trouble ticketing? I don't think this was motivated in either the suit architecture or the suit IM document, and I don't recall it ever being discussed on the SUIT list or WG meeting (but maybe it was and I forgot?)   Again, I think my preferred course would be to sever it from the SUIT manifest specification.

7.      Defining a new identifier space (UUIDs) for vendors is not motivated.  So a vendor can't use an existing OUI or IANA private enterprise number that can be easily looked up? You have to instead use an opaque identifier with no way to directly look up its meaning? What is the rationale for inventing a new space rather than being able to reuse an existing one that can be looked up to get an org name, contact info, etc.? (Yes there is suit-text-vendor-domain but that's severable and optional to implement at all.) And a UUID takes up more bytes than either an OUI or a PEN, so is worse for constrained devices, so why not use an existing space that is shorter and hence more applicable to constrained devices?

8.      The time-of-day and day-of-week wait events are underspecified in terms of whether they are in local time or UTC.

9.      If I understand correctly, if a dependency manifest sets Strict Order to false, this will then carry over to the dependent manifest, potentially leading to a source of unexpected bugs.  Is my understanding correct?

10.   For conditions that are optional to implement, I couldn't tell if that means that if not implemented by a manifest processor, they are treated as passing, failing, or as parse errors.

11.   There are several commands where in certain contexts the doc says they "MUST have no effect".  But why not make them illegal to appear in such contexts?   Why spend the extra space to include them in the manifest just to have no effect?

12.   Swap directive is underspecified in terms of what should happen if the destination doesn't yet exist (i.e., fail vs move).

13.   IANA considerations section doesn't yet meet the requirements of RFC 8126.  For example, it specifies Expert Review but contains insufficient information to instruct an expert how to review, per the guidelines in that RFC.

I know the doc is long (109 pages) so forgive me if some answers are elsewhere in the doc and I just missed them,
which just means maybe a cross-reference would be sufficient. :)

Dave

---

From: Michael Richardson <[email-masked]>
Date: Sun, 26 Jul 2020 16:06:48 -0400

> which is too long to copy into email here.

I appreciate the edits, but would it be as easy for you to do this via github
review now?  Or are you doing this offline somewhere?

    > 11.   There are several commands where in certain contexts the doc says
    > they "MUST have no effect".  But why not make them illegal to appear in
    > such contexts?   Why spend the extra space to include them in the
    > manifest just to have no effect?

I prefer that we tell the receiver how/if to ignore illegal stuff, rather
than assume that we can put requirements on the sender.

    > I know the doc is long (109 pages) so forgive me if some answers are
    > elsewhere in the doc and I just missed them,

I found a bunch of what I think are internal references, like "[full-cddl]" was impossible to follow.
for example:

  } The complete CDDL description is provided in [full-cddl], examples
  } are given in [examples] and a design rational is offered in
  } [design-rationale].  Finally, [implementation-matrix] gives a

I think that there is some xml2rfc rendering issue here.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brendan Moran <[email-masked]>
Date: Mon, 27 Jul 2020 14:42:05 +0000

Hi Dave,

Thank you very much for your very detailed review! Of course, it will take me some time to work through this review. I will do my best to clarify these technical comments as I work through. In general, the issues you’ve listed look to me like the “right” answer is fairly obvious, so I will straighten them out. There are several comments that I think deserve a little more clarification.

6. SUIT_Report

SUIT_Report and Reporting Engine text is added but does not appear to be about what goes in a SUIT manifest, so I argue that it doesn’t belong in this spec (and is arguable as to whether it’s in scope for SUIT at all)

You’re right. This has not been raised on the list. If it’s more appropriate to put it in a new draft, I’m happy to do that. However, it’s a natural consequence of adding the SUIT_Reporting_Policy, which was discussed at the virtual interim. It seemed to me that if a reporting policy was specified, then an implementor would naturally want to know how to report that information. If there is a need for logging SUIT commands, along with their arguments and results, this seems very specific to SUIT in general and the SUIT manifest in specific. I struggle to see what document would be more appropriate than the SUIT manifest for the SUIT_Report.

Furthermore, it says SUIT_Report can go in an attestation report.  What’s the rationale for that as opposed to some more typical logging/reporting mechanism that might integrate with existing error reporting mechanisms and trouble ticketing?

SUIT_Reporting_Policy has two output channels: “system information,” that is the “actual” values compared against in conditions, and “command records” which are effectively logs of command execution. For an update case, these are adequately served by logging infrastructure. However, in a bootloader case, this is inadequate because the bootloader and the booted application are different security domains. This means that any system information or command records need to be protected from modification by the application. Typically, this would be done with a signature; I don’t see how this is different from attestation.

The discussion of a Reporting Engine seems necessary: it’s the thing that consumes reporting policy.

7.      Defining a new identifier space (UUIDs) for vendors is not motivated.  So a vendor can’t use an existing OUI or IANA private enterprise number that can be easily looked up? You have to instead use an opaque identifier with no way to directly look up its meaning? What is the rationale for inventing a new space rather than being able to reuse an existing one that can be looked up to get an org name, contact info, etc.? (Yes there is suit-text-vendor-domain but that’s severable and optional to implement at all.) And a UUID takes up more bytes than either an OUI or a PEN, so is worse for constrained devices, so why not use an existing space that is shorter and hence more applicable to constrained devices?
7. Vendor IDs
I’d argue that I have not defined a new identifier space. It was defined in RFC4122. That said, I think that PEN could be beneficial if we can work around some of the complexities associated with it.

OUIs may be prohibitive for small manufacturers (US $2,995). For example, I have seen small manufacturers avoid building USB devices due to the cost of obtaining a USB VID. Class IDs still require a UUID Name Space Identifier. There is no rule I can find for constructing an OUI UUID, so it cannot be used as a UUID Name Space Identifier.

Private Enterprise Numbers seem manageable by small manufacturers.
There is a UUID Name Space Identifier for OIDs, however this gets a bit confusing. You would need to construct a class ID as follows:

Vendor_UUID = uuid.uuid5(uuid.NAMESPACE_OID, EncodeOID(‘1.3.6.1.4.1.’ + PEN))
Class_UUID = uuid.uuid5(Vendor_UUID, Class_Information)

The problem here is that EncodeOID() is not specified at all in RFC4122. The closest we get is:

For example, some name spaces are the
   domain name system, URLs, ISO Object IDs (OIDs), X.500 Distinguished
   Names (DNs), and reserved words in a programming language.

So Class IDs become unpredictable because OID encoding is underspecified in RFC4122. I can see the Vendor_UUID being computed with several different versions of EncodeOID:
- Encode as dotted-integer string
- Encode as DER OID
- Encode as value of DER OID (no tag/length)
- Lots of other ASN.1 encodings possible.
- Future CBOR OID?

I do not believe we should specify the use of OUIs because 1) they cost $3000, 2) there is no UUID namespace for OUIs

I’m not against using a PEN, but we would also need to provide extremely strict encoding guidelines for constructing Vendor UUIDs, since the Vendor UUID is needed as the Name Space ID for the Class UUID. For encoding in the manifest I think we should insist on using the PEN directly rather than the full OID. But what would we do with a PEN sub-assignment?

There’s a lot more complexity here than just “use a PEN.”

Best Regards,
Brendan

On 24 Jul 2020, at 23:51, Dave Thaler <dthaler=[email-masked]<mailto:dthaler=[email-masked]>> wrote:

During the IETF hackathon week, I went through all of the suit manifest draft and kept notes.
My full review in context is at
https://www.microsoft..com/en-us/research/uploads/prod/2017/05/draft-ietf-suit-manifest-09.pdf<https://www.microsoft.com/en-us/research/uploads/prod/2017/05/draft-ietf-suit-manifest-09.pdf>
which is too long to copy into email here.

Besides lots of editorial comments, there’s a few technical comments/questions, including
(but there may be more depending on whether you interpret some others as editorial or technical):
1.      Apparent contradictions about whether on systems with a single component, whether setting the component index should clear the dependency index or not.
2.      What it means to “break” is underspecified (I’m guessing continue on to the next command after try-each, as opposed to go on to the next manifest, but it’s not stated in the doc).
3.      Section 6.7 seems to require using multiple processes, not just multiple threads, without justification.
4.      The trust model when multiple manifest processors exist, in two or more security domains, is underspecified, and not mentioned in the Security Considerations section.
5.      Suit-text-version-required expression syntax is underspecified.
6.      SUIT_Report and Reporting Engine text is added but does not appear to be about what goes in a SUIT manifest, so I argue that it doesn’t belong in this spec (and is arguable as to whether it’s in scope for SUIT at all).  It reads like SUIT_Record is yet another alternative to IPFIX, syslog, etc., and doesn’t state the rationale for defining a new format. You might say that it could be used in an octetArray in IPFIX if someone defined such a field, but this document doesn’t, and indeed if SUIT_Record is not something that would appear in a SUIT manifest, then I think it should not be in this document.
o   Furthermore, it says SUIT_Report can go in an attestation report.  What’s the rationale for that as opposed to some more typical logging/reporting mechanism that might integrate with existing error reporting mechanisms and trouble ticketing? I don’t think this was motivated in either the suit architecture or the suit IM document, and I don’t recall it ever being discussed on the SUIT list or WG meeting (but maybe it was and I forgot?)   Again, I think my preferred course would be to sever it from the SUIT manifest specification.
7.      Defining a new identifier space (UUIDs) for vendors is not motivated.  So a vendor can’t use an existing OUI or IANA private enterprise number that can be easily looked up? You have to instead use an opaque identifier with no way to directly look up its meaning? What is the rationale for inventing a new space rather than being able to reuse an existing one that can be looked up to get an org name, contact info, etc.? (Yes there is suit-text-vendor-domain but that’s severable and optional to implement at all.) And a UUID takes up more bytes than either an OUI or a PEN, so is worse for constrained devices, so why not use an existing space that is shorter and hence more applicable to constrained devices?
8.      The time-of-day and day-of-week wait events are underspecified in terms of whether they are in local time or UTC.
9.      If I understand correctly, if a dependency manifest sets Strict Order to false, this will then carry over to the dependent manifest, potentially leading to a source of unexpected bugs.  Is my understanding correct?
10.   For conditions that are optional to implement, I couldn’t tell if that means that if not implemented by a manifest processor, they are treated as passing, failing, or as parse errors.
11.   There are several commands where in certain contexts the doc says they “MUST have no effect”.  But why not make them illegal to appear in such contexts?   Why spend the extra space to include them in the manifest just to have no effect?
12.   Swap directive is underspecified in terms of what should happen if the destination doesn’t yet exist (i.e., fail vs move).
13.   IANA considerations section doesn’t yet meet the requirements of RFC 8126.  For example, it specifies Expert Review but contains insufficient information to instruct an expert how to review, per the guidelines in that RFC.

I know the doc is long (109 pages) so forgive me if some answers are elsewhere in the doc and I just missed them,
which just means maybe a cross-reference would be sufficient. ☺

Dave

_______________________________________________
Suit mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/suit

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: Henk Birkholz <[email-masked]>
Date: Mon, 27 Jul 2020 17:15:07 +0200

Hi Brendan,
hi Dave

thanks for your extensive summary, Brendan! This is very useful. Just 
two small additions.

While CBOR OID seems to be a good match, that unfortunately introduces a 
timing problem (as does packed), but maybe we can devise a way around that.

As PEN are not a rare choice in CBOR-based representations, I'd just 
want to voice support for the notion of being very careful here. We can 
of course start to create a qualified name that involves a PEN (among 
other things), but we are not the only ones that might attempt such a 
thing and therefore might require some ealignment.

Viele Grüße,

Henk

On 27.07.20 16:42, Brendan Moran wrote:
> Hi Dave,
> 
> Thank you very much for your very detailed review! Of course, it will 
> take me some time to work through this review. I will do my best to 
> clarify these technical comments as I work through. In general, the 
> issues you’ve listed look to me like the “right” answer is fairly 
> obvious, so I will straighten them out. There are several comments that 
> I think deserve a little more clarification.
> 
> 6. SUIT_Report
> 
>> SUIT_Report and Reporting Engine text is added but does not appear to 
>> be about what goes in a SUIT manifest, so I argue that it doesn’t 
>> belong in this spec (and is arguable as to whether it’s in scope for 
>> SUIT at all)
> 
> You’re right. This has not been raised on the list. If it’s more 
> appropriate to put it in a new draft, I’m happy to do that. However, 
> it’s a natural consequence of adding the SUIT_Reporting_Policy, which 
> was discussed at the virtual interim. It seemed to me that if a 
> reporting policy was specified, then an implementor would naturally want 
> to know how to report that information. If there is a need for logging 
> SUIT commands, along with their arguments and results, this seems very 
> specific to SUIT in general and the SUIT manifest in specific. I 
> struggle to see what document would be more appropriate than the SUIT 
> manifest for the SUIT_Report.
> 
>> Furthermore, it says SUIT_Report can go in an attestation report.  
>> What’s the rationale for that as opposed to some more typical 
>> logging/reporting mechanism that might integrate with existing error 
>> reporting mechanisms and trouble ticketing?
> 
> SUIT_Reporting_Policy has two output channels: “system information,” 
> that is the “actual” values compared against in conditions, and “command 
> records” which are effectively logs of command execution. For an update 
> case, these are adequately served by logging infrastructure. However, in 
> a bootloader case, this is inadequate because the bootloader and the 
> booted application are different security domains. This means that any 
> system information or command records need to be protected from 
> modification by the application. Typically, this would be done with a 
> signature; I don’t see how this is different from attestation.
> 
>> 7.Defining a new identifier space (UUIDs) for vendors is not 
>> motivated.  So a vendor can’t use an existing OUI or IANA private 
>> enterprise number that can be easily looked up? You have to instead 
>> use an opaque identifier with no way to directly look up its meaning? 
>> What is the rationale for inventing a new space rather than being able 
>> to reuse an existing one that can be looked up to get an org name, 
>> contact info, etc.? (Yes there is suit-text-vendor-domain but that’s 
>> severable and optional to implement at all.) And a UUID takes up more 
>> bytes than either an OUI or a PEN, so is worse for constrained 
>> devices, so why not use an existing space that is shorter and hence 
>> more applicable to constrained devices?
> 7. Vendor IDs
> I’d argue that I have not defined a new identifier space. It was defined 
> in RFC4122. That said, I think that PEN could be beneficial if we can 
> work around some of the complexities associated with it.
> 
> OUIs may be prohibitive for small manufacturers (US $2,995). For 
> example, I have seen small manufacturers avoid building USB devices due 
> to the cost of obtaining a USB VID. Class IDs still require a UUID Name 
> Space Identifier. There is no rule I can find for constructing an OUI 
> UUID, so it cannot be used as a UUID Name Space Identifier.
> 
> 
> There is a UUID Name Space Identifier for OIDs, however this gets a bit 
> confusing. You would need to construct a class ID as follows:
> 
> So Class IDs become unpredictable because OID encoding is underspecified 
> in RFC4122. I can see the Vendor_UUID being computed with several 
> different versions of EncodeOID:
> I do not believe we should specify the use of OUIs because 1) they cost 
> $3000, 2) there is no UUID namespace for OUIs
> 
> I’m not against using a PEN, but we would also need to provide extremely 
> strict encoding guidelines for constructing Vendor UUIDs, since the 
> Vendor UUID is needed as the Name Space ID for the Class UUID. For 
> encoding in the manifest I think we should insist on using the PEN 
> directly rather than the full OID. But what would we do with a PEN 
> sub-assignment?
> 
>> On 24 Jul 2020, at 23:51, Dave Thaler 
>> <dthaler=[email-masked] 
>> <mailto:dthaler=[email-masked]>> wrote:
>>
>> https://www.microsoft..com/en-us/research/uploads/prod/2017/05/draft-ietf-suit-manifest-09.pdf 
>> <https://www.microsoft.com/en-us/research/uploads/prod/2017/05/draft-ietf-suit-manifest-09.pdf>
>> 1.Apparent contradictions about whether on systems with a single 
>> component, whether setting the component index should clear the 
>> dependency index or not.
>> 2.What it means to “break” is underspecified (I’m guessing continue on 
>> to the next command after try-each, as opposed to go on to the next 
>> manifest, but it’s not stated in the doc).
>> 3.Section 6.7 seems to require using multiple processes, not just 
>> multiple threads, without justification.
>> 4.The trust model when multiple manifest processors exist, in two or 
>> more security domains, is underspecified, and not mentioned in the 
>> Security Considerations section.
>> 5.Suit-text-version-required expression syntax is underspecified.
>> 6.SUIT_Report and Reporting Engine text is added but does not appear 
>> to be about what goes in a SUIT manifest, so I argue that it doesn’t 
>> belong in this spec (and is arguable as to whether it’s in scope for 
>> SUIT at all).  It reads like SUIT_Record is yet another alternative to 
>> IPFIX, syslog, etc., and doesn’t state the rationale for defining a 
>> new format. You might say that it could be used in an octetArray in 
>> IPFIX if someone defined such a field, but this document doesn’t, and 
>> indeed if SUIT_Record is not something that would appear in a SUIT 
>> manifest, then I think it should not be in this document.
>> oFurthermore, it says SUIT_Report can go in an attestation report.  
>> What’s the rationale for that as opposed to some more typical 
>> logging/reporting mechanism that might integrate with existing error 
>> reporting mechanisms and trouble ticketing? I don’t think this was 
>> motivated in either the suit architecture or the suit IM document, and 
>> I don’t recall it ever being discussed on the SUIT list or WG meeting 
>> (but maybe it was and I forgot?)   Again, I think my preferred course 
>> would be to sever it from the SUIT manifest specification.
>> 7.Defining a new identifier space (UUIDs) for vendors is not 
>> motivated.  So a vendor can’t use an existing OUI or IANA private 
>> enterprise number that can be easily looked up? You have to instead 
>> use an opaque identifier with no way to directly look up its meaning? 
>> What is the rationale for inventing a new space rather than being able 
>> to reuse an existing one that can be looked up to get an org name, 
>> contact info, etc.? (Yes there is suit-text-vendor-domain but that’s 
>> severable and optional to implement at all.) And a UUID takes up more 
>> bytes than either an OUI or a PEN, so is worse for constrained 
>> devices, so why not use an existing space that is shorter and hence 
>> more applicable to constrained devices?
>> 8.The time-of-day and day-of-week wait events are underspecified in 
>> terms of whether they are in local time or UTC.
>> 9.If I understand correctly, if a dependency manifest sets Strict 
>> Order to false, this will then carry over to the dependent manifest, 
>> potentially leading to a source of unexpected bugs.  Is my 
>> understanding correct?
>> 10.For conditions that are optional to implement, I couldn’t tell if 
>> that means that if not implemented by a manifest processor, they are 
>> treated as passing, failing, or as parse errors.
>> 11.There are several commands where in certain contexts the doc says 
>> they “MUST have no effect”.  But why not make them illegal to appear 
>> in such contexts?   Why spend the extra space to include them in the 
>> 12.Swap directive is underspecified in terms of what should happen if 
>> the destination doesn’t yet exist (i.e., fail vs move).
>> 13.IANA considerations section doesn’t yet meet the requirements of 
>> RFC 8126.  For example, it specifies Expert Review but contains 
>> insufficient information to instruct an expert how to review, per the 
>> guidelines in that RFC.
>> which just means maybe a cross-reference would be sufficient.J
>> Dave
>> [email-masked] <mailto:[email-masked]>
> 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.
> 
> [email-masked]

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Mon, 27 Jul 2020 15:43:57 +0000

By CBOR OID are your referring to draft-bormann-cbor-tags-oid?

https://datatracker.ietf.org/doc/draft-bormann-cbor-tags-oid/

Dave

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Henk Birkholz
Sent: Monday, July 27, 2020 11:15 AM
To: Brendan Moran <[email-masked]>; Dave Thaler <dthaler=[email-masked]>
Cc: suit <[email-masked]>
Subject: Re: [Suit] Review of draft-ietf-suit-manifest-09

Hi Brendan,
hi Dave

thanks for your extensive summary, Brendan! This is very useful. Just two small additions.

While CBOR OID seems to be a good match, that unfortunately introduces a timing problem (as does packed), but maybe we can devise a way around that.

As PEN are not a rare choice in CBOR-based representations, I'd just want to voice support for the notion of being very careful here. We can of course start to create a qualified name that involves a PEN (among other things), but we are not the only ones that might attempt such a thing and therefore might require some ealignment.

Viele Grüße,

Henk

On 27.07.20 16:42, Brendan Moran wrote:
> obvious, so I will straighten them out. There are several comments 
> that I think deserve a little more clarification.
> 
> 6. SUIT_Report
> 
> reporting policy was specified, then an implementor would naturally 
> want to know how to report that information. If there is a need for 
> logging SUIT commands, along with their arguments and results, this 
> seems very specific to SUIT in general and the SUIT manifest in 
> specific. I struggle to see what document would be more appropriate 
> than the SUIT manifest for the SUIT_Report.
> 
> that is the “actual” values compared against in conditions, and 
> “command records” which are effectively logs of command execution. For 
> an update case, these are adequately served by logging infrastructure. 
> However, in a bootloader case, this is inadequate because the 
> bootloader and the booted application are different security domains. 
> This means that any system information or command records need to be 
> protected from modification by the application. Typically, this would 
> be done with a signature; I don’t see how this is different from attestation.
> 
>> What is the rationale for inventing a new space rather than being 
>> able to reuse an existing one that can be looked up to get an org 
>> name, contact info, etc.? (Yes there is suit-text-vendor-domain but 
>> that’s severable and optional to implement at all.) And a UUID takes 
>> up more bytes than either an OUI or a PEN, so is worse for 
>> constrained devices, so why not use an existing space that is shorter 
>> and hence more applicable to constrained devices?
> 7. Vendor IDs
> I’d argue that I have not defined a new identifier space. It was 
> defined in RFC4122. That said, I think that PEN could be beneficial if 
> we can work around some of the complexities associated with it.
> 
> example, I have seen small manufacturers avoid building USB devices 
> due to the cost of obtaining a USB VID. Class IDs still require a UUID 
> Name Space Identifier. There is no rule I can find for constructing an 
> OUI UUID, so it cannot be used as a UUID Name Space Identifier.
> 
> 
> There is a UUID Name Space Identifier for OIDs, however this gets a 
> bit confusing. You would need to construct a class ID as follows:
> 
> Vendor_UUID = uuid.uuid5(uuid.NAMESPACE_OID, EncodeOID(‘1.3.6.1.4.1.’ 
> +
> PEN))
> So Class IDs become unpredictable because OID encoding is 
> underspecified in RFC4122. I can see the Vendor_UUID being computed 
> with several different versions of EncodeOID:
> I do not believe we should specify the use of OUIs because 1) they 
> cost $3000, 2) there is no UUID namespace for OUIs
> 
> I’m not against using a PEN, but we would also need to provide 
> extremely strict encoding guidelines for constructing Vendor UUIDs, 
> since the Vendor UUID is needed as the Name Space ID for the Class 
> UUID. For encoding in the manifest I think we should insist on using 
> the PEN directly rather than the full OID. But what would we do with a 
> PEN sub-assignment?
> 
>> <https://www.microsoft.com/en-us/research/uploads/prod/2017/05/draft-
>> ietf-suit-manifest-09.pdf> which is too long to copy into email here.
>> Besides lots of editorial comments, there’s a few technical 
>> comments/questions, including (but there may be more depending on 
>> whether you interpret some others as editorial or technical):
>> 2.What it means to “break” is underspecified (I’m guessing continue 
>> on to the next command after try-each, as opposed to go on to the 
>> next manifest, but it’s not stated in the doc).
>> SUIT at all).  It reads like SUIT_Record is yet another alternative 
>> to IPFIX, syslog, etc., and doesn’t state the rationale for defining 
>> a new format. You might say that it could be used in an octetArray in 
>> motivated in either the suit architecture or the suit IM document, 
>> and I don’t recall it ever being discussed on the SUIT list or WG 
>> meeting (but maybe it was and I forgot?)   Again, I think my 
>> preferred course would be to sever it from the SUIT manifest specification.
>> What is the rationale for inventing a new space rather than being 
>> able to reuse an existing one that can be looked up to get an org 
>> name, contact info, etc.? (Yes there is suit-text-vendor-domain but 
>> that’s severable and optional to implement at all.) And a UUID takes 
>> up more bytes than either an OUI or a PEN, so is worse for 
>> constrained devices, so why not use an existing space that is shorter 
>> and hence more applicable to constrained devices?
>> elsewhere in the doc and I just missed them, which just means maybe a 
>> cross-reference would be sufficient.J Dave 
>> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
>> .ietf.org%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7Cdavid.walter
>> mire%40nist.gov%7Ce1a91bc27b184eb4affa08d8323ff57b%7C2ab5d82fd8fa4797
>> a93e054655c61dec%7C1%7C0%7C637314597580328389&amp;sdata=1HJE9Qiicoe%2
>> BTGq7kaodbBn23m6L31VL5OQLI3mHoAY%3D&amp;reserved=0
> 
> 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.
> 
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7Cdavid.waltermi
> re%40nist.gov%7Ce1a91bc27b184eb4affa08d8323ff57b%7C2ab5d82fd8fa4797a93
> e054655c61dec%7C1%7C0%7C637314597580328389&amp;sdata=1HJE9Qiicoe%2BTGq
> 7kaodbBn23m6L31VL5OQLI3mHoAY%3D&amp;reserved=0
> 

_______________________________________________
Suit mailing list
[email-masked]
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7Cdavid.waltermire%40nist.gov%7Ce1a91bc27b184eb4affa08d8323ff57b%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637314597580328389&amp;sdata=1HJE9Qiicoe%2BTGq7kaodbBn23m6L31VL5OQLI3mHoAY%3D&amp;reserved=0

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 27 Jul 2020 17:51:07 +0200

Hi Dave,

yes exactly. This I-D is now revitalized due to some re-occurring 
requirements - SUIT being one of the domains of interest.

Viele Grüße,

Henk

---

From: Brendan Moran <[email-masked]>
Date: Mon, 27 Jul 2020 15:56:19 +0000

Hi Dave,

Henk has it right. However this might obscure the more salient point:

  1.  Class IDs should be UUIDs.
  2.  UUIDs require a Name Space ID.
  3.  The Name Space ID should be unique per-vendor.
  4.  There must be a way to convert a vendor identifier to a Name Space ID in a consistent way.

OUI does not provide this.
PEN might provide this, but it would require a specification of the correct encoding to use when creating a UUID from an OID. This is missing in RFC4122, despite the inclusion of NAMESPACE_OID.

Best Regards,
Brendan

On 27 Jul 2020, at 16:51, Henk Birkholz <[email-masked]<mailto:[email-masked]>> wrote:

Hi Dave,

yes exactly. This I-D is now revitalized due to some re-occurring requirements - SUIT being one of the domains of interest.

Viele Grüße,

Henk

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Henk Birkholz
Sent: Monday, July 27, 2020 11:15 AM
To: Brendan Moran <[email-masked]>; Dave Thaler <dthaler=[email-masked]>
Cc: suit <[email-masked]>
Subject: Re: [Suit] Review of draft-ietf-suit-manifest-09
Hi Brendan,
hi Dave

6. SUIT_Report

The discussion of a Reporting Engine seems necessary: it’s the thing
that consumes reporting policy.

The problem here is that EncodeOID() is not specified at all in RFC4122.
The closest we get is:

Best Regards,
Brendan

During the IETF hackathon week, I went through all of the suit
manifest draft and kept notes.
https://www.microsoft..com/en-us/research/uploads/prod/2017/05/draft-
ietf-suit-manifest-09.pdf

---

From: Dave Thaler <[email-masked]>
Date: Mon, 27 Jul 2020 16:09:46 +0000

Thanks Brendan, initial responses below.
Looking forward to a discussion on Friday.

From: Suit <[email-masked]> On Behalf Of Brendan Moran
Sent: Monday, July 27, 2020 7:42 AM
To: Dave Thaler <dthaler=[email-masked]>
Cc: suit <[email-masked]>
Subject: Re: [Suit] Review of draft-ietf-suit-manifest-09

Hi Dave,

6. SUIT_Report

You’re right. This has not been raised on the list. If it’s more appropriate to put it in a new draft, I’m happy to do that.

That’s what I’m arguing, yes.

However, it’s a natural consequence of adding the SUIT_Reporting_Policy, which was discussed at the virtual interim. It seemed to me that if a reporting policy was specified, then an implementor would naturally want to know how to report that information.

Part of my point is there are multiple existing reporting standards (e.g., in the Behave WG we had drafts on both syslog and IPFIX).
Creating yet another one is not necessarily wrong, but does mean there’s more complexity in dealing with multiple ways, and in explaining why a new one is competing with existing standards, and which one to use in what circumstance, especially if the device is already implementing one of the others for a reason unrelated to SUIT.   That adds complexity and delay into the SUIT manifest document which I would prefer to avoid.

If there is a need for logging SUIT commands, along with their arguments and results, this seems very specific to SUIT in general and the SUIT manifest in specific. I struggle to see what document would be more appropriate than the SUIT manifest for the SUIT_Report.

A new one, so that you can use the SUIT manifest without some new reporting format, if someone is already using IPFIX or syslog or whatever else.  And so that the SUIT manifest can progress sooner without blocking on this discussion (which from my experience in Behave is never simple once you have people in the room familiar with existing mechanisms).

Well often you have existing logging/reporting standards that have signatures and are not considered as “attestation”.  In theory they are similar.  My point is about the ability to integrate with existing standards and implementations that devices and networks might be already using.

RFC 4122 defined a way to create identifiers, but using them to identify vendors, or classes, or whatever else, is a new identifier space in the sense I mean.

I don’t understand any requirement to constrict a UUID for vendors.   I agree that OUIs are harder than PENs, my point is about the ability to reuse shorter IDs out of an existing number space without having to put long UUIDs in messages just to identify the vendor.  (I like PENs better.)

Agree.

I fail to see why “EncodeOID” is relevant here.  You can just use the PEN.
(And of course the Vendor_UUID need not appear in any message if the PEN appears instead.)

I didn’t follow why OID encoding is relevant to this discussion.

I’m not against using a PEN, but we would also need to provide extremely strict encoding guidelines for constructing Vendor UUIDs, since the Vendor UUID is needed as the Name Space ID for the Class UUID.

For encoding in the manifest I think we should insist on using the PEN directly rather than the full OID. But what would we do with a PEN sub-assignment?

Can you elaborate on what you mean?   I’m suggesting we simply use the PEN numbering space itself (no “sub-assignments” or whatever)
as what goes in the CBOR, and what is used to construct the namespace ID for the class id.

Dave

Best Regards,
Brendan

---

From: Dave Thaler <[email-masked]>
Date: Mon, 27 Jul 2020 16:28:52 +0000

Example concrete proposal:

1)     Change suit-parameter-vendor-identifier to be a “uint” that MUST be a PEN.

2)     Define a well-known “PEN_NAMESPACE_UUID” uuid in the SUIT manifest spec.

3)     Change the recommended method to create a vendor UUID as the namespace for class UUID to:

Vendor_UUID = uuid.uuid5(uuid. PEN_NAMESPACE_UUID, PEN))

The Vendor_UUID is used only as part of class ID construction, it never appears in a manifest.
I believe this results in smaller manifests, and the ability to look up the vendor information, given a manifest,
even if the manifest does not include the (optional) vendor domain.   In both those respects, I believe
it would be an improvement over the current spec.

Dave

From: Dave Thaler <dthaler=[email-masked]>
Sent: Monday, July 27, 2020 9:10 AM
To: Brendan Moran <[email-masked]>; Dave Thaler <[email-masked]>
Cc: suit <[email-masked]>
Subject: RE: [Suit] Review of draft-ietf-suit-manifest-09

From: Suit <[email-masked]<mailto:[email-masked]>> On Behalf Of Brendan Moran
Sent: Monday, July 27, 2020 7:42 AM
To: Dave Thaler <dthaler=[email-masked]<mailto:dthaler=[email-masked]>>
Cc: suit <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Suit] Review of draft-ietf-suit-manifest-09

Hi Dave,

6. SUIT_Report

Agree.

Dave

Best Regards,
Brendan

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 Jul 2020 13:34:18 -0400

dthaler> 6. SUIT_Report
    dthaler> SUIT_Report and Reporting Engine text is added but does not appear to be
    dthaler> about what goes in a SUIT manifest, so I argue that it doesn’t belong in
    dthaler> this spec (and is arguable as to whether it’s in scope for SUIT at all)

    bm> You’re right. This has not been raised on the list. If it’s more
    bm> appropriate to put it in a new draft, I’m happy to do that. However, it’s a
    bm> natural consequence of adding the SUIT_Reporting_Policy, which was
    bm> discussed at the virtual interim. It seemed to me that if a reporting
    bm> policy was specified, then an implementor would naturally want to know how
    bm> to report that information. If there is a need for logging SUIT commands,
    bm> along with their arguments and results, this seems very specific to SUIT in
    bm> general and the SUIT manifest in specific. I struggle to see what document
    bm> would be more appropriate than the SUIT manifest for the SUIT_Report.

I had tweaked on Dave's question here about whether IPFIX might be an
appropriate transport.  I am intringued by this possibility.
I would like to understand more about this as a concept.
I think that I would not want an IPFIX client in a bootloader, so:

    dthaler> Furthermore, it says SUIT_Report can go in an attestation report.  What’s
    dthaler> the rationale for that as opposed to some more typical logging/reporting
    dthaler> mechanism that might integrate with existing error reporting mechanisms
    dthaler> and trouble ticketing?

    bm> SUIT_Reporting_Policy has two output channels: “system information,” that
    bm> is the “actual” values compared against in conditions, and “command
    bm> records” which are effectively logs of command execution. For an update
    bm> case, these are adequately served by logging infrastructure. However, in a
    bm> bootloader case, this is inadequate because the bootloader and the booted
    bm> application are different security domains. This means that any system
    bm> information or command records need to be protected from modification by
    bm> the application. Typically, this would be done with a signature; I don’t
    bm> see how this is different from attestation.

I don't know what "existing error reporting mechanism" a bootloader (in a
nanny cam) might have access to :-)
From Dave's probably TEEP point of view, I can see that the TAM could well
provide a very rich of facilities.
The observation that the bootloader and booted application are in different
security domains is probably more relevant than the observation I was going
to make that the bootloader might not have any network.

I think that we can reasonably separate this into another draft, that I
think, TEEP would ignore.

    bm> 7. Vendor IDs
    bm> I’d argue that I have not defined a new identifier space. It was defined in
    bm> RFC4122. That said, I think that PEN could be beneficial if we can work
    bm> around some of the complexities associated with it.
    bm>
    bm> OUIs may be prohibitive for small manufacturers (US $2,995). For example, I
    bm> have seen small manufacturers avoid building USB devices due to the cost of
    bm> obtaining a USB VID. Class IDs still require a UUID Name Space
    bm> Identifier. There is no rule I can find for constructing an OUI UUID, so it
    bm> cannot be used as a UUID Name Space Identifier.

At one point, this was just not an issue because you always had to get one
for ethernet.   But, in many lower-end semi-industrial cases, the network is
provided by a "wifi module", which really does layers 1-4 (sometimes TLS
too), so the vendors do not pay for ethernet OUI.

    bm> Private Enterprise Numbers seem manageable by small manufacturers.
    bm> There is a UUID Name Space Identifier for OIDs, however this gets a bit
    bm> confusing. You would need to construct a class ID as follows:

PENs are easy. You send an email to IANA, and a week or so later, you get
number.  I have one.

    bm> There’s a lot more complexity here than just “use a PEN.”

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 Jul 2020 13:44:15 -0400

> PEN might provide this, but it would require a specification of the
    > correct encoding to use when creating a UUID from an OID. This is
    > missing in RFC4122, despite the inclusion of NAMESPACE_OID.

I'm looking at section 8.7.5.1 to try to understand things.
It seems that rather than have VendorID be hash of DNS_PREFIX,
why not just have it be a PEN, encoded as a cbor integer?
(Not an OID, just the PEN)

You could permit a bstr or integer here, so for those that have some kind of
concern about identifying the vendor, they can go with hash of something.

---

From: Brendan Moran <[email-masked]>
Date: Thu, 30 Jul 2020 17:46:40 +0000

Yup. That’s the easy part. The hard part is: what’s the uuid Name Space Identifier of the Class ID?

Best Regards,
Brendan

> On 30 Jul 2020, at 18:44, Michael Richardson <[email-masked]> wrote:
>
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 Jul 2020 13:47:38 -0400

> Vendor_UUID = uuid.uuid5(uuid. PEN_NAMESPACE_UUID, PEN))

Your choice of variables doesn't match the document, so I was confused for a
bit.

I think you mean, that to replace:

  The RECOMMENDED method to create a class ID is: Class ID =
   UUID5(Vendor ID, Class-Specific-Information)

with:
   Vendor_UUID = uuid.uuid5(uuid.PEN_NAMESPACE_UUID, PEN))

and I'm good with that, and I should have read the entire thread before
suggesting the same thing.

---

From: Brendan Moran <[email-masked]>
Date: Thu, 30 Jul 2020 17:59:41 +0000

What I had in mind was actually:

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.

Also, we need to support sub-assignments from a PEN, since large organisations may have policies that require the use of specific sub-assignments.

How does this approach handle continuity if a vendor were to spin out a sub-entity using the PEN? Is it a situation where the next firmware update needs to replace the PEN?

Best Regards,
Brendan

On 30 Jul 2020, at 18:47, Michael Richardson <[email-masked]> wrote:

with: