Re: [OPSAWG] Document Shepherd Review of draft-ietf-opsawg-sbom-access-11

[Eliot Lear <[e-mail]>]

Hi Qin,

Thanks for your review.  Please see below.

On 08.10.22 11:27, Qin Wu wrote:
>
> Hi, authors:
>
> I have read the latest version of this draft, it is well written, 
> thank for that.
>
> Here is the identified minor issues during document shepherd review of 
> draft-ietf-opsawg-sbom-access-11:
>
> 1.Abstract said:
>
> “
>
> It may optionally be discovered through manufacturer usage descriptions.
>
> ”
>
> [Qin] This sentence is not clear. Are you saying MUD extensions 
> transparency can be discovered using extensions defined in section 3.9 
> of RFC8520?
>
> Or software transparency and vulnerability information can be 
> discovered by using ACL example defined in section 5.4 of this draft? 
> I assume it is the latter. Please clarify.
>
Ok, I propose the following change:

OLD:

This memo specifies a model to provide access to this information.  It
may optionally be discovered through manufacturer usage descriptions.

NEW:

This memo extends the MUD YANG model to provide the locations of software
bills of materials and to vulnerability information.

> 2.Section 1 said:
>
> “
>
>    The mechanisms specified in this document are meant to satisfy
>
>    several use cases:
>
>    *  A network-layer management system retrieving information from an
>
>       IoT device as part of its ongoing lifecycle.  Such devices may or
>
>       may not have query interfaces available.
>
> ”
>
> [Qin] How many use cases do we specify here? I believe it is two, how 
> about be specific about the number of use cases here, s/several use 
> cases/the following two use cases
>
Ok


> 3.Section 1 said:
>
> “   In the first case, devices will have interfaces that permit direct
>
>    retrieval.  Examples of these interfaces might be an HTTP [RFC9110 
> <https://datatracker.ietf.org/doc/html/rfc9110>],
>
>    or COAP [RFC7252 <https://datatracker.ietf.org/doc/html/rfc7252>] 
> endpoint for retrieval.  There may also be private
>
>    interfaces as well.
>
>    In the second case, when a device does not have an appropriate
>
>    retrieval interface, but one is directly available from the
>
>    manufacturer, a URI to that information MUST be discovered.
>
>    In the third case, a supplier may wish to make an SBOM or
>
>    vulnerability information available under certain circumstances, and
>
>    may need to individually evaluate requests. The result of that
>
>    evaluation might be the SBOM or vulnerability itself or a restricted
>
> ”
>
> [Qin] I believe the first case, the second case, the third case are 
> corresponding to three ways to discover object instead of two key use 
> cases listed in section 1? Therefore there are confusing to be 
> introduced here.
>
> I suggest to change as follows:
>
> s/in one of three ways/ through one of three method
>
> s/In the first case/In the first method
>
> s/In the second case/In the second method
>
> s/in the third case/In the third method
>
Ok.  I changed the word "In" to "Using", but otherwise agree.


> 4.Section 1.1
>
> [Qin] s/in either/either in
>
Ok


> 5.Section 1.1 said:
>
> “The MUD semantics provide a way for manufacturers
>
> to control how often tooling should check for those changes through
>
> the cache-validity node.“
>
> [Qin] Can you provide a reference section in RFC8520 about such MUD 
> semantics.
>
I have changed this to "MUD's cache-validity node provides a way..."

For your information, this is Section 3.5 of 8520.

> 6.Section 3 N.B.
>
> [Qin] What N.B. stands for? Can you provide a reference or change in 
> other words.
>
N.B. is a commonly used Latin abbreviation for "nota bene" or "note 
well".  It falls into the class of i.e,  and e.g.



> 7.Section 5.4 said:
>
> “*5.4 
> <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-sbom-access-11#section-5.4>.  
> With ACLS*
>
> Finally, here is a complete example where the device provides SBOM
>
> and vulnerability information, as well as access-control information.
>
> {
>
> "ietf-mud:mud": {
>
> "mud-version": 1,
>
> "extensions": [
>
> "ol",
>
> "transparency"
>
> ],“
>
> [Qin] How this draft is related to draft-ietf-opsawg-ol-01? In other 
> words, how sbom access work together with Ownership and licensing 
> statements in YANG described in draft-ietf-opsawg-ol-01.
>
> If ‘ol’ extension is needed, I think a informative reference is needed 
> here.
>
This as discussed within the working group, and the point was made that 
it is good to show mud working with unrelated extensions.  I would 
prefer for this reason *not* to include an informative reference.  
Implementations need not process extensions they do not understand (to 
do so would require a major rev of MUD).

> 8.Section 6 said:
>
> “N.B., for MUD, the mandatory method of retrieval is TLS.“
>
> [Qin] New fashion of acronym,J
>
> 9.Section 6 said:
>
> “
>
> One example may be to issue a certificate to the client for
>
> this purpose after a registration process has taken place.  Another
>
> example would involve the use of OAUTH in combination with a
>
> federations of SBOM servers.“
>
> [Qin] I feel there is disconnection between the fifth sentence and the 
> sixth sentence in the paragraph 9 . Two examples are provided here, I 
> am wondering which security risk are addressed by which example?
>
>
I think you are right.  The sentence order wasn't good.  How about this:

[...] Other servers that offer the data MAY restrict access to
SBOM information using appropriate authorization semantics within
HTTP.  One way to do this would be to issue a certificate to the client for
this purpose after a registration process has taken place.  Another
approach would involve the use of OAUTH in combination with a
In particular, if a system attempts to retrieve an SBOM via
HTTP and the client is not authorized, the server MUST produce an
appropriate error, with instructions on how to register a particular
client.

> 10.Section 6 said:
>
> “
>
> Vulnerability information is generally made available to such
>
> databases as NIST's National Vulnerability Database. “
>
> [Qin] Do we need to list the Database Name developed by specific 
> entity in the security section as normative text?
>
> 11.Do we have implementation that pertains to this draft?
>
Indeed we do.  Please see https://github.com/sbomtools/apt2sbom.

Eliot