first stab at a security considerations section

[thomas-fossati]

Privacy considerations are still TODO

Partially address #11

[yogeshbdeshpande]

This section has come along nicely, thanks for this! I have left few minor comments for you to have a look!

[yogeshbdeshpande]

see few more

[yogeshbdeshpande]

LGTM! First iteration is coming along well..

[deeglaze]

I think your non-bullet point item below this list ought to be referenced as its own section of relevant system security principles to follow.

[thomas-fossati]

Is there a usable reference for this (e.g., some NIST thing)? If so, we could replace $this with a pointer to $that.

[deeglaze]

SOC type 2 audits, software component analysis against CVE databases (e.g., GUAC), SLSA for code handling

[deeglaze]

This section of text is still a list, but it's more to do with the system security bullet above. Should this be its own subsection?

Your use of "transparent" is not elaborated upon. Sometimes "transparent" means that people don't notice it's there. Sometimes "transparent" means there's a window into the inner workings instead of a wall. Sometimes "transparent" means that every important action is published on a public append-only log.

I'm guessing that you mean that the Verifier attests to itself as a background check model to RPs while implementing the passport model for other attesters, and that the attestation is meaningfully traced to sources that can be audited and re-built to reconstruct the measurements.

[thomas-fossati]

I will remove "transparent"

[deeglaze]

Suggested change

	This includes key material carried in attestation key triples and key material used to verify the authority of triples (such as public keys that identify trusted supply chain actors).
	This includes key material used to sign Attestation Results, key material carried in attestation key triples, and key material used to verify the authority of triples (such as public keys that identify trusted supply chain actors).

[thomas-fossati]

ARs are not relevant to CoRIM.

[deeglaze]

ARs are explicitly described in the document and accounted for in phase 7. I think we can make this statement.

[yogeshbdeshpande]

I agree with @deeglaze

[thomas-fossati]

ARs are explicitly described in the document and accounted for in phase 7.

That's Phase 7 of Verifier appraisal. The CoRIM processor boundaries do not include ARs assembly nor their signing.

[deeglaze]

We have a huge section about a model of Verifier behavior. You have bullet points about implementing the verifier correctly. Do we want to explicitly separate the security discussion about CoRIM production and CoRIM consumption?

[thomas-fossati]

These security considerations should be scoped to CoRIM (creation, ingestion and processing). If something is missing in that scope (and I am sure there are lots of things we could and should add), let's add them. Talking about the verifier in general is also ok as long as the intersection with CoRIM is non-zero.

[deeglaze]

Perhaps we should simply say

Suggested change

	This includes key material carried in attestation key triples and key material used to verify the authority of triples (such as public keys that identify trusted supply chain actors).
	Example key management guidelines are {{?NIST SP 800-57}} and {{Annex A.10 of ISO/IEC 27001:2022}}

[nedmsmith]

Security considerations seem to be scoped toward Verifiers. But it may also apply to the entities that supply verifier inputs as well? The CoRIM draft primarily is a definition of a wire format that describes Endorsement and RV inputs to a Verifier. Nevertheless, whether describing security considerations from the perspective of Verifiers, Endorsers, or RVPs; the standard set of key management guidelines applies to all the roles (more precisely, to all the entities that implement one or more of the roles).

[deeglaze]

Please describe what you mean by "These links" and what "deep" means.

Is "link" referring to the secure channel, or is it talking about a link in your supply chain?

I see that "possibly terminated in the appraisal session" is indicative that you mean that your channels should be terminated at a controlled point in the operator's system, that the point should be close to or ideally inside the appraisal process. Yes?

When you talk about suppliers and links, and going deep, I think more about the "intermediaries" you describe next.

[thomas-fossati]

Is "link" referring to the secure channel, or is it talking about a link in your supply chain?

The former.

I see that "possibly terminated in the appraisal session" is indicative that you mean that your channels should be terminated at a controlled point in the operator's system, that the point should be close to or ideally inside the appraisal process. Yes?

yes.

[deeglaze]

Suggested change

	Minimize the use of intermediaries: each intermediary becomes another party that needs to be trusted and needs to be factored in the relying parties' TCBs.
	Minimize the use of intermediaries: each intermediary becomes another party that needs to be trusted and needs to be factored in the relying parties' TCBs.

Intermediaries of what? What counts as an intermediary? I can use cryptographic methods to ensure integrity over untrusted channels.
Are you talking about people operating your Verifier? Implementing it? Sourcing its data?
I'm sure the answer is all of the above, but the number is going to be big. Is there something we can suggest to help tame the chaos of supply chains?

[thomas-fossati]

Intermediaries of what? What counts as an intermediary?

Actors that somehow are part of the supply chain.

I can use cryptographic methods to ensure integrity over untrusted channels.

Sure, sometimes though the threat is not someone manipulating your data, but someone preventing you from seeing some data (e.g., a newly published vulnerability report), in which case cryptography is unhelpful.

Are you talking about people operating your Verifier? Implementing it?

No.

Sourcing its data?

Maybe, depending on what "sourcing" exactly means.

I am talking about external dependencies that for one reason or another you'd have to trust.

I'm sure the answer is all of the above, but the number is going to be big. Is there something we can suggest to help tame the chaos of supply chains?

Not sure, apart from "Stay in your house and close all doors and windows!" 🤣

[deeglaze]

CoRIM represents a form of improving supply chain security. Perhaps we can say, "where possible, ensure your suppliers are following best practices (through SBOM and general security framework compliance) to make breaches of trust evident and thus more difficult"

[nedmsmith]

Security considerations seem to be scoped toward Verifiers. But it may also apply to the entities that supply verifier inputs as well? The CoRIM draft primarily is a definition of a wire format that describes Endorsement and RV inputs to a Verifier. Nevertheless, whether describing security considerations from the perspective of Verifiers, Endorsers, or RVPs; the standard set of key management guidelines applies to all the roles (more precisely, to all the entities that implement one or more of the roles).

[nedmsmith]

Suggested change

[^issue] https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/11

[nedmsmith]

LGTM