Subject: Re: [Rats] revision -09 of RIV draft addressing AD comments

From: Roman Danyliw <[email-masked]>
Date: Thu, 9 Dec 2021 23:13:07 +0000

Hi Guy, et al!

Thanks for the detailed response and all of the changes you made in response to -09.  I'm pruning the thread down to the items I'd like to discuss more.  Please consider items cut from the original thread to be resolved.

Beyond the items below, I wanted to bring one process items up to the WG.  There are three blocks of text in this document which are on the edge of the charter scope.

==[ snip ]==
Section 2.3

   6.  Reference Values MUST be encoded as defined in the TCG RIM
       document [RIM], typically using SWID [SWID], [NIST-IR-8060] or
       CoSWID tags [I-D.ietf-sacm-coswid].

Section 2.4

   *  The authorized software supplier MUST make available Reference
      Values in the form of signed SWID or CoSWID tags.

Section 6
   *  Reference Values must be conveyed from the software authority
      (e.g., the manufacturer) in Reference Integrity Manifests, to the
      system in which verification will take place.  IETF and TCG SWID
      and CoSWID work [I-D.ietf-sacm-coswid], [RIM])) forms the basis
      for this function.

==[ snip ]==

Our charter says "[w]hile a relying party may use reference, known, or expected values or thresholds to assess the assertions/claims, the procedures for this activity are out of scope for this WG (without rechartering)."  By my interpretation, this and the text in the preceding paragraph rules out the WG standardizing reference value formats.  This may be future work and something we discussed prior to the formation of the WG.

In the spirit of being practical given the intent of this document (a cross-walk of RATS with TCG work), I'm going to be flexible in interpreting our scope.  The WG should not consider us operating under an expanded charter.  My rational for exercising this flexibility is that as an informational document (not proposed standard) we are in a blurry area of specifying the RIV use case, trying to map to the existing TCG work and also noting protocol behavior.  Also influential for me was that this material was a narrow component of the document and that all behavior was being specified by reference (which fell out of the TCG work).

> -----Original Message-----
> From: Guy Fedorkow <[email-masked]>
> Sent: Thursday, November 18, 2021 8:51 PM
> To: Roman Danyliw <[email-masked]>
> Cc: [email-masked]; Jessica Fitzgerald-McKay <[email-masked]>; Eric Voit
> (evoit) <[email-masked]>
> Subject: revision -09 of RIV draft addressing AD comments
 
> ** Section 2.1.
> The result is that the Verifier can verify the device's identity by
>    checking the Subject Field
> Per Table 8-1 of 802.1AR-2018
> (https://urldefense.com/v3/__https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=
> &arnumber=8423794__;!!NEt6yMaO-gk!UNDiQXpCxaBT3PO-
> wpDMk2p5vVGjywG4k3TZ3aNUItvJ3s8-saAyFDgP0VH1A3B3MWE$ ), isn't this
> the "subject" field (lower case)?
> [guy]   yes

[Per -09] The text now reads “The result is that the Verifier can verify the device's identity by checking the _subjectName_” (emphasis mine).  I’ll repeat the same comment though -- Table 8-1 and Section 8.6 of 802.1AR-2018 appears to call this field “subject” lower case (not subjectName) and allows for the possibility of “subjectAltName”.

Any changes made here need to be reflected in Section 2.2 since subjectName is used there too.

> ** Does this document make a distinction between BIOS and UEFI?  The terms
> "BIOS", "UEFI" and "BIOS UEFI" are used throughout the document.
> 
> -- Uses "BIOS" = Sections 2.1, 2.1.2, 2.4.1
>
> If there is a distinction being drawn, please make that clear.  Otherwise, I would
> recommend consistent terminology and perhaps some up-front level setting on
> these terms.
> [guy] I’m going with “UEFI BIOS”

[Per -09] Still “BIOS” in Figure 1.  If you can make it work with the ASCII art to say UEFI BIOS or just UEFI by all means (otherwise, this one will be fine)

Regards,
Roman