Back to "transparency and trust" from "security" #23
Conversation
There was a discussion with me, @OR13 and @kaywilliams on the other PR that wasn't addressed, and I think is very important. I'm concerned that we're swerving a little into the 'preventative security' world where actually the work here is transparency and accountability. In the example given we don't have total confidence that the computer will always behave perfectly: even with the 'right' software payload there may be bugs or operator-borne attacks, for example. But what we do have is confidence that you're dealing with the computer system you thought you would be, and that nothing has been injected or modified on its way to you. I also removed "an individual" because humans aren't realistically going to be doing much of this transactional verification: we want all of this stuff to be strong enough that we can automate all the mundane validation work away.
| @@ -4,9 +4,7 @@ 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. | |||
|
|
|||
| The output of the SCITT WG is a set of standards that define the essential building blocks enabling the security of supply chain systems and assisting implementers in securing deployments. | |||
There was a problem hiding this comment.
I like this sentence:
The output of the SCITT WG is a set of standards that define the essential building blocks enabling the security of supply chain systems
|
Original comment thread here: #20 (comment) |
ietf-scitt-charter.md
Outdated
| The output of the SCITT WG is a set of standards that define the essential building blocks enabling the security of supply chain systems and assisting implementers in securing deployments. | ||
| For example, a public computer interface system could report its software composition, which can be compared against known software compositions for such a device, as recorded in an append-only transparent registry. | ||
| Therefore, providing an individual using the system with confidence that it will behave as and when expected, consistently and without deviation. | ||
| SCITT forms a set of interoperable building blocks that will allow implementers to build integrity and accountability into supply chain systems to help assure trustworthy operation. For example, a public computer interface system could report its software composition that can then be compared against known software compositions (and certifications?) for such a device thereby giving confidence that the system is running the software expected and has not been modified, either by attack or accident, in the supply chain. |
There was a problem hiding this comment.
To address Orie's comment, how about this:
The output of the SCITT WG is a set of interoperable building blocks that will allow implementers to build integrity and accountability into supply chain systems to help assure trustworthy operation.
Instead of this...
SCITT forms a set of interoperable building blocks that will allow implementers to build integrity and accountability into supply chain systems to help assure trustworthy operation.
Otherwise, I agree with this change.
There was a problem hiding this comment.
I'm good with that proposed language.
@henkbirkholz is this language ok for a charter?
I like the ideal of being a bit concrete about what we intend to deliver.
There was a problem hiding this comment.
Only a few editorial requests:
- the 2nd sentence now is pretty long and should be split
- "(and certifications?)" cannot stay, either remove it or incorporate it as "or certifications"
Otherwise I am okay with the suggested change, the core of the message remains unchanged.
There was a problem hiding this comment.
All addressed in update #2. @henkbirkholz are you happy to merge?
There was a problem hiding this comment.
I am happy with Kay's proposal and will incorporate!
There was a discussion with me, @OR13 and @kaywilliams on the other PR that wasn't addressed, and I think is very important.
I'm concerned that we're swerving a little into the 'preventative security' world where actually the work here is transparency and accountability. In the example given we don't have total confidence that the computer will always behave perfectly: even with the 'right' software payload there may be bugs or operator-borne attacks, for example. But what we do have is confidence that you're dealing with the computer system you thought you would be, and that nothing has been injected or modified on its way to you.
I also removed "an individual" because humans aren't realistically going to be doing much of this transactional verification: we want all of this stuff to be strong enough that we can automate all the mundane validation work away.