Code change:
as discussed on [SCITT] SCITT threat model. I still need to discuss with Yogesh how to integrate some of his comments.
NAME : Thank you for this. I think, we should start Threat Model as a separate document to begin with. The reason been, I expect Supply Chain Security been a complex subject the number of threats and mitigation strategies will be a long document. I would prefer a pointer to the document from the master Architecture document, then! Once the document is in final shape post Community review, at that time we can make a final call, should we merge it to Main Arch. Doc or leave it separate.
Considering the scale of the addition and the fact that stand-alone terminology or threat models are a bit frowned upon, I think we should merge this PR for now. If there is a need for a separate threat model I-D we can arrive at that conclusion in the WG and with AD and chair guidance. Keeping the number of I-Ds the same during chartering is a pro and not a con, I think.

Related discussion:
text: they MUST NOT sign any other message that may be verified as an Envelope. <ins> 10.1. We provide a generic threat model for SCITT, describing its residual security properties when some of its actors (identity providers, Issuers, TS, and Auditors) are corrupt or compromised. This model may need to be refined to account for specific supply chains and use cases. 10.1.1. SCITT primarily supports evidence of Claim integrity, both from the Issuer (authentication) and from the TS (transparency).  These guarantees are meant to hold for the long term, possibly decades. We conservatively suppose that some issuers and some TS will be corrupt. SCITT entities explicitly trust one another on the basis of their long-term identity, which maps to shorter-lived cryptographic credentials.  Hence, a Verifier would usually validate a transparent signed Claim from a given Issuer, registered at a given TS (both identified in the Verifier's local authorization policy) and would not depend on any other Issuer or TS. We cannot stop authorized supply chain actors from making false claims (either by mistake or by corruption) but we can make them accountable by ensuring their Claims are systematically registered at a trustworthy TS. Similarly, we aim to provide strong residual guarantees against a faulty/corrupt TS.  We cannot stop a TS from registering Claims that do not meet its stated Registration Policy, or to issue Receipts that are not consistent with their append-only Registry, but we can hold it accountable and guarantee that it will be blamed by any Auditor that replays their Registry against any contested Receipt.  Note that SCITT does not require trust in a single centralized TS: different actors may rely on different TS, each registering a subset of claims subject to their own policy. In both cases, SCITT provides generic, universally-verifiable cryptographic evidence to individually blame the Issuer or the TS. This enables valid actors to detect and disambiguate malicious actors who make contradictory Claims to different entities (Verifiers, Auditors, Issuers).  On the other hand, their liability and the resulting damage to their reputation are application specific, and out of scope for SCITT. Verifiers and Auditors need not be trusted by other actors.  In particular, they cannot "frame" an Issuer or a TS for claims they did not issue or register. If a TS is honest, then a transparent signed Claim with a correct Receipt of registration at a given position ensures that the signed claim passed its Registration Policy and was recorded at that position in its Registry. Conversely, a corrupt TS may 1. refuse or delay the registration of Claims; 2. register Claims that do not pass its Registration Policy (e.g.  Claims with Issuer identities and signatures that do not verify.) 3. issue verifiable Receipts for Claims that do not match its Registry; 4. refuse access to its Registry (e.g. to Auditors, possibly after storage loss) An Auditor granted (partial) access to the Registry and to a collection of disputed Receipts will be able to replay it, detect any invalid Registration (2) or incorrect receipt in this collection (3), and blame the TS for them.  This ensures any Verifier that trust at least one such Auditor that (2,3) will be blamed to the TS. Due to the operational challenge of maintaining a globally consistent append-only Registry, some TS may provide limited support for historical queries on the Claims they have registered, and accept the risk of being blamed for inconsistent Registration or Issuer equivocation. Verifier and Auditors may also witness (1,4) but may not be able to collect verifiable evidence for it. Networking and Storage are trusted only for availability. Auditing may involve access to data beyond what is persisted in the TS log.  For example, the registered TS may include only the hash of a detailed SBOM, which may limit the scope of auditing. Resistance to denial-of-service is implementation specific. Actors should independently keep their own record of the Claims they issue, endorse, verify, or audit. 10.1.2. The network is untrusted.  All contents exchanged between actors is protected using secure authenticated channels (TLS) but, as usual, this may not exclude network traffic analysis. The TS is trusted with the confidentiality of the claims presented for registration.  Some TS may publish every claim in their logs, to facilitate their dissemination and auditing.  Others may just return receipts to the client that present claims for registration, and disclose the ledger only to auditors trusted with the confidentiality of its contents. A collection of transparent Claims leaks no information about the contents of other Claims registered at the TS. Nonetheless, Issuers should carefully review the inclusion of private/confidential materials in their Claims; they may for instance remove any PII, or include instead opaque cryptographic commitments, such as hashes. The confidentiality of queries is implementation-specific, and generally not guaranteed.  For example, while offline Claim verification is private, a TS may monitor which of its Claims are being verified from lookups to ensure their freshness. 10.1.3. We rely on standard cryptographic security for signing schemes (EUF- CMA: for a given key, given the public key and any number of signed messages, the attacker cannot forge a valid signature for any other message) and for receipts schemes (log collision-resistance: for a given commitment such as a Merkle-tree root, there is a unique log such that any valid path authenticates a claim in this log.) SCITT supports cryptographic agility: the actors depend only on the subset of signing and receipt schemes they trust.  This enables the gradual transition to stronger algorithms, including e.g. post- quantum signature algorithms. 10.1.4. Trust in clients that submit Claims for registration is implementation-specific.  Hence, an attacker may attempt to register any Claim it has obtained, at any TS that accepts them, possibly multiple times and out of order.  This may be mitigated by a TS that enforces restrictive access control and registration policies. 10.1.5. The identity resolution mechanism is trusted to associate long-term identifiers with their public signature-verification keys.  (The TS and other parties may record identity-resolution evidence to facilitate its auditing.) If one of the credentials of an Issuer gets compromised, SCITT still guarantee the authenticity of all claims signed with this credential that have been registered on a TS before the compromise.  It is up to the Issuer to notify TS of credential revocation to stop Verifiers from accepting Claims signed with compromised credentials.  [See the thread of revocation for additional details.] The confidentiality of any identity lookup during Claim Registration or Claim Verification is out of scope. </ins> 11. See Body mybody.