post IETF 114 BoF charter proposal #18
Conversation
Signed-off-by: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
merging to bash after discuss
ietf-scitt-charter.md
Outdated
| @@ -4,6 +4,8 @@ Over the years, rapid technological advancements have motivated organizations to | |||
| While these improvements help organizations increase efficiency and swiftly bring innovations to market, the rapid increase in scale, size, and complexity of supply chains has led to more frequent and sophisticated supply chain attacks. | |||
| The traditional methods of safeguarding supply chains (e.g., pre- and post-audit methodologies) are no longer adequate. | |||
|
|
|||
| Scitt forms a building block that will allow implemeters to compose complex supply chain integrity systems. For example, public computer interface system could report its software composition and that can be compared against known software compositions for such a device, recorded in a public ledger, thus providing an individual using the system with confidence that it will behave as expected, when expected, and nothing/nowhen else. | |||
|
|
|||
| Problem Statement | |||
| ================= | |||
| It is challenging to manage the compliance of products across end-to-end, global supply chains. | |||
There was a problem hiding this comment.
Please update the problem statement to match the BOF Problem statement
There was a problem hiding this comment.
Will do in another PR
There was a problem hiding this comment.
Minor suggestion, please consider replacing "and nothing/nowhen else." WITH
"consistently, without deviation."
There was a problem hiding this comment.
Saving 1st comment in issue & adding 2nd comment via commit.
Signed-off-by: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Co-authored-by: Yogesh Deshpande <yogesh.deshpande@arm.com>
Co-authored-by: Yogesh Deshpande <yogesh.deshpande@arm.com>
…o post-BoF-1st-pass
Signed-off-by: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Signed-off-by: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Signed-off-by: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Signed-off-by: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
…o post-BoF-1st-pass Signed-off-by: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Signed-off-by: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
ietf-scitt-charter.md
Outdated
| 2. There are no APIs defined for automated publishing, retrieval, or independent verification of the information above. | ||
| 3. The absence of decentralized, globally interoperable, transparent services to publish the supply chain data. | ||
| 4. The lack of sufficient standards for independently verifying the presence of supply chain data in tamper-proof data stores. | ||
| 5. Software consumers have no trustworthy way to verify that a software signature on a software package is legitimate. |
There was a problem hiding this comment.
Since there are many folks out there who will tell you, my PGP verification system works just fine and is plenty trustworthy, perhaps we could focus instead on closing the gap from a methodology perspective of how the attestations generated are consumed in a uniform way across environments to allow for easy adoption by any existing ecosystem whose current status may fall under bullet 5
| 5. Software consumers have no trustworthy way to verify that a software signature on a software package is legitimate. | |
| 5. Fractured verification methodologies across software distribution ecosystems create inconsistent security guarantees for end users. |
There was a problem hiding this comment.
(5) sounds related to @rjb4standards's comment made here: https://www.youtube.com/watch?v=6B8Bv0naAIA&t=1584s
There was a problem hiding this comment.
It seems we could preserve the existing 5 and add the proposed new 5 as 6 as they both provide justification for the purpose
+6. Fractured verification methodologies across software distribution ecosystems create inconsistent security guarantees for end users.
There was a problem hiding this comment.
As the "old" (5.) is a verbatim quote from Dick at the BoF and he is okay with the change, I am okay with the change. Was about to merge, but will give folks 12h to object.
There was a problem hiding this comment.
Henk, my suggestion is to keep the old 5 and add John's recommendation as 6. His recommendation is far broader and a bit more abstract - it's good stuff, but my comment was from an actual, pointed encounter in the wild where SCITT can help.
There was a problem hiding this comment.
No they are not independent statements, but can be clubbed using OR
There was a problem hiding this comment.
So it should be joined using OR, either lacking verifying methods or fragmented verifying methods
There was a problem hiding this comment.
@yogeshbdeshpande they are certainly all within the same context of verification, but the new 6 is more abstract. Using an ice cream analogy, 6 is like saying "ice cream is made from dairy products and other ingredients", which is also true for a more direct, less abstract statement, like the current 5, i.e. Chocolate ice cream is made from whole milk, sugar and chocolate flavoring, which the supplier of the chocolate flavoring cannot be determined or verified.
There was a problem hiding this comment.
ok, in that case, we should really swap (5) and (6).
Reason been current (6) talks about SW distribution systems while current (5) talks about end user!
There was a problem hiding this comment.
No objections to swapping 5 and 6, so that John's proposal becomes 5 and the original 5 becomes 6.
Signed-off-by: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Co-authored-by: Henk Birkholz <henkbirkholz@users.noreply.github.com>
No description provided.