From 693c24a860d664cd149715f692592e1b93006716 Mon Sep 17 00:00:00 2001 From: "A.J. Stein" Date: Tue, 15 Oct 2024 09:57:24 -0400 Subject: [PATCH 1/3] Condense items 2-4 in S4.3 registration section for #279 --- draft-ietf-scitt-architecture.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/draft-ietf-scitt-architecture.md b/draft-ietf-scitt-architecture.md index 39aa048..e9290a2 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -570,9 +570,7 @@ To register a Signed Statement, the Transparency Service performs the following 1. **Client authentication:** A Client authenticates with the Transparency Service before registering Signed Statements on behalf of one or more Issuers. Authentication and authorization are implementation-specific and out of scope of the SCITT architecture. -1. **Issuer Verification:** The Transparency Service MUST perform signature verification, as defined in {{Section 4.4 of RFC9052}}, and MAY perform additional checks as part of its Registration Policy. -1. **Signature verification:** The Transparency Service MUST verify the signature of the Signed Statement, as described in {{RFC9360}}, using the signature algorithm and verification key of the Issuer. -1. **Signed Statement validation:** The Transparency Service MUST check that the Signed Statement includes the required protected headers. +1. **TS Signed Statement Verification and Validation:** The Transparency Service MUST perform signature verification per {{Section 4.4 of RFC9052}} and MUST verify the signature of the Signed Statement with the signature algorithm and verification key of the Issuer per {{RFC9360}}. It MUST also check the Signed Statement includes the required protected headers. The Transparency Service MAY validate the Signed Statement payload in order to enforce domain specific registration policies that apply to specific content types. 1. **Apply Registration Policy:** The Transparency Service MUST check the attributes required by a Registration Policy are present in the protected headers. Custom Signed Statements are evaluated given the current Transparency Service state and the entire Envelope, and may use information contained in the attributes of named policies. From 9b4f891d2c51ec00714b0dfb2810355687a4a6ff Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Tue, 15 Oct 2024 07:03:09 -0700 Subject: [PATCH 2/3] Update draft-ietf-scitt-architecture.md --- draft-ietf-scitt-architecture.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-scitt-architecture.md b/draft-ietf-scitt-architecture.md index e9290a2..826ce12 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -570,7 +570,8 @@ To register a Signed Statement, the Transparency Service performs the following 1. **Client authentication:** A Client authenticates with the Transparency Service before registering Signed Statements on behalf of one or more Issuers. Authentication and authorization are implementation-specific and out of scope of the SCITT architecture. -1. **TS Signed Statement Verification and Validation:** The Transparency Service MUST perform signature verification per {{Section 4.4 of RFC9052}} and MUST verify the signature of the Signed Statement with the signature algorithm and verification key of the Issuer per {{RFC9360}}. It MUST also check the Signed Statement includes the required protected headers. +1. **TS Signed Statement Verification and Validation:** The Transparency Service MUST perform signature verification per {{Section 4.4 of RFC9052}} and MUST verify the signature of the Signed Statement with the signature algorithm and verification key of the Issuer per {{RFC9360}}. +It MUST also check the Signed Statement includes the required protected headers. The Transparency Service MAY validate the Signed Statement payload in order to enforce domain specific registration policies that apply to specific content types. 1. **Apply Registration Policy:** The Transparency Service MUST check the attributes required by a Registration Policy are present in the protected headers. Custom Signed Statements are evaluated given the current Transparency Service state and the entire Envelope, and may use information contained in the attributes of named policies. From 1a6a9052ad56093ab0afa1d7cfed6c0459cc463c Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Tue, 15 Oct 2024 08:00:04 -0700 Subject: [PATCH 3/3] Update draft-ietf-scitt-architecture.md --- draft-ietf-scitt-architecture.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-scitt-architecture.md b/draft-ietf-scitt-architecture.md index 826ce12..1b72c2d 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -571,7 +571,7 @@ To register a Signed Statement, the Transparency Service performs the following 1. **Client authentication:** A Client authenticates with the Transparency Service before registering Signed Statements on behalf of one or more Issuers. Authentication and authorization are implementation-specific and out of scope of the SCITT architecture. 1. **TS Signed Statement Verification and Validation:** The Transparency Service MUST perform signature verification per {{Section 4.4 of RFC9052}} and MUST verify the signature of the Signed Statement with the signature algorithm and verification key of the Issuer per {{RFC9360}}. -It MUST also check the Signed Statement includes the required protected headers. +The Transparency Service MUST also check the Signed Statement includes the required protected headers. The Transparency Service MAY validate the Signed Statement payload in order to enforce domain specific registration policies that apply to specific content types. 1. **Apply Registration Policy:** The Transparency Service MUST check the attributes required by a Registration Policy are present in the protected headers. Custom Signed Statements are evaluated given the current Transparency Service state and the entire Envelope, and may use information contained in the attributes of named policies.