From 5f4535a433a7172bb469f3828a7a1f7ded3eb604 Mon Sep 17 00:00:00 2001 From: ID Bot Date: Tue, 7 Jan 2025 15:50:51 +0000 Subject: [PATCH] Script updating gh-pages from d5ad6f8. [ci skip] --- draft-ietf-scitt-scrapi.html | 240 +++++++++-------------------------- draft-ietf-scitt-scrapi.txt | 161 +++-------------------- 2 files changed, 81 insertions(+), 320 deletions(-) diff --git a/draft-ietf-scitt-scrapi.html b/draft-ietf-scitt-scrapi.html index 73d1fcd..6c575e5 100644 --- a/draft-ietf-scitt-scrapi.html +++ b/draft-ietf-scitt-scrapi.html @@ -1183,19 +1183,16 @@

2.2. Optional Endpoints

The following HTTP endpoints are optional to implement.

-
-
-

-2.2.1. Issue Signed Statement -

-

Authentication MUST be implemented for this endpoint.

-

This endpoint enables a Transparency Service to be an issuer of Signed Statements on behalf of authenticated clients. -This supports cases where a client lacks the ability to perform complex cryptographic operations, but can be authenticated and report statements and measurements.

-

Request:

-
-
-POST /signed-statements/issue HTTP/1.1
-Host: transparency.example
-Accept: application/json
-Content-Type: application/spdx+json
-Payload
-
-{
-  "spdxVersion": "SPDX-2.2",
-  "dataLicense": "CC0-1.0",
-  "SPDXID": "SPDXRef-DOCUMENT",
-  "name": "cli-app 0.1.2",
-  "documentNamespace": \
-    "https://spdx.org/spdxdocs/\
-    sbom-tool-2.2.7-38f6.../cli-app/0.1.2/0d06...",
-  "creationInfo": {
-    "created": "2024-08-16T21:44:54Z",
-    "creators": [
-      "Organization: acme"
-    ]
-  },
-  "files": [
-    {
-      "name": "cli-app",
-      "SPDXID": "SPDXRef-RootPackage",
-      "downloadLocation": "NOASSERTION",
-      "packageVerificationCode": {
-        "packageVerificationCodeValue": "ecf0aae2a849cc51..."
-      },
-      "filesAnalyzed": true,
-      "licenseConcluded": "NOASSERTION",
-      "licenseInfoFromFiles": [
-        "NOASSERTION"
-      ],
-      "licenseDeclared": "NOASSERTION",
-      "copyrightText": "NOASSERTION",
-      "versionInfo": "0.1.2",
-      "externalRefs": [
-        {
-          "referenceCategory": "PACKAGE-MANAGER",
-          "referenceType": "purl",
-          "referenceLocator": \
-            "pkg:swid/acme/spdx.org/cli-app@0.1.2?tag_id=ac07..."
-        }
-      ],
-      "supplier": "Organization: acme",
-      "hasFiles": [
-        "SPDXRef-File--..."
-      ]
-    }
-  ],
-  "relationships": [
-    {
-      "relationshipType": "DESCRIBES",
-      "relatedSpdxElement": "SPDXRef-RootPackage",
-      "spdxElementId": "SPDXRef-DOCUMENT"
-    },
-    {
-      "relationshipType": "DEPENDS_ON",
-      "relatedSpdxElement": "SPDXRef-Package-FF36801C1982452...",
-      "spdxElementId": "SPDXRef-RootPackage"
-    }
-  ],
-  "documentDescribes": [
-    "SPDXRef-RootPackage"
-  ],
-  "externalDocumentRefs": []
-}
-
-
-

Response:

-
-
-HTTP/1.1 200 Ok
-Content-Type: application/cose
-
-Payload (in CBOR diagnostic notation)
-
-18([                            / COSE Sign1         /
-  h'a1013822',                  / Protected Header   /
-  {},                           / Unprotected Header /
-  null,                         / Detached Payload   /
-  h'269cd68f4211dffc...0dcb29c' / Signature          /
-])
-
-
-
-
-
+

-2.2.2. Resolve Signed Statement +2.2.1. Resolve Signed Statement

-

This endpoint enables Transparency Service APIs to act like Artifact Repositories, and serve Signed Statements directly, instead of indirectly through Receipts.

-

Request:

-
+

This endpoint enables Transparency Service APIs to act like Artifact Repositories, and serve Signed Statements directly, instead of indirectly through Receipts.

+

Request:

+
 GET /signed-statements/9e4f...688a HTTP/1.1
 Host: transparency.example
 Accept: application/cose
-
+
-

Response:

-

One of the following:

+

Response:

+

One of the following:

-
+
-2.2.2.1. Status 200 - Success +2.2.1.1. Status 200 - Success
-
+
 HTTP/1.1 200 Ok
 Content-Type: application/cose
@@ -2015,18 +1914,18 @@ 

   null,                         / Detached Payload   /
   h'269cd68f4211dffc...0dcb29c' / Signature          /
 ])
-
+
-
+
-2.2.2.2. Status 404 - Not Found +2.2.1.2. Status 404 - Not Found
-

The following expected errors are defined. -Implementations MAY return other errors, so long as they are valid [RFC9290] objects.

-
+

The following expected errors are defined. +Implementations MAY return other errors, so long as they are valid [RFC9290] objects.

+
 HTTP/1.1 404 Not Found
 application/concise-problem-details+cbor
@@ -2039,31 +1938,31 @@ 

   / instance /      -3: \
           "urn:ietf:params:scitt:error:notFound",
   / response-code / -4: 404,
-
+
-
+
-2.2.2.3. Eventual Consistency +2.2.1.3. Eventual Consistency
-

For all responses additional eventually consistent operation details MAY be present. -Support for eventually consistent Receipts is implementation specific, and out of scope for this specification.

+

For all responses additional eventually consistent operation details MAY be present. +Support for eventually consistent Receipts is implementation specific, and out of scope for this specification.

-
+

-2.2.3. Exchange Receipt +2.2.2. Exchange Receipt

-

This endpoint is used to exchange old or expiring Receipts for fresh ones.

-

The iat, exp and kid claims can change each time a Receipt is exchanged.

-

This means that fresh Receipts can have more recent issued at times, further in the future expiration times, and be signed with new signature algorithms.

-

Request:

-
+

This endpoint is used to exchange old or expiring Receipts for fresh ones.

+

The iat, exp and kid claims can change each time a Receipt is exchanged.

+

This means that fresh Receipts can have more recent issued at times, further in the future expiration times, and be signed with new signature algorithms.

+

Request:

+
 POST /exchange/receipt HTTP/1.1
 Host: transparency.example
@@ -2077,15 +1976,15 @@ 

   null,                         / Detached Payload   /
   h'269cd68f4211dffc...0dcb29c' / Signature          /
 ])
-
+
-
+
-2.2.3.1. Status 200 +2.2.2.1. Status 200
-

A new Receipt:

-
+

A new Receipt:

+
 HTTP/1.1 200 Ok
 Location: https://transparency.example/entries/67ed...befe
@@ -2100,29 +1999,29 @@ 

   null,                         / Detached Payload   /
   h'269cd68f4211dffc...0dcb29c' / Signature          /
 ])
-
+
-
+

-2.2.4. Resolve Issuer +2.2.3. Resolve Issuer

-

This endpoint is inspired by [I-D.draft-ietf-oauth-sd-jwt-vc].

-

The following is a non-normative example of a HTTP request for the Issuer Metadata configuration when iss is set to https://transparency.example/tenant/1234:

-

Request:

-
+

This endpoint is inspired by [I-D.draft-ietf-oauth-sd-jwt-vc].

+

The following is a non-normative example of a HTTP request for the Issuer Metadata configuration when iss is set to https://transparency.example/tenant/1234:

+

Request:

+
 GET /.well-known/issuer/tenant/1234 HTTP/1.1
 Host: transparency.example
 Accept: application/json
-
+
-

Response:

-
+

Response:

+
 HTTP/1.1 200 Ok
 Content-Type: application/json
@@ -2154,29 +2053,29 @@ 

     ]
   }
 }
-
+
-
+

-2.2.5. Request Nonce +2.2.4. Request Nonce

-

This endpoint in inspired by [I-D.draft-demarco-oauth-nonce-endpoint].

-

Authentication SHOULD NOT be implemented for this endpoint. +

This endpoint in inspired by [I-D.draft-demarco-oauth-nonce-endpoint].

+

Authentication SHOULD NOT be implemented for this endpoint. This endpoint is used to demonstrate proof of possession, which is the reason that authentication is not required. -Client holding signed statements that require demonstrating proof of possession MUST use this endpoint to obtain a nonce.

-

Request:

-
+Client holding signed statements that require demonstrating proof of possession MUST use this endpoint to obtain a nonce.

+

Request:

+
 GET /nonce HTTP/1.1
 Host: transparency.example
 Accept: application/json
-
+
-

Response:

-
+

Response:

+
 HTTP/1.1 200 OK
 Content-Type: application/json
@@ -2184,7 +2083,7 @@ 

 {
   "nonce": "d2JhY2NhbG91cmVqdWFuZGFt"
 }
-
+
@@ -2296,8 +2195,7 @@
4.4.1.3. Message Modification Attacks
-

While most relevant modification attacks are mitigated by the use of the Issuer signature on the Signed Statement, the Issue Statement endpoint presents an opportunity for manipulation of messages and misrepresentation of Issuer intent that could mislead later Verifiers.

-

Transparency Services offering the Issue Statement endpoint MUST require authentication and transport-level security for that endpoint, MUST NOT modify anything in the message to be signed, and MUST take steps to ensure that the party calling the endpoint is authorized to register statements on behalf of the specified Issuer.

+

Modification attacks are mitigated by the use of the Issuer signature on the Signed Statement.

@@ -2305,20 +2203,8 @@
4.4.1.4. Message Insertion Attacks
-

While most relevant insertion attacks are mitigated by the use of the Issuer signature on the Signed Statement, the Issue Statement endpoint presents an opportunity for insertion of messages and misrepresentation of Issuer intent that could mislead later Verifiers. -There are 2 most likely avenues to this attack:

- -

Clients relying on the Issue Statement endpoint SHOULD take steps to ensure their endpoint authentication credentials are securely stored and can be rotated and/or revoked in the case of a breach.

-

Transparency Services offering the Issue Statement endpoint MUST require authentication and transport-level security for that endpoint, and MUST enable the rotation and revocation of those credentials.

-

Transparency Services offering the Issue Statement endpoint MUST take careful steps in both design and operation of their software stack to prevent the theft or inappropriate use of the Issuer keys they use to sign Statements on behalf of Issuers, such as HSMs for storage and least-privilege, regularly refreshed access controls for use.

-

Transparency Services MAY also implement additional protections such as anomaly detection or rate limiting in order to mitigate the impact of any breach.

+

Insertion attacks are mitigated by the use of the Issuer signature on the Signed Statement, therefore care must be taken in the protection of Issuer keys and credentials to avoid theft Issuer and impersonation.

+

Transparency Services MAY also implement additional protections such as anomaly detection or rate limiting in order to mitigate the impact of any breach.

diff --git a/draft-ietf-scitt-scrapi.txt b/draft-ietf-scitt-scrapi.txt index 8d437c2..37d126d 100644 --- a/draft-ietf-scitt-scrapi.txt +++ b/draft-ietf-scitt-scrapi.txt @@ -77,11 +77,10 @@ Table of Contents 2.1.3. Check Registration 2.1.4. Resolve Receipt 2.2. Optional Endpoints - 2.2.1. Issue Signed Statement - 2.2.2. Resolve Signed Statement - 2.2.3. Exchange Receipt - 2.2.4. Resolve Issuer - 2.2.5. Request Nonce + 2.2.1. Resolve Signed Statement + 2.2.2. Exchange Receipt + 2.2.3. Resolve Issuer + 2.2.4. Request Nonce 3. Privacy Considerations 4. Security Considerations 4.1. General Scope @@ -665,101 +664,7 @@ Table of Contents The following HTTP endpoints are optional to implement. -2.2.1. Issue Signed Statement - - Authentication MUST be implemented for this endpoint. - - This endpoint enables a Transparency Service to be an issuer of - Signed Statements on behalf of authenticated clients. This supports - cases where a client lacks the ability to perform complex - cryptographic operations, but can be authenticated and report - statements and measurements. - - Request: - - POST /signed-statements/issue HTTP/1.1 - Host: transparency.example - Accept: application/json - Content-Type: application/spdx+json - Payload - - { - "spdxVersion": "SPDX-2.2", - "dataLicense": "CC0-1.0", - "SPDXID": "SPDXRef-DOCUMENT", - "name": "cli-app 0.1.2", - "documentNamespace": \ - "https://spdx.org/spdxdocs/\ - sbom-tool-2.2.7-38f6.../cli-app/0.1.2/0d06...", - "creationInfo": { - "created": "2024-08-16T21:44:54Z", - "creators": [ - "Organization: acme" - ] - }, - "files": [ - { - "name": "cli-app", - "SPDXID": "SPDXRef-RootPackage", - "downloadLocation": "NOASSERTION", - "packageVerificationCode": { - "packageVerificationCodeValue": "ecf0aae2a849cc51..." - }, - "filesAnalyzed": true, - "licenseConcluded": "NOASSERTION", - "licenseInfoFromFiles": [ - "NOASSERTION" - ], - "licenseDeclared": "NOASSERTION", - "copyrightText": "NOASSERTION", - "versionInfo": "0.1.2", - "externalRefs": [ - { - "referenceCategory": "PACKAGE-MANAGER", - "referenceType": "purl", - "referenceLocator": \ - "pkg:swid/acme/spdx.org/cli-app@0.1.2?tag_id=ac07..." - } - ], - "supplier": "Organization: acme", - "hasFiles": [ - "SPDXRef-File--..." - ] - } - ], - "relationships": [ - { - "relationshipType": "DESCRIBES", - "relatedSpdxElement": "SPDXRef-RootPackage", - "spdxElementId": "SPDXRef-DOCUMENT" - }, - { - "relationshipType": "DEPENDS_ON", - "relatedSpdxElement": "SPDXRef-Package-FF36801C1982452...", - "spdxElementId": "SPDXRef-RootPackage" - } - ], - "documentDescribes": [ - "SPDXRef-RootPackage" - ], - "externalDocumentRefs": [] - } - - Response: - - HTTP/1.1 200 Ok - Content-Type: application/cose - - Payload (in CBOR diagnostic notation) - - 18([ / COSE Sign1 / - h'a1013822', / Protected Header / - {}, / Unprotected Header / - null, / Detached Payload / - h'269cd68f4211dffc...0dcb29c' / Signature / - ]) - -2.2.2. Resolve Signed Statement +2.2.1. Resolve Signed Statement This endpoint enables Transparency Service APIs to act like Artifact Repositories, and serve Signed Statements directly, instead of @@ -775,7 +680,7 @@ Table of Contents One of the following: -2.2.2.1. Status 200 - Success +2.2.1.1. Status 200 - Success HTTP/1.1 200 Ok Content-Type: application/cose @@ -789,7 +694,7 @@ Table of Contents h'269cd68f4211dffc...0dcb29c' / Signature / ]) -2.2.2.2. Status 404 - Not Found +2.2.1.2. Status 404 - Not Found The following expected errors are defined. Implementations MAY return other errors, so long as they are valid [RFC9290] objects. @@ -806,13 +711,13 @@ Table of Contents "urn:ietf:params:scitt:error:notFound", / response-code / -4: 404, -2.2.2.3. Eventual Consistency +2.2.1.3. Eventual Consistency For all responses additional eventually consistent operation details MAY be present. Support for eventually consistent Receipts is implementation specific, and out of scope for this specification. -2.2.3. Exchange Receipt +2.2.2. Exchange Receipt This endpoint is used to exchange old or expiring Receipts for fresh ones. @@ -839,7 +744,7 @@ Table of Contents h'269cd68f4211dffc...0dcb29c' / Signature / ]) -2.2.3.1. Status 200 +2.2.2.1. Status 200 A new Receipt: @@ -857,7 +762,7 @@ Table of Contents h'269cd68f4211dffc...0dcb29c' / Signature / ]) -2.2.4. Resolve Issuer +2.2.3. Resolve Issuer This endpoint is inspired by [I-D.draft-ietf-oauth-sd-jwt-vc]. @@ -904,7 +809,7 @@ Table of Contents } } -2.2.5. Request Nonce +2.2.4. Request Nonce This endpoint in inspired by [I-D.draft-demarco-oauth-nonce-endpoint]. @@ -1028,45 +933,15 @@ Table of Contents 4.4.1.3. Message Modification Attacks - While most relevant modification attacks are mitigated by the use of - the Issuer signature on the Signed Statement, the Issue Statement - endpoint presents an opportunity for manipulation of messages and - misrepresentation of Issuer intent that could mislead later - Verifiers. - - Transparency Services offering the Issue Statement endpoint MUST - require authentication and transport-level security for that - endpoint, MUST NOT modify anything in the message to be signed, and - MUST take steps to ensure that the party calling the endpoint is - authorized to register statements on behalf of the specified Issuer. + Modification attacks are mitigated by the use of the Issuer signature + on the Signed Statement. 4.4.1.4. Message Insertion Attacks - While most relevant insertion attacks are mitigated by the use of the - Issuer signature on the Signed Statement, the Issue Statement - endpoint presents an opportunity for insertion of messages and - misrepresentation of Issuer intent that could mislead later - Verifiers. There are 2 most likely avenues to this attack: - - * Stolen client endpoint authentication credentials - - * Stolen or misused Issuer keys held in the Transparency Service on - behalf of clients - - Clients relying on the Issue Statement endpoint SHOULD take steps to - ensure their endpoint authentication credentials are securely stored - and can be rotated and/or revoked in the case of a breach. - - Transparency Services offering the Issue Statement endpoint MUST - require authentication and transport-level security for that - endpoint, and MUST enable the rotation and revocation of those - credentials. - - Transparency Services offering the Issue Statement endpoint MUST take - careful steps in both design and operation of their software stack to - prevent the theft or inappropriate use of the Issuer keys they use to - sign Statements on behalf of Issuers, such as HSMs for storage and - least-privilege, regularly refreshed access controls for use. + Insertion attacks are mitigated by the use of the Issuer signature on + the Signed Statement, therefore care must be taken in the protection + of Issuer keys and credentials to avoid theft Issuer and + impersonation. Transparency Services MAY also implement additional protections such as anomaly detection or rate limiting in order to mitigate the impact