From 5f98ae4976a5c61f220188140f6b657bdb722827 Mon Sep 17 00:00:00 2001
From: ID Bot <idbot@example.com>
Date: Tue, 5 Nov 2024 15:11:51 +0000
Subject: [PATCH] Script updating gh-pages from e363258. [ci skip]

---
 .../draft-ietf-scitt-scrapi.html              | 32 +++++++++----------
 .../draft-ietf-scitt-scrapi.txt               | 20 ++++++------
 2 files changed, 25 insertions(+), 27 deletions(-)

diff --git a/jag-uk/36-eliminate-json/draft-ietf-scitt-scrapi.html b/jag-uk/36-eliminate-json/draft-ietf-scitt-scrapi.html
index 98a368d..e165399 100644
--- a/jag-uk/36-eliminate-json/draft-ietf-scitt-scrapi.html
+++ b/jag-uk/36-eliminate-json/draft-ietf-scitt-scrapi.html
@@ -1084,7 +1084,7 @@
 </tr></thead>
 <tfoot><tr>
 <td class="left">Birkholz, et al.</td>
-<td class="center">Expires 8 May 2025</td>
+<td class="center">Expires 9 May 2025</td>
 <td class="right">[Page]</td>
 </tr></tfoot>
 </table>
@@ -1097,12 +1097,12 @@
 <dd class="internet-draft">draft-ietf-scitt-scrapi-latest</dd>
 <dt class="label-published">Published:</dt>
 <dd class="published">
-<time datetime="2024-11-04" class="published">4 November 2024</time>
+<time datetime="2024-11-05" class="published">5 November 2024</time>
     </dd>
 <dt class="label-intended-status">Intended Status:</dt>
 <dd class="intended-status">Standards Track</dd>
 <dt class="label-expires">Expires:</dt>
-<dd class="expires"><time datetime="2025-05-08">8 May 2025</time></dd>
+<dd class="expires"><time datetime="2025-05-09">9 May 2025</time></dd>
 <dt class="label-authors">Authors:</dt>
 <dd class="authors">
 <div class="author">
@@ -1160,7 +1160,7 @@ <h2 id="name-status-of-this-memo">
         time. It is inappropriate to use Internet-Drafts as reference
         material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
 <p id="section-boilerplate.1-4">
-        This Internet-Draft will expire on 8 May 2025.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
+        This Internet-Draft will expire on 9 May 2025.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="copyright">
@@ -1423,16 +1423,17 @@ <h4 id="name-transparency-configuration">
 <p id="section-2.1.1-1">Authentication <span class="bcp14">SHOULD NOT</span> be implemented for this endpoint.<a href="#section-2.1.1-1" class="pilcrow">¶</a></p>
 <p id="section-2.1.1-2">This endpoint is used to discover the capabilities and current configuration of a transparency service implementing this specification.<a href="#section-2.1.1-2" class="pilcrow">¶</a></p>
 <p id="section-2.1.1-3">The Transparency Service responds with a signed dictionary of configuration elements. These elements are Transparency-Service specific.<a href="#section-2.1.1-3" class="pilcrow">¶</a></p>
-<p id="section-2.1.1-4">Request:<a href="#section-2.1.1-4" class="pilcrow">¶</a></p>
-<div class="lang-http-message sourcecode" id="section-2.1.1-5">
+<p id="section-2.1.1-4">Contents of bodies are informative examples only.<a href="#section-2.1.1-4" class="pilcrow">¶</a></p>
+<p id="section-2.1.1-5">Request:<a href="#section-2.1.1-5" class="pilcrow">¶</a></p>
+<div class="lang-http-message sourcecode" id="section-2.1.1-6">
 <pre>
 GET /.well-known/transparency-configuration HTTP/1.1
 Host: transparency.example
 Accept: application/cose
-</pre><a href="#section-2.1.1-5" class="pilcrow">¶</a>
+</pre><a href="#section-2.1.1-6" class="pilcrow">¶</a>
 </div>
-<p id="section-2.1.1-6">Response:<a href="#section-2.1.1-6" class="pilcrow">¶</a></p>
-<div class="lang-http-message sourcecode" id="section-2.1.1-7">
+<p id="section-2.1.1-7">Response:<a href="#section-2.1.1-7" class="pilcrow">¶</a></p>
+<div class="lang-http-message sourcecode" id="section-2.1.1-8">
 <pre>
 HTTP/1.1 200 Ok
 Content-Type: application/cose
@@ -1451,10 +1452,10 @@ <h4 id="name-transparency-configuration">
     },
     h'ABCDEF1234567890ABCDEF1234567890'  ; Signature placeholder
 ])
-</pre><a href="#section-2.1.1-7" class="pilcrow">¶</a>
+</pre><a href="#section-2.1.1-8" class="pilcrow">¶</a>
 </div>
-<p id="section-2.1.1-8">Responses to this message are vendor-specific.
-Fields that are not understood <span class="bcp14">MUST</span> be ignored.<a href="#section-2.1.1-8" class="pilcrow">¶</a></p>
+<p id="section-2.1.1-9">Responses to this message are vendor-specific.
+Fields that are not understood <span class="bcp14">MUST</span> be ignored.<a href="#section-2.1.1-9" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="sec-register-signed-statement">
@@ -2089,7 +2090,7 @@ <h3 id="name-user-host-authentication">
 <p id="section-4.3-2">For those endpoints that require client authentication, Transparency Services <span class="bcp14">MUST</span> support at least one of the following options:<a href="#section-4.3-2" class="pilcrow">¶</a></p>
 <ul class="normal">
 <li class="normal" id="section-4.3-3.1">
-            <p id="section-4.3-3.1.1">HTTP Authorization header with a bearer JWT<a href="#section-4.3-3.1.1" class="pilcrow">¶</a></p>
+            <p id="section-4.3-3.1.1">HTTP Authorization header with a JWT<a href="#section-4.3-3.1.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-4.3-3.2">
             <p id="section-4.3-3.2.1">domain-bound API key<a href="#section-4.3-3.2.1" class="pilcrow">¶</a></p>
@@ -2098,8 +2099,7 @@ <h3 id="name-user-host-authentication">
             <p id="section-4.3-3.3.1">TLS client authentication<a href="#section-4.3-3.3.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
-<p id="section-4.3-4">Transparency Services <span class="bcp14">MUST</span> provide a configuration surface that allows Issuers to specify which authorized clients can submit Statements on their behalf.<a href="#section-4.3-4" class="pilcrow">¶</a></p>
-<p id="section-4.3-5">Where authentication methods rely on long term secrets, both clients and Transparency Services implementing this specification <span class="bcp14">MUST</span> allow for the revocation and rolling of authentication secrets.<a href="#section-4.3-5" class="pilcrow">¶</a></p>
+<p id="section-4.3-4">Where authentication methods rely on long term secrets, both clients and Transparency Services implementing this specification <span class="bcp14">SHOULD</span> allow for the revocation and rolling of authentication secrets.<a href="#section-4.3-4" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="sec-primary-threats">
@@ -2190,7 +2190,7 @@ <h5 id="name-replay-attacks">
 <p id="section-4.4.2.1-1">Replay attacks are not particularly concerning for SCITT or SCRAPI:
 once a statement is made, it is intended to be immutable and non-repudiable, so making it twice should not lead to any particular issues.
 There could be issues at the payload level (for instance, the statement "it is raining" may true when first submitted but not when replayed), but being payload-agnostic implementations of SCITT services cannot be required to worry about that.<a href="#section-4.4.2.1-1" class="pilcrow">¶</a></p>
-<p id="section-4.4.2.1-2">If the semantic content of the payload are time dependent and susceptible to replay attacks in this way then timestamps <span class="bcp14">MAY</span> be added to the payload signed by the Issuer.<a href="#section-4.4.2.1-2" class="pilcrow">¶</a></p>
+<p id="section-4.4.2.1-2">If the semantic content of the payload are time dependent and susceptible to replay attacks in this way then timestamps <span class="bcp14">MAY</span> be added to the protected header signed by the Issuer.<a href="#section-4.4.2.1-2" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="sec-message-deletion-attacks">
diff --git a/jag-uk/36-eliminate-json/draft-ietf-scitt-scrapi.txt b/jag-uk/36-eliminate-json/draft-ietf-scitt-scrapi.txt
index 8540ef7..7af9c4e 100644
--- a/jag-uk/36-eliminate-json/draft-ietf-scitt-scrapi.txt
+++ b/jag-uk/36-eliminate-json/draft-ietf-scitt-scrapi.txt
@@ -5,10 +5,10 @@
 SCITT                                                        H. Birkholz
 Internet-Draft                                            Fraunhofer SIT
 Intended status: Standards Track                               O. Steele
-Expires: 8 May 2025                                            Transmute
+Expires: 9 May 2025                                            Transmute
                                                                J. Geater
                                                          DataTrails Inc.
-                                                         4 November 2024
+                                                         5 November 2024
 
 
                           SCITT Reference APIs
@@ -52,7 +52,7 @@ Status of This Memo
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on 8 May 2025.
+   This Internet-Draft will expire on 9 May 2025.
 
 Copyright Notice
 
@@ -232,6 +232,8 @@ Table of Contents
    configuration elements.  These elements are Transparency-Service
    specific.
 
+   Contents of bodies are informative examples only.
+
    Request:
 
    GET /.well-known/transparency-configuration HTTP/1.1
@@ -801,19 +803,15 @@ Retry-After: <seconds>
    For those endpoints that require client authentication, Transparency
    Services MUST support at least one of the following options:
 
-   *  HTTP Authorization header with a bearer JWT
+   *  HTTP Authorization header with a JWT
 
    *  domain-bound API key
 
    *  TLS client authentication
 
-   Transparency Services MUST provide a configuration surface that
-   allows Issuers to specify which authorized clients can submit
-   Statements on their behalf.
-
    Where authentication methods rely on long term secrets, both clients
-   and Transparency Services implementing this specification MUST allow
-   for the revocation and rolling of authentication secrets.
+   and Transparency Services implementing this specification SHOULD
+   allow for the revocation and rolling of authentication secrets.
 
 4.4.  Primary threats
 
@@ -923,7 +921,7 @@ Retry-After: <seconds>
 
    If the semantic content of the payload are time dependent and
    susceptible to replay attacks in this way then timestamps MAY be
-   added to the payload signed by the Issuer.
+   added to the protected header signed by the Issuer.
 
 4.4.2.2.  Message deletion attacks