Allow plugging CMW into EAT submods #118
Conversation
Fix #115 Signed-off-by: Thomas Fossati <[email protected]>
also create separate subsection for EAT submods considerations Signed-off-by: Thomas Fossati <[email protected]>
Signed-off-by: Thomas Fossati <[email protected]>
Signed-off-by: Thomas Fossati <[email protected]>
Signed-off-by: Thomas Fossati <[email protected]>
Signed-off-by: Thomas Fossati <[email protected]>
draft-ietf-rats-msg-wrap.md
Outdated
|
|
||
| To address the composite Attester use case, this document defines a CMW "collection" as a container that holds several CMW items, each with a label that is unique within the scope of the collection. |
There was a problem hiding this comment.
I don't understand why this text should be removed.
There was a problem hiding this comment.
It's not removed, it's just been expanded in L269:
"To allow aggregation of multiple, potentially non-homogeneous evidence formats collected from different AEs, this document ..."
draft-ietf-rats-msg-wrap.md
Outdated
| When a CMW is used to carry the Evidence for composite or layered attestation for a single device, the security properties needed are that of attestation. | ||
| In particular, all the members in a CMW must be bound together so that an attacker can not replace one Evidence message showing compromise with that from a non-compromised device. | ||
| The authenticity and integrity protection MUST be attestation-oriented. |
There was a problem hiding this comment.
I'm not sure what these lines are compelling me to do. Why aren't lines 292 - 294 sufficient to convey that expectation that security of the CMW isn't part of this document? The normative wording seems to contradict the previous paragraph. It seems to acknowledge an additional security consideration that an active attacker could drop portions of the collection - which is an attack that is reasonably covered in lines 292-294.
There was a problem hiding this comment.
This captures the third point from Laurence's email:
"The third thing is discussion of security when the use case is attestation Evidence, in which case the full attestation security model is necessary (which is more than integrity protection or a CWT)."
There was a problem hiding this comment.
The wording seems awkward. Is it different from: "A CMW collection is subject to a variety of security threats such as insertion / removal of CMW contents, replay, misdirection, snooping, etc."
There was a problem hiding this comment.
Since CMW doesn't define security mechanisms, it seems impossible for an implementer to satisfy the MUST requirement. I'm not sure what "attestation oriented" means. It reads like normative on some other spec besides this spec.
There was a problem hiding this comment.
Since CMW doesn't define security mechanisms, it seems impossible for an implementer to satisfy the MUST requirement.
I agree that the MUST here is unenforceable. I'll remove it and rephrase Laurence's point to keep the same "strength of signal" without bothering RFC2119.
I'm not sure what "attestation oriented" means. It reads like normative on some other spec besides this spec.
He means obeying https://www.rfc-editor.org/rfc/rfc9334.html#section-12.1
There was a problem hiding this comment.
Please see 5c5928a
Signed-off-by: Thomas Fossati <[email protected]>
No description provided.