Original text:
3.1. <del> A certain software component product is created and packaged by a Supplier.  The package by itself does not include a proof of authenticity.  A signing authority is tasked with adding a proof of authenticity.  Trust has to be established from the Supplier towards the Signing Authority - and vice versa.  The mutual trust relationship (trust bond) between Supplier and Signing Authority is established per each individual software component package. </del>  <del> A consumer of a released software wants: </del>  <del> to understand and verify that an actual trust bond exists between the Supplier of a certain software component package and the Signing Authority of that software component package. </del>  There is no standardized way to: <del> enable the consumer to verify that a trust bond for a certain software component package exists and is still valid. </del>  3.2. <del> Authoritative entities, such as auditing or code-review companies, certification entities or government bodies, continuously produce statements about software products and identifiable software components.  Such statements can vouch for the trustworthiness of a software product or the lack thereof.  Consumers of these statements include entities, such as distributing entities, as well as end users.  There can be one or more entities that produce statements relevant to one or more of these consumer groups.  Discovery of all sources of statements and/or the identity of authoritative entities creates significant cost not all consumer groups can afford.  Some authoritative entities actively do not acknowledge other authoritative entities that highlight a lack of trustworthiness of certain released software products.  In the end, identifying all relevant statements from multiple sources typically ends up to be a responsibility of the consumer. A consumer of released software wants: * to offload the burden of identifying all relevant authoritative entities to an entity who does this on their behalf * to offload the burden to filter from and select all statements that are applicable to the released software product to an entity who does this on their behalf * to make informed decisions on which authoritative entities to believe based on the best visibility of all authoritative entities possible There is no standardized way to: * aggregate large numbers of related statements in one place and discover them there * referencing other statements via a statement * identifing or discover all (or at least a critical mass) of relevant authoritative entities </del>  3.3. <del> A released software product is accompanied by a set of complementary statements about it's security compliance and is deemed trustworthy by both producers and consumers.  After some time, new statements produced and published by third-parties show that a software component used in the software product contains a potential weakness. Over time, a statement from another third-party illustrates that the weakness is exposed in the software product in a way that it is an exploitable vulnerability.  The producer of the software product now provides a statement that confirms the linking of software component </del>  vulnerability with the software product and also issues an advisory <del> statement on how to mitigate the vulnerability ad-hoc.  Later, the </del>  producer provides an updated software product that still uses the vulnerable software component but shields the issue in a fashion that <del> inhibits exploitation.  A second update of the software product includes a patch to the affected software component created by the software product producer.  A third update includes an updated version of the formerly insecure software component.  For this release, both the software product and the affected software component are deemed secure by the producer and consumers. </del>  A consumer of a released software wants: <del> to know where to get these statements from producers and third- parties related to the software product in a timely and </del>  unambiguous fashion, how to attribute them to an authoritative issuer,

Reviewer comments:
Signed-off-by: Henk Birkholz
Looks good.
If there are no objections until the end of Fri, I'll merge for the meeting on Mon.
No objections with merging these changes.
My feedback is non blocking, PR authors may dismiss my suggestions.
LGTM!

Revised text:
3.1.  <ins> Consumers wish to verify the authenticity and integrity of software they use before installation.  To do this today, they rely on the digital signature of the software.  This can be misleading, however, as there is no guarantee that the certificate used to sign the software is authorized by the Supplier for signing.  For example, a malicious actor may obtain a signing certificate from a reputable organization and use that certificate to sign malicious software. The consumer, believing the software originated from the reputable organization, would then install malicious software. </ins>  <ins> A consumer of software wants: </ins>  <ins> to verify the authenticity and integrity of software they use before installation. </ins> There is no standardized way to:  <ins> enable the consumer to verify that software originated from a 'duly authorized signing party' on behalf of the Supplier. </ins> 3.2.  <ins> In IT industry it is a common practice that once a software product is released, it is evaluated on various aspects.  For example, an auditing company, a code review company or a government body will examine the software product and issue authoritative reports about the product.  The end users (consumers or distribution entities) use these report to make an accurate assessment as to whether the software product is deemed fit to use. There are multiple such authoritative bodies that make such assessments.  There is no assurance that all the bodies may be aware of statements from other authoritative entities or actively acknowledge them.  Discovery of all sources of such reports and/or identity of the authoritaitve bodies adds a significant cost to the end user or consumer of the product. A consumer of released software component wants: to offload the burden of identifying all relevant authoritative entities to an entity who does it on their behalf to offload the burden to filter from and select all statements that are applicable to a particular release of a multi release software product, to an entity who does this on their behalf to make an informed decisions on which authoritative entities to believe based on the best visibility of all authoritative entities possible There is no standardized way to: aggregate large numbers of related statements in one place and discover them referencing other statements via a statement identifying or discover all (or at least a critical mass) of relevant authoritative entities </ins> 3.3.  <ins> This use case is a specialization of the use case above. A released software product is often accompanied by a set of complementary statements about it's security compliance.  This gives enough confidence to both producers and consumers that the released software has a good security standard and is suitable to use. Subsequently, multiple security researchers often run sophisticated security analysis tools on the same product.  The intention is to identify any security weaknesses or vulnerabilities in the package. Initially a particluar analysis can identify itself as a simple weakness in a software component.  Over a period of time, a statement from another third-party illustrates that the weakness is exposed in the same software component in a way that it is an exploitable vulnerability.  The producer of the software product now provides a statement that confirms the linking of software component </ins> vulnerability with the software product and also issues an advisory  <ins> statement on how to mitigate the vulnerability.  At first, the </ins> producer provides an updated software product that still uses the vulnerable software component but shields the issue in a fashion that  <ins> inhibits exploitation.  Later, A second update of the software product includes a security patch to the affected software component from the software producer.  Finally, A third update includes a new release (updated version) of the formerly insecure software component.  For this release, both the software product and the affected software component are deemed secure by the producer and consumers. </ins> A consumer of a released software wants:  <ins> to know where to get these security statements from producers and third-parties related to the software product in a timely and </ins> unambiguous fashion, how to attribute them to an authoritative issuer,