rfc9943v3.txt		rfc9943.txt
	skipping to change at line 94 ¶		skipping to change at line 94 ¶
	9.4. Key Management		9.4. Key Management
	9.4.1. Verifiable Data Structure		9.4.1. Verifiable Data Structure
	9.4.2. Key Compromise		9.4.2. Key Compromise
	9.4.3. Bootstrapping		9.4.3. Bootstrapping
	9.5. Implications of Media Type Usage		9.5. Implications of Media Type Usage
	9.6. Cryptographic Agility		9.6. Cryptographic Agility
	9.7. Threat Model		9.7. Threat Model
	10. IANA Considerations		10. IANA Considerations
	10.1. Registration of application/scitt-statement+cose		10.1. Registration of application/scitt-statement+cose
	10.2. Registration of application/scitt-receipt+cose		10.2. Registration of application/scitt-receipt+cose
	Registration
	10.3. CoAP Content-Format Registrations		10.3. CoAP Content-Format Registrations
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	11.2. Informative References		11.2. Informative References
	Contributors		Contributors
	Authors' Addresses		Authors' Addresses
	1. Introduction		1. Introduction
	This document defines an architecture, a base set of extensible		This document defines an architecture, a base set of extensible
	skipping to change at line 541 ¶		skipping to change at line 540 ¶
	Subject: an identifier, defined by the Issuer, that represents the		Subject: an identifier, defined by the Issuer, that represents the
	organization, device, user, entity, or Artifact about which		organization, device, user, entity, or Artifact about which
	Statements (and Receipts) are made and by which a logical		Statements (and Receipts) are made and by which a logical
	collection of Statements can be grouped. It is possible that		collection of Statements can be grouped. It is possible that
	there are multiple Statements about the same Artifact. In these		there are multiple Statements about the same Artifact. In these
	cases, distinct Issuers (iss) might agree to use the sub CWT		cases, distinct Issuers (iss) might agree to use the sub CWT
	Claim, defined in [RFC8392], to create a coherent sequence of		Claim, defined in [RFC8392], to create a coherent sequence of
	Signed Statements about the same Artifact, and Relying Parties can		Signed Statements about the same Artifact, and Relying Parties can
	leverage sub to ensure completeness and Non-equivocation across		leverage sub to ensure completeness and Non-equivocation across
	Statements by identifying all Transparent Statements associated to		Statements by identifying all Transparent Statements associated
	a specific Subject.		with a specific Subject.
	Transparency Service: an entity that maintains and extends the VDS		Transparency Service: an entity that maintains and extends the VDS
	and endorses its state. The identity of a TS is captured by a		and endorses its state. The identity of a TS is captured by a
	public key that must be known by Relying Parties in order to		public key that must be known by Relying Parties in order to
	validate Receipts.		validate Receipts.
	Transparent Statement: a Signed Statement that is augmented with a		Transparent Statement: a Signed Statement that is augmented with a
	Receipt created via Registration in a TS. The Receipt is stored		Receipt created via Registration in a TS. The Receipt is stored
	in the unprotected header of COSE Envelope of the Signed		in the unprotected header of COSE Envelope of the Signed
	Statement. A Transparent Statement remains a valid Signed		Statement. A Transparent Statement remains a valid Signed
	skipping to change at line 826 ¶		skipping to change at line 825 ¶
	consistent with any Receipts they have verified.		consistent with any Receipts they have verified.
	Replayability: the VDS includes sufficient information to enable		Replayability: the VDS includes sufficient information to enable
	authorized actors with access to its content to check that each		authorized actors with access to its content to check that each
	data structure representing each Signed Statement has been		data structure representing each Signed Statement has been
	correctly registered.		correctly registered.
	In addition to Receipts, some VDSs might support additional Proof		In addition to Receipts, some VDSs might support additional Proof
	Types, such as proofs of consistency or proofs of non-inclusion.		Types, such as proofs of consistency or proofs of non-inclusion.
	Specific VDSs, such those describes in [RFC9162] and [RFC9942], and		Specific VDSs, such as those described in [RFC9162] and [RFC9942],
	the review of their security requirements for SCITT are out of scope		and the review of their security requirements for SCITT are out of
	for this document.		scope for this document.
	5.1.4. Adjacent Services		5.1.4. Adjacent Services
	TSs can be deployed alongside other database or object storage		TSs can be deployed alongside other database or object storage
	technologies. For example, a TS that supports a software package		technologies. For example, a TS that supports a software package
	management system, might be referenced from the APIs exposed for		management system, might be referenced from the APIs exposed for
	package management. It can also provide the ability to request a		package management. It can also provide the ability to request a
	fresh Receipt for a given software package or a list of Signed		fresh Receipt for a given software package or a list of Signed
	Statements associated with that package.		Statements associated with that package.
	skipping to change at line 862 ¶		skipping to change at line 861 ¶
	Signed Statements. An Issuer must first decide on a suitable format		Signed Statements. An Issuer must first decide on a suitable format
	(3: payload type) to serialize the Statement payload. For a software		(3: payload type) to serialize the Statement payload. For a software
	supply chain, payloads describing the software Artifacts may include:		supply chain, payloads describing the software Artifacts may include:
	* Concise Software Identification Tags format [CoSWID]		* Concise Software Identification Tags format [CoSWID]
	* Bill of Materials format [CycloneDX]		* Bill of Materials format [CycloneDX]
	* Supply chain description metadata [in-toto]		* Supply chain description metadata [in-toto]
	* Software component description format [SPDX-CBOR]		* Software component description format [SPDX]
	* Software component description format [SPDX-CBOR]
	* Supply-chain Levels for Software Artifacts [SLSA]		* Supply-chain Levels for Software Artifacts [SLSA]
	* Software Identification Tag format [SWID]		* Software Identification Tag format [SWID]
	Issuers can produce Signed Statements about different Artifacts under		Issuers can produce Signed Statements about different Artifacts under
	the same Identity. Issuers and Relying Parties must be able to		the same Identity. Issuers and Relying Parties must be able to
	recognize the Artifact to which the Statements pertain by looking at		recognize the Artifact to which the Statements pertain by looking at
	the Signed Statement. The iss and sub Claims, within the CWT Claims		the Signed Statement. The iss and sub Claims, within the CWT Claims
	protected header, are used to identify the Artifact the Statement		protected header, are used to identify the Artifact the Statement
	skipping to change at line 905 ¶		skipping to change at line 902 ¶
	* When using X.509 certificates, support for either x5t or x5chain		* When using X.509 certificates, support for either x5t or x5chain
	in the protected header is REQUIRED to implement.		in the protected header is REQUIRED to implement.
	* Support for kid in the protected header and x5chain in the		* Support for kid in the protected header and x5chain in the
	unprotected header is OPTIONAL to implement.		unprotected header is OPTIONAL to implement.
	When x5t or x5chain is present in the protected header, the iss Claim		When x5t or x5chain is present in the protected header, the iss Claim
	value MUST be a string that meets URI requirements defined in		value MUST be a string that meets URI requirements defined in
	[RFC8392]. The iss Claim value's length MUST be between 1 and 8192		[RFC8392]. The iss Claim value's length MUST be between 1 and 8192
	characters in Length.		characters in length.
	The kid header parameter MUST be present when neither x5t nor x5chain		The kid header parameter MUST be present when neither x5t nor x5chain
	is present in the protected header. Key discovery protocols are out		is present in the protected header. Key discovery protocols are out
	of scope of this document.		of scope of this document.
	The protected header of a Signed Statement and a Receipt MUST include		The protected header of a Signed Statement and a Receipt MUST include
	the CWT Claims header parameter as specified in Section 2 of		the CWT Claims header parameter as specified in Section 2 of
	[RFC9597]. The CWT Claims value MUST include the Issuer Claim (Claim		[RFC9597]. The CWT Claims value MUST include the Issuer Claim (Claim
	label 1) and the Subject Claim (Claim label 2) [IANA.cwt].		label 1) and the Subject Claim (Claim label 2) [IANA.cwt].
	skipping to change at line 930 ¶		skipping to change at line 927 ¶
	6.1. Signed Statement Examples		6.1. Signed Statement Examples
	Figure 3 illustrates a normative CDDL definition [RFC8610] for the		Figure 3 illustrates a normative CDDL definition [RFC8610] for the
	protected header and unprotected header of Signed Statements and		protected header and unprotected header of Signed Statements and
	Receipts.		Receipts.
	The SCITT architecture specifies the minimal mandatory labels.		The SCITT architecture specifies the minimal mandatory labels.
	Implementation-specific Registration Policies may define additional		Implementation-specific Registration Policies may define additional
	mandatory labels.		mandatory labels.
	Signed_Statement = /6.18(COSE_Sign1)		Signed_Statement = #6.18(COSE_Sign1)
	Receipt = /6.18(COSE_Sign1)		Receipt = #6.18(COSE_Sign1)
	COSE_Sign1 = [		COSE_Sign1 = [
	protected : bstr .cbor Protected_Header,		protected : bstr .cbor Protected_Header,
	unprotected : Unprotected_Header,		unprotected : Unprotected_Header,
	payload : bstr / nil,		payload : bstr / nil,
	signature : bstr		signature : bstr
	]		]
	Protected_Header = {		Protected_Header = {
	&(CWT_Claims: 15) => CWT_Claims		&(CWT_Claims: 15) => CWT_Claims
	skipping to change at line 958 ¶		skipping to change at line 955 ¶
	}		}
	CWT_Claims = {		CWT_Claims = {
	&(iss: 1) => tstr		&(iss: 1) => tstr
	&(sub: 2) => tstr		&(sub: 2) => tstr
	* label => any		* label => any
	}		}
	Unprotected_Header = {		Unprotected_Header = {
	? &(x5chain: 33) => COSE_X509		? &(x5chain: 33) => COSE_X509
	? &(receipts: 394) => [+ Receipt]		? &(receipts: 394) => [+ bstr .cbor Receipt]
	* label => any		* label => any
	}		}
	label = int / tstr		label = int / tstr
	Figure 3: CDDL Definition for Signed Statements and Receipts		Figure 3: CDDL Definition for Signed Statements and Receipts
	Figure 4 illustrates an instance of a Signed Statement in Extended		Figure 4 illustrates an instance of a Signed Statement in Extended
	Diagnostic Notation (EDN), with a payload that is detached. Detached		Diagnostic Notation (EDN), with a payload that is detached. Detached
	payloads support large Statements and ensure Signed Statements can		payloads support large Statements and ensure Signed Statements can
	skipping to change at line 1044 ¶		skipping to change at line 1041 ¶
	^ | |		^ | |
	.----+-------. | |		.----+-------. | |
	| Private Key | | |		| Private Key | | |
	'----+-------' v |		'----+-------' v |
	| .----+---. |		| .----+---. |
	| | Header | |		| | Header | |
	| '----+---' |		| '----+---' |
	v v v		v v v
	.-+-----------. .------+------+--.		.-+-----------. .------+------+--.
	/ / / \		/ / / \
	/ Sign +<------+ To Be Signed Bytes |		/ Sign +<------+ To-Be-Signed-Bytes |
	/ / \ /		/ / \ /
	'-----+-------' '----------------'		'-----+-------' '----------------'
	v		v
	.----+-------.		.----+-------.
	| COSE_Sign1 |		| COSE_Sign1 |
	'------------'		'------------'
	Figure 6: Workflow for Signing Large or Sensitive Statements		Figure 6: Signing Large or Sensitive Statements
	6.3. Registration of Signed Statements		6.3. Registration of Signed Statements
	To register a Signed Statement, the TS performs the following steps:		To register a Signed Statement, the TS performs the following steps:
	1. Client Authentication		1. Client Authentication
	A Client authenticates with the TS before registering Signed		A Client authenticates with the TS before registering Signed
	Statements on behalf of one or more Issuers. Authentication and		Statements on behalf of one or more Issuers. Authentication and
	authorization are implementation specific and out of scope of the		authorization are implementation specific and out of scope of the
	skipping to change at line 1140 ¶		skipping to change at line 1137 ¶
	[RFC9942], which also provides the COSE header parameter semantics		[RFC9942], which also provides the COSE header parameter semantics
	for label 394.		for label 394.
	The Registration time is recorded as the timestamp when the TS added		The Registration time is recorded as the timestamp when the TS added
	the Signed Statement to its VDS.		the Signed Statement to its VDS.
	Figure 7 illustrates a normative CDDL definition of Transparent		Figure 7 illustrates a normative CDDL definition of Transparent
	Statements. See Figure 3 for the CDDL rule that defines COSE_Sign1		Statements. See Figure 3 for the CDDL rule that defines COSE_Sign1
	as specified in Section 4.2 of RFC 9052 [STD96].		as specified in Section 4.2 of RFC 9052 [STD96].
	Transparent_Statement = /6.18(COSE_Sign1)		Transparent_Statement = #6.18(COSE_Sign1)
	Unprotected_Header = {		Unprotected_Header = {
	&(receipts: 394) => [+ Receipt]		&(receipts: 394) => [+ bstr .cbor Receipt]
	}		}
	Figure 7: CDDL Definition for a Transparent Statement		Figure 7: CDDL Definition for a Transparent Statement
	Figure 8 illustrates a Transparent Statement with a detached payload		Figure 8 illustrates a Transparent Statement with a detached payload
	and two Receipts in its unprotected header. The type of label 394		and two Receipts in its unprotected header. The type of label 394
	receipts in the unprotected header is a CBOR array that can contain		receipts in the unprotected header is a CBOR array that can contain
	one or more Receipts (each entry encoded as a .cbor-encoded Receipt).		one or more Receipts (each entry encoded as a .cbor-encoded Receipt).
	18( / COSE_Sign1 /		18( / COSE_Sign1 /
	skipping to change at line 1174 ¶		skipping to change at line 1171 ¶
	]		]
	)		)
	Figure 8: CBOR-Extended Diagnostic Notation Example of a		Figure 8: CBOR-Extended Diagnostic Notation Example of a
	Transparent Statement		Transparent Statement
	Figure 9 illustrates one of the decoded Receipts from Figure 8. The		Figure 9 illustrates one of the decoded Receipts from Figure 8. The
	Receipt contains inclusion proofs for VDSs. The unprotected header		Receipt contains inclusion proofs for VDSs. The unprotected header
	contains VDP. See the protected header for details regarding the		contains VDP. See the protected header for details regarding the
	specific VDS used. Per the "COSE Verifiable Data Structure		specific VDS used. Per the "COSE Verifiable Data Structure
	Algorithms" registry documented in [RFC9942], the COSE Key Type		Algorithms" registry documented in [RFC9942], the Verifiable Data
	RFC9162_SHA256 is value 1. Labels identify inclusion proofs (-1) and		Structure algorithm RFC9162_SHA256 is value 1. Labels identify
	consistency proofs (-2).		inclusion proofs (-1) and consistency proofs (-2).
	18( / COSE_Sign1 /		18( / COSE_Sign1 /
	[		[
	h'a4012604...6d706c65', / Protected /		h'a4012604...6d706c65', / Protected /
	{ / Unprotected /		{ / Unprotected /
	-222: { / Proofs /		396: { / Proofs /
	-1: [ / Inclusion proofs (1) /		-1: [ / Inclusion proofs (1) /
	h'83080783...32568964', / Inclusion proof 1 /		h'83080783...32568964', / Inclusion proof 1 /
	]		]
	},		},
	},		},
	nil, / Detached payload /		nil, / Detached payload /
	h'10f6b12a...4191f9d2' / Signature /		h'10f6b12a...4191f9d2' / Signature /
	]		]
	)		)
	Figure 9: CBOR-Extended Diagnostic Notation Example of a Receipt		Figure 9: CBOR-Extended Diagnostic Notation Example of a Receipt
	Figure 10 illustrates the decoded protected header of the Transparent		Figure 10 illustrates the decoded protected header of the Transparent
	Statement in Figure 8. The VDS (-111) uses 1 from RFC9162_SHA256.		Statement in Figure 8. The VDS (395) uses 1 from RFC9162_SHA256.
	{ / Protected /		{ / Protected /
	1: -7, / Algorithm /		1: -7, / Algorithm /
	4: h'50685f55...50523255', / Key identifier /		4: h'50685f55...50523255', / Key identifier /
	-111: 1, / Verifiable Data Structure /		395: 1, / Verifiable Data Structure /
	15: { / CWT Claims /		15: { / CWT Claims /
	1: transparency.vendor.example, / Issuer /		1: transparency.vendor.example, / Issuer /
	2: vendor.product.example, / Subject /		2: vendor.product.example, / Subject /
	}		}
	}		}
	Figure 10: CBOR-Extended Diagnostic Notation Example of a		Figure 10: CBOR-Extended Diagnostic Notation Example of a
	Receipt's Protected Header		Receipt's Protected Header
	Figure 11 illustrates the decoded inclusion proof from Figure 9.		Figure 11 illustrates the decoded inclusion proof from Figure 9.
	skipping to change at line 1436 ¶		skipping to change at line 1433 ¶
	| Name | Template | Reference |		| Name | Template | Reference |
	+======================+======================+=============+		+======================+======================+=============+
	| scitt-statement+cose | application/scitt- | Section 6 |		| scitt-statement+cose | application/scitt- | Section 6 |
	| | statement+cose | of RFC 9943 |		| | statement+cose | of RFC 9943 |
	+----------------------+----------------------+-------------+		+----------------------+----------------------+-------------+
	Table 1: SCITT Signed Statement Media Type Registration		Table 1: SCITT Signed Statement Media Type Registration
	Type name: application		Type name: application
	Subtype name: statement+cose		Subtype name: scitt-statement+cose
	Required parameters: N/A		Required parameters: N/A
	Optional parameters: N/A		Optional parameters: N/A
	Encoding considerations: binary (CBOR data item)		Encoding considerations: binary (CBOR data item)
	Security considerations: Section 9.5 of RFC 9943		Security considerations: Section 9.5 of RFC 9943
	Interoperability considerations: none		Interoperability considerations: none
	skipping to change at line 1472 ¶		skipping to change at line 1469 ¶
	Person & email address to contact for further information:		Person & email address to contact for further information:
	iesg@ietf.org		iesg@ietf.org
	Intended usage: COMMON		Intended usage: COMMON
	Restrictions on usage: none		Restrictions on usage: none
	Author/Change controller: IETF		Author/Change controller: IETF
	10.2. Registration of application/scitt-receipt+cose Registration		10.2. Registration of application/scitt-receipt+cose
	+====================+================================+=============+		+====================+================================+=============+
	| Name | Template | Reference |		| Name | Template | Reference |
	+====================+================================+=============+		+====================+================================+=============+
	| scitt-receipt+cose | application/scitt- | Section 7 |		| scitt-receipt+cose | application/scitt- | Section 7 |
	| | receipt+cose | of RFC 9943 |		| | receipt+cose | of RFC 9943 |
	+--------------------+--------------------------------+-------------+		+--------------------+--------------------------------+-------------+
	Table 2: SCITT Receipt Media Type Registration		Table 2: SCITT Receipt Media Type Registration
	Type name: application		Type name: application
	Subtype name: receipt+cose		Subtype name: scitt-receipt+cose
	Required parameters: N/A		Required parameters: N/A
	Optional parameters: N/A		Optional parameters: N/A
	Encoding considerations: binary (CBOR data item)		Encoding considerations: binary (CBOR data item)
	Security considerations: Section 9.5 of RFC 9943		Security considerations: Section 9.5 of RFC 9943
	Interoperability considerations: none		Interoperability considerations: none
	skipping to change at line 1688 ¶		skipping to change at line 1685 ¶
	Current Practices", BCP 225, RFC 8725,		Current Practices", BCP 225, RFC 8725,
	DOI 10.17487/RFC8725, February 2020,		DOI 10.17487/RFC8725, February 2020,
	<https://www.rfc-editor.org/info/rfc8725>.		<https://www.rfc-editor.org/info/rfc8725>.
	[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate		[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
	Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,		Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,
	December 2021, <https://www.rfc-editor.org/info/rfc9162>.		December 2021, <https://www.rfc-editor.org/info/rfc9162>.
	[SLSA] "SLSA", <https://slsa.dev/>.		[SLSA] "SLSA", <https://slsa.dev/>.
	[SPDX-CBOR]		[SPDX] "SPDX Specification",
	"SPDX Specification",
	<https://spdx.dev/use/specifications/>.		<https://spdx.dev/use/specifications/>.
	[SWID] NIST, "SWID Specification",		[SWID] NIST, "SWID Specification",
	<https://csrc.nist.gov/Projects/Software-Identification-		<https://csrc.nist.gov/Projects/Software-Identification-
	SWID/guidelines>.		SWID/guidelines>.
	Contributors		Contributors
	Orie Steele		Orie Steele
	Tradeverifyd		Tradeverifyd
	skipping to change at line 1713 ¶		skipping to change at line 1709 ¶
	Orie contributed to improving the generalization of COSE building		Orie contributed to improving the generalization of COSE building
	blocks and document consistency.		blocks and document consistency.
	Amaury Chamayou		Amaury Chamayou
	Microsoft		Microsoft
	United Kingdom		United Kingdom
	Email: amaury.chamayou@microsoft.com		Email: amaury.chamayou@microsoft.com
	Amaury contributed elemental parts to finalize normative language on		Amaury contributed elemental parts to finalize normative language on
	registration behavior and the single-issuer design, as well as		registration behavior and the single-issuer design, as well as
	overall document consistency		overall document consistency.
	Dick Brooks		Dick Brooks
	Business Cyber Guardian		Business Cyber Guardian
	United States of America		United States of America
	Email: dick@businesscyberguardian.com		Email: dick@businesscyberguardian.com
	Dick contributed to the software supply chain use cases.		Dick contributed to the software supply chain use cases.
	Brian Knight		Brian Knight
	Microsoft		Microsoft
End of changes. 20 change blocks.
	29 lines changed or deleted		25 lines changed or added
This html diff was produced by rfcdiff 1.48.