Skip to content

Commit

Permalink
Script updating gh-pages from 0d86887. [ci skip]
Browse files Browse the repository at this point in the history
  • Loading branch information
ID Bot committed Oct 15, 2024
1 parent d942296 commit b0b0794
Show file tree
Hide file tree
Showing 2 changed files with 17 additions and 27 deletions.
21 changes: 8 additions & 13 deletions draft-ietf-scitt-architecture.html
Original file line number Diff line number Diff line change
Expand Up @@ -2019,26 +2019,21 @@ <h3 id="name-registration">
Authentication and authorization are implementation-specific and out of scope of the SCITT architecture.<a href="#section-4.3-2.1.1" class="pilcrow"></a></p>
</li>
<li id="section-4.3-2.2">
<p id="section-4.3-2.2.1"><strong>Issuer Verification:</strong> The Transparency Service <span class="bcp14">MUST</span> perform signature verification, as defined in <span><a href="https://rfc-editor.org/rfc/rfc9052#section-4.4" class="relref">Section 4.4</a> of [<a href="#RFC9052" class="cite xref">RFC9052</a>]</span>, and <span class="bcp14">MAY</span> perform additional checks as part of its Registration Policy.<a href="#section-4.3-2.2.1" class="pilcrow"></a></p>
<p id="section-4.3-2.2.1"><strong>TS Signed Statement Verification and Validation:</strong> The Transparency Service <span class="bcp14">MUST</span> perform signature verification per <span><a href="https://rfc-editor.org/rfc/rfc9052#section-4.4" class="relref">Section 4.4</a> of [<a href="#RFC9052" class="cite xref">RFC9052</a>]</span> and <span class="bcp14">MUST</span> verify the signature of the Signed Statement with the signature algorithm and verification key of the Issuer per <span>[<a href="#RFC9360" class="cite xref">RFC9360</a>]</span>.
The Transparency Service <span class="bcp14">MUST</span> also check the Signed Statement includes the required protected headers.
The Transparency Service <span class="bcp14">MAY</span> validate the Signed Statement payload in order to enforce domain specific registration policies that apply to specific content types.<a href="#section-4.3-2.2.1" class="pilcrow"></a></p>
</li>
<li id="section-4.3-2.3">
<p id="section-4.3-2.3.1"><strong>Signature verification:</strong> The Transparency Service <span class="bcp14">MUST</span> verify the signature of the Signed Statement, as described in <span>[<a href="#RFC9360" class="cite xref">RFC9360</a>]</span>, using the signature algorithm and verification key of the Issuer.<a href="#section-4.3-2.3.1" class="pilcrow"></a></p>
<p id="section-4.3-2.3.1"><strong>Apply Registration Policy:</strong> The Transparency Service <span class="bcp14">MUST</span> 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.<a href="#section-4.3-2.3.1" class="pilcrow"></a></p>
</li>
<li id="section-4.3-2.4">
<p id="section-4.3-2.4.1"><strong>Signed Statement validation:</strong> The Transparency Service <span class="bcp14">MUST</span> check that the Signed Statement includes the required protected headers.
The Transparency Service <span class="bcp14">MAY</span> validate the Signed Statement payload in order to enforce domain specific registration policies that apply to specific content types.<a href="#section-4.3-2.4.1" class="pilcrow"></a></p>
<p id="section-4.3-2.4.1"><strong>Register the Signed Statement</strong> to the Append-only Log.<a href="#section-4.3-2.4.1" class="pilcrow"></a></p>
</li>
<li id="section-4.3-2.5">
<p id="section-4.3-2.5.1"><strong>Apply Registration Policy:</strong> The Transparency Service <span class="bcp14">MUST</span> 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.<a href="#section-4.3-2.5.1" class="pilcrow"></a></p>
</li>
<li id="section-4.3-2.6">
<p id="section-4.3-2.6.1"><strong>Register the Signed Statement</strong> to the Append-only Log.<a href="#section-4.3-2.6.1" class="pilcrow"></a></p>
</li>
<li id="section-4.3-2.7">
<p id="section-4.3-2.7.1"><strong>Return the Receipt</strong>, which <span class="bcp14">MAY</span> be asynchronous from Registration.
<p id="section-4.3-2.5.1"><strong>Return the Receipt</strong>, which <span class="bcp14">MAY</span> be asynchronous from Registration.
The Transparency Service <span class="bcp14">MUST</span> be able to provide a Receipt for all registered Signed Statements.
Details about generating Receipts are described in <a href="#Receipt" class="auto internal xref">Section 4.4</a>.<a href="#section-4.3-2.7.1" class="pilcrow"></a></p>
Details about generating Receipts are described in <a href="#Receipt" class="auto internal xref">Section 4.4</a>.<a href="#section-4.3-2.5.1" class="pilcrow"></a></p>
</li>
</ol>
<p id="section-4.3-3">The last two steps may be shared between a batch of Signed Statements registered in the Append-only Log.<a href="#section-4.3-3" class="pilcrow"></a></p>
Expand Down
23 changes: 9 additions & 14 deletions draft-ietf-scitt-architecture.txt
Original file line number Diff line number Diff line change
Expand Up @@ -786,31 +786,26 @@ Table of Contents
are implementation-specific and out of scope of the SCITT
architecture.

2. *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.

3. *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.

4. *Signed Statement validation:* The Transparency Service MUST
check that the Signed Statement includes the required protected
2. *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]. 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.

5. *Apply Registration Policy:* The Transparency Service MUST check
3. *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.

6. *Register the Signed Statement* to the Append-only Log.
4. *Register the Signed Statement* to the Append-only Log.

7. *Return the Receipt*, which MAY be asynchronous from
5. *Return the Receipt*, which MAY be asynchronous from
Registration. The Transparency Service MUST be able to provide a
Receipt for all registered Signed Statements. Details about
generating Receipts are described in Section 4.4.
Expand Down

0 comments on commit b0b0794

Please sign in to comment.