From b37dbb11977e8c5842ebfab613690a04b2815873 Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Tue, 13 Aug 2024 07:34:53 -0700 Subject: [PATCH] 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 9cd8adbb..ccde8d38 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -549,7 +549,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 [RFC 9052 4.4](https://datatracker.ietf.org/doc/html/rfc9052#section-4.4), and MAY perform additional checks as part of its Registration Policy. +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. The Transparency Service MAY validate the Signed Statement payload in order to enforce domain specific registration policies that apply to specific content types.