From a2c8dc1bd5064ffb9d87594cc2bc3445c5a3edcb Mon Sep 17 00:00:00 2001 From: Amaury Chamayou Date: Tue, 4 Feb 2025 13:42:45 +0000 Subject: [PATCH] Remove URNs --- draft-ietf-scitt-architecture.md | 190 ------------------------------- 1 file changed, 190 deletions(-) diff --git a/draft-ietf-scitt-architecture.md b/draft-ietf-scitt-architecture.md index c9612ce..9777d77 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -120,7 +120,6 @@ informative: RFC7523: RFC8725: RFC2397: DataURLs - RFC8141: URNs RFC9162: CT RFC9334: rats-arch CWT_CLAIMS: @@ -1074,195 +1073,6 @@ Occasionally, RATS Evidence and RATS Attestation Results or the procedures of cr The stand-alone use of "attestation" and "to attest" is discouraged outside a well-defined context, such as specification text that highlights the application of terminology, explicitly. Correspondingly, it is often useful for the intended audience to qualify the term "attestation" to avoid confusion and ambiguity. -# Identifiers - -This section provides informative examples of identifiers for Statements, Signed Statements, and Receipts. - -SCITT Identifiers are primarily meant to be understood by humans and secondarily meant to be understood by machines, as such we define text encodings for message identifiers first, and then provide binary translations according to standard transformations for URLs and URNs to binary formats. - -SCITT Identifiers for URLs and URNs that are not Data URLs MUST be represented in binary using {{-CURIs}}. - -For each SCITT conceptual message, we define a Data URL format according to {{-DataURLs}}, a URN format according to {{-URNs}} and a URL format according to {{URLs}}. - -Note that Data URLs require base64 encoding, but the URN definitions require base64url encoding. - -Resolution and dereferencing of these identifiers is out of scope for this document, and can be implemented by any concrete api implementing the abstract interface defined as follows: - -~~~ -resource: content-type = dereference(identifier: identifier-type) -~~~ - -These identifiers MAY be present in a `tstr` field that does not otherwise restrict the string in ways that prevent a URN or URL from being present. - -This includes `iss`, and `sub` which are used to express the Issuer and Subject of a Signed Statement or Receipt. - -This also includes `kid` which is used to express a hint for which public key should be used to verify a signature. - -All SCITT identifiers share common parameters to promote interoperability: - -Let hash-name be an algorithm name registered in {{IANA.named-information}}. - -To promote interoperability, the hash-name MUST be "sha-256". - -Let base-encoding, be a base encoding defined in {{-Base64Url}}. - -To promote interoperability, the base encoding MUST be "base64url". - -In the blocks and examples that follow, note '\' line wrapping per RFC 8792. - -## Identifiers For Binary Content - -Identifiers for binary content, such as Statements, or even Artifacts themselves are computed as follows: - -Let the `base64url-encoded-bytes-digest` for the message be the base64url encoded digest with the chosen hash algorithm of bytes / octets. - -Let the SCITT name for the message be the URN constructed from the following URI template, according to {{-URITemplate}}: - -Let the `message-type`, be "statement" for Statements about Artifacts. - -~~~ -urn:ietf:params:scitt:\ -{message-type}:\ -{hash-name}:{base-encoding}:\ -{base64url-encoded-bytes-digest} -~~~ - -## Identifiers For SCITT Messages - -Identifiers for COSE Sign 1 based messages, such as identifiers for Signed Statements and Receipts are computed as follows: - -Let the `base64url-encoded-to-be-signed-bytes-digest` for the message be the base64url encoded digest with the chosen hash algorithm of the "to-be-signed bytes", according to {{Section 8.1 of RFC9052}}. - -Let the SCITT name for the message be the URN constructed from the following URI template, according to {{-URITemplate}}: - -Let the `message-type`, be "signed-statement" for Signed Statements, and "receipt" for Receipts. - -~~~ -urn:ietf:params:scitt:\ -{message-type}:\ -{hash-name}:{base-encoding}:\ -{base64url-encoded-to-be-signed-bytes-digest} -~~~ - -Note that this means the content of the signature is not included in the identifier, even though signature related Claims, such as activation or expiration information in protected headers are included. - -As a result, an attacker may construct a new Signed Statement that has the same identifier as a previous Signed Statement, but has a different signature. - -## Identifiers For Transparent Statements - -Identifiers for Transparent Statements are defined as identifiers for binary content, but with "transparent-statement" as the `message-type`. - -~~~ -urn:ietf:params:scitt:\ -{message-type}:\ -{hash-name}:{base-encoding}:\ -{base64url-encoded-bytes-digest} -~~~ - -Note that because this identifier is computed over the unprotected header of the Signed Statement, any changes to the unprotected header, such as changing the order of the unprotected header map key value pairs, adding additional Receipts, or adding additional proofs to a Receipt, will change the identifier of a Transparent Statement. - -Note that because this identifier is computed over the signatures of the Signed Statement and signatures in each Receipt, any canonicalization of the signatures after the fact will produce a distinct identifier. - -## Statements - -### Statement URN - -~~~ -urn:ietf:params:scitt:statement:sha-256:base64url:5i6UeR...qnGmr1o -~~~ -{: #example-statement-urn align="left" title="Example Statement URN"} - -### Statement URL - -~~~ -https://transparency.example/api/identifiers\ -/urn:ietf:params:scitt:statement:sha-256:base64url:5i6UeR...qnGmr1o -~~~ -{: #example-statement-url align="left" title="Example Statement URL"} - -### Statement Data URL - -~~~ -data:application/json;base64,SGVsb...xkIQ== -~~~ -{: #example-statement-data-url align="left" title="Example Statement Data URL"} - -## Signed Statements - -### Signed Statement URN - -~~~ -urn:ietf:params:scitt:\ -signed-statement:sha-256:base64url:5i6UeR...qnGmr1o -~~~ -{: #example-signed-statement-urn align="left" title="Example Signed Statement URN"} - -### Signed Statement URL - -~~~ -https://transparency.example/api/identifiers\ -/urn:ietf:params:scitt:\ -signed-statement:sha-256:base64url:5i6...r1o -~~~ -{: #example-signed-statement-url align="left" title="Example Signed Statement URL"} - -### Signed Statement Data URL - -~~~ -data:application/cose;base64,SGVsb...xkIQ== -~~~ -{: #example-signed-statement-data-url align="left" title="Example Signed Statement Data URL"} - -## Receipts - -### Receipt URN - -~~~ -urn:ietf:params:scitt:receipt:sha-256:base64url:5i6UeR...qnGmr1o -~~~ -{: #example-receipt-urn align="left" title="Example Receipt URN"} - -### Receipt URL - -~~~ -https://transparency.example/api/identifiers\ -/urn:ietf:params:scitt:receipt:sha-256:base64url:5i6UeR...qnGmr1o -~~~ -{: #example-receipt-url align="left" title="Example Receipt URL"} - -### Receipt Data URL - -~~~ -data:application/cose;base64,SGVsb...xkIQ== -~~~ -{: #example-receipt-data-url align="left" title="Example Receipt Data URL"} - -## Transparent Statements - -### Transparent Statement URN - -~~~ -urn:ietf:params:scitt:\ -transparent-statement:sha-256:base64url:5i6UeR...qnGmr1o -~~~ -{: #example-transparent-statement-urn align="left" title="Example Transparent Statement URN"} - -### Transparent Statement URL - -~~~ -https://transparency.example/api/identifiers\ -/urn:ietf:params:scitt:\ -transparent-statement:sha-256:base64url:5i6UeR...qnGmr1o -~~~ -{: #example-transparent-statement-url align="left" title="Example Transparent Statement URL"} - -### Transparent Statement Data URL - -~~~ -data:application/cose;base64,SGVsb...xkIQ== -~~~ -{: #example-transparent-statement-data-url align="left" title="Example Transparent Statement Data URL"} - # Signing Statements Remotely Statements about digital Artifacts, containing digital Artifacts, or structured data regarding any type of Artifacts, can be too large or too sensitive to be send to a remote Transparency Services over the Internet.