Script updating gh-pages from 8d38c05. [ci skip]

Author: ID Bot

pb/ad_review/draft-ietf-oauth-status-list.html

@@ -1978,9 +1978,9 @@ <h3 id="name-status-list-token-in-cwt-fo">
 d2845820a2012610781a6170706c69636174696f6e2f7374617475736c6973742b63
 7774a1044231325850a502782168747470733a2f2f6578616d706c652e636f6d2f73
 74617475736c697374732f31061a648c5bea041a8898dfea19fffe19a8c019fffda2
-646269747301636c73744a78dadbb918000217015d58402574c628fb3ca309b51b47
-0d6fca529108d1adf5bc8fb6eb112f58aad3d0d4cf8cfb830a8f88756a1035bd5259
-e7febfd481970538f1a064e0264fd8fa319dbe
+646269747301636c73744a78dadbb918000217015d58408681dd0578a1e156e9444c
+ad40c00b8aa0ef364a3620cc5f9c9739f1cbd366049f274eea385d84566a5c658c9c
+1e71539d148b7c13c8a5f44da5961ba0bd4f42
 </pre><a href="#section-5.2-9" class="pilcrow">¶</a>
 </div>
 <p id="section-5.2-10">The following is the CBOR Annotated Hex output of the example above:<a href="#section-5.2-10" class="pilcrow">¶</a></p>
@@ -2005,12 +2005,12 @@ <h3 id="name-status-list-token-in-cwt-fo">
       6269747301636c73744a78da  #       "bits\x01clstJxÚ"
       dbb918000217015d          #       "Û¹\x18\x00\x02\x17\x01]"
     58 40                       #     bytes(64)
-      2574c628fb3ca309b51b470d  #       "%tÆ(û&lt;£\x09µ\x1bG\x0d"
-      6fca529108d1adf5bc8fb6eb  #       "oÊR\x91\x08Ñ\xadõ¼\x8f¶ë"
-      112f58aad3d0d4cf8cfb830a  #       "\x11/XªÓÐÔÏ\x8cû\x83\x0a"
-      8f88756a1035bd5259e7febf  #       "\x8f\x88uj\x105½RYçþ¿"
-      d481970538f1a064e0264fd8  #       "Ô\x81\x97\x058ñ\xa0dà&amp;OØ"
-      fa319dbe                  #       "ú1\x9d¾"
+      8681dd0578a1e156e9444cad  #       "\x86\x81Ý\x05x¡áVéDL\xad"
+      40c00b8aa0ef364a3620cc5f  #       "@À\x0b\x8a\xa0ï6J6 Ì_"
+      9c9739f1cbd366049f274eea  #       "\x9c\x979ñËÓf\x04\x9f'Nê"
+      385d84566a5c658c9c1e7153  #       "8]\x84Vj\e\x8c\x9c\x1eqS"
+      9d148b7c13c8a5f44da5961b  #       "\x9d\x14\x8b|\x13È¥ôM¥\x96\x1b"
+      a0bd4f42                  #       "\xa0½OB"
 </pre><a href="#section-5.2-11" class="pilcrow">¶</a>
 </div>
 </section>
@@ -2151,9 +2151,9 @@ <h3 id="name-referenced-token-in-cose">
 d28443a10126a1044231325866a502653132333435017368747470733a2f2f657861
 6d706c652e636f6d061a648c5bea041a8898dfea19ffffa16b7374617475735f6c69
 7374a2636964780063757269782168747470733a2f2f6578616d706c652e636f6d2f
-7374617475736c697374732f315840f1abf4b19c32ad64be61747ef6178eee743f69
-0c7cf92b1e30d2476d85933b3c2ad50961540213fe48a1545a1f23f555859d5322c7
-bc7706e6e1212dba0b882f
+7374617475736c697374732f3158407aa5d4cea352652a4389546c65673f7991d405
+df8e8d9949ca7e95e105b4816fe97d012f0b4ccc2010205cab9fc3d386cce24ab022
+1436760cc9514a82e90c91
 </pre><a href="#section-6.3-6" class="pilcrow">¶</a>
 </div>
 <p id="section-6.3-7">The following is the CBOR Annotated Hex output of the example above:<a href="#section-6.3-7" class="pilcrow">¶</a></p>
@@ -2178,12 +2178,12 @@ <h3 id="name-referenced-token-in-cose">
       2e636f6d2f7374617475736c  #       ".com/statusl"
       697374732f31              #       "ists/1"
     58 40                       #     bytes(64)
-      f1abf4b19c32ad64be61747e  #       "ñ«ô±\x9c2\xadd¾at~"
-      f6178eee743f690c7cf92b1e  #       "ö\x17\x8eît?i\x0c|ù+\x1e"
-      30d2476d85933b3c2ad50961  #       "0ÒGm\x85\x93;&lt;*Õ\x09a"
-      540213fe48a1545a1f23f555  #       "T\x02\x13þH¡TZ\x1f#õU"
-      859d5322c7bc7706e6e1212d  #       "\x85\x9dS"Ǽw\x06æá!-"
-      ba0b882f                  #       "º\x0b\x88/"
+      7aa5d4cea352652a4389546c  #       "z¥ÔΣRe*C\x89Tl"
+      65673f7991d405df8e8d9949  #       "eg?y\x91Ô\x05ß\x8e\x8d\x99I"
+      ca7e95e105b4816fe97d012f  #       "Ê~\x95á\x05´\x81oé}\x01/"
+      0b4ccc2010205cab9fc3d386  #       "\x0bLÌ \x10 \«\x9fÃÓ\x86"
+      cce24ab0221436760cc9514a  #       "ÌâJ°"\x146v\x0cÉQJ"
+      82e90c91                  #       "\x82é\x0c\x91"
 </pre><a href="#section-6.3-8" class="pilcrow">¶</a>
 </div>
 <p id="section-6.3-9">ISO mdoc <span>[<a href="#ISO.mdoc" class="cite xref">ISO.mdoc</a>]</span> may utilize the Status List mechanism by introducing the <code>status</code> parameter in the Mobile Security Object (MSO) as specified in Section 9.1.2. The <code>status</code> parameter uses the same encoding as a CWT as defined in <a href="#referenced-token-cose" class="auto internal xref">Section 6.3</a>.<a href="#section-6.3-9" class="pilcrow">¶</a></p>
@@ -2379,7 +2379,7 @@ <h3 id="name-status-list-request">
         </ul>
 <p id="section-8.1-5">If the Relying Party does not send an Accept Header, the response type is assumed to be known implicitly or out-of-band.<a href="#section-8.1-5" class="pilcrow">¶</a></p>
 <p id="section-8.1-6">A successful response that contains a Status List Token <span class="bcp14">MUST</span> use an HTTP status code in the 2xx range.<a href="#section-8.1-6" class="pilcrow">¶</a></p>
-<p id="section-8.1-7">A response <span class="bcp14">MAY</span> also choose to redirect the client to another URI using an HTTP status code in the 3xx range, which clients <span class="bcp14">SHOULD</span> follow. A client <span class="bcp14">SHOULD</span> detect and intervene in cyclical redirections (i.e., "infinite" redirection loops). See <a href="#redirects" class="auto internal xref">Section 11.4</a> for further guidance on redirects.<a href="#section-8.1-7" class="pilcrow">¶</a></p>
+<p id="section-8.1-7">A response <span class="bcp14">MAY</span> also choose to redirect the client to another URI using an HTTP status code in the 3xx range, which clients <span class="bcp14">SHOULD</span> follow. See <a href="#redirects" class="auto internal xref">Section 11.4</a> for security considerations on redirects.<a href="#section-8.1-7" class="pilcrow">¶</a></p>
 <p id="section-8.1-8">The following are non-normative examples of a request and response for a Status List Token with type <code>application/statuslist+jwt</code>:<a href="#section-8.1-8" class="pilcrow">¶</a></p>
 <div class="alignLeft art-ascii-art art-text artwork" id="section-8.1-9">
 <pre>
@@ -2397,8 +2397,8 @@ <h3 id="name-status-list-request">
 yJleHAiOjIyOTE3MjAxNzAsImlhdCI6MTY4NjkyMDE3MCwiaXNzIjoiaHR0cHM6Ly9le
 GFtcGxlLmNvbSIsInN0YXR1c19saXN0Ijp7ImJpdHMiOjEsImxzdCI6ImVOcmJ1UmdBQ
 WhjQlhRIn0sInN1YiI6Imh0dHBzOi8vZXhhbXBsZS5jb20vc3RhdHVzbGlzdHMvMSIsI
-nR0bCI6NDMyMDB9.8ZzvWsUWWvdRDW2quZcLlj28y8Je3ejw20EqLk662ssZb9rwlnuA
-gjjtBYBIIkv0VMUxaqQ_OL3CTmJZaDMkiw
+nR0bCI6NDMyMDB9.y_p6jeXfKQyeXc0kYSSTT6guxCX88eqZscMmiHDRphWOZxA9XCtY
+gqUjP-uw8LVaWZiymuRpbEwF_C0t5rxaDA
 </pre><a href="#section-8.1-10" class="pilcrow">¶</a>
 </div>
 </section>
@@ -2505,8 +2505,8 @@ <h3 id="name-historical-resolution">
 yJleHAiOjIyOTE3MjAxNzAsImlhdCI6MTY4NjkyMDE3MCwiaXNzIjoiaHR0cHM6Ly9le
 GFtcGxlLmNvbSIsInN0YXR1c19saXN0Ijp7ImJpdHMiOjEsImxzdCI6ImVOcmJ1UmdBQ
 WhjQlhRIn0sInN1YiI6Imh0dHBzOi8vZXhhbXBsZS5jb20vc3RhdHVzbGlzdHMvMSIsI
-nR0bCI6NDMyMDB9.8ZzvWsUWWvdRDW2quZcLlj28y8Je3ejw20EqLk662ssZb9rwlnuA
-gjjtBYBIIkv0VMUxaqQ_OL3CTmJZaDMkiw
+nR0bCI6NDMyMDB9.y_p6jeXfKQyeXc0kYSSTT6guxCX88eqZscMmiHDRphWOZxA9XCtY
+gqUjP-uw8LVaWZiymuRpbEwF_C0t5rxaDA
 </pre><a href="#section-8.4-7" class="pilcrow">¶</a>
 </div>
 </section>
@@ -2704,15 +2704,15 @@ <h3 id="name-key-resolution-and-trust-ma">
         <h3 id="name-redirection-3xx">
 <a href="#section-11.4" class="section-number selfRef">11.4. </a><a href="#name-redirection-3xx" class="section-name selfRef">Redirection 3xx</a>
         </h3>
-<p id="section-11.4-1">Clients that follow 3xx (Redirection) class of status codes should be aware of possible dangers of redirects, such as infinite redirection loops since they could be used as an attack vector for possible denial of service attacks on clients. The general guidance for redirects given in Section 15.4 of <span>[<a href="#RFC9110" class="cite xref">RFC9110</a>]</span> should be applied.<a href="#section-11.4-1" class="pilcrow">¶</a></p>
+<p id="section-11.4-1">Clients that follow 3xx (Redirection) class of status codes should be aware of possible dangers of redirects, such as infinite redirection loops since they could be used as an attack vector for possible denial of service attacks on clients. A client <span class="bcp14">SHOULD</span> detect and intervene in cyclical redirections (i.e., "infinite" redirection loops). More guidance for redirects given in Section 15.4 of <span>[<a href="#RFC9110" class="cite xref">RFC9110</a>]</span> should be applied.<a href="#section-11.4-1" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="security-ttl">
 <section id="section-11.5">
         <h3 id="name-exiration-and-caching">
 <a href="#section-11.5" class="section-number selfRef">11.5. </a><a href="#name-exiration-and-caching" class="section-name selfRef">Exiration and Caching</a>
         </h3>
-<p id="section-11.5-1">Expiration and Caching information is conveyed via the <code>exp</code> and <code>ttl</code> claims as explained in <a href="#expiry-and-caching" class="auto internal xref">Section 13.7</a>. Clients should check that both values are within reasonable ranges before requesting new Status List Tokens based on these values to prevent accidentally creating unreasonable amounts of requests for a specific URL. Status Provider could accidentally or maliciously use this mechanism to effectively DDoS the provided Status List Token URI.<a href="#section-11.5-1" class="pilcrow">¶</a></p>
+<p id="section-11.5-1">Expiration and Caching information is conveyed via the <code>exp</code> and <code>ttl</code> claims as explained in <a href="#expiry-and-caching" class="auto internal xref">Section 13.7</a>. Clients should check that both values are within reasonable ranges before requesting new Status List Tokens based on these values to prevent accidentally creating unreasonable amounts of requests for a specific URL. Status Issuers could accidentally or maliciously use this mechanism to effectively DDoS the contained URL of the Status Provider.<a href="#section-11.5-1" class="pilcrow">¶</a></p>
 <p id="section-11.5-2">Concrete values for both claims heavily depend on the use-case requirements and clients should be configured with lower/upper bounds for these values that fit their respective use-cases.<a href="#section-11.5-2" class="pilcrow">¶</a></p>
 </section>
 </div>

pb/ad_review/draft-ietf-oauth-status-list.txt

@@ -727,9 +727,9 @@ Table of Contents
    d2845820a2012610781a6170706c69636174696f6e2f7374617475736c6973742b63
    7774a1044231325850a502782168747470733a2f2f6578616d706c652e636f6d2f73
    74617475736c697374732f31061a648c5bea041a8898dfea19fffe19a8c019fffda2
-   646269747301636c73744a78dadbb918000217015d58402574c628fb3ca309b51b47
-   0d6fca529108d1adf5bc8fb6eb112f58aad3d0d4cf8cfb830a8f88756a1035bd5259
-   e7febfd481970538f1a064e0264fd8fa319dbe
+   646269747301636c73744a78dadbb918000217015d58408681dd0578a1e156e9444c
+   ad40c00b8aa0ef364a3620cc5f9c9739f1cbd366049f274eea385d84566a5c658c9c
+   1e71539d148b7c13c8a5f44da5961ba0bd4f42
 
    The following is the CBOR Annotated Hex output of the example above:
 
@@ -752,12 +752,12 @@ d2                              # tag(18)
       6269747301636c73744a78da  #       "bits\x01clstJxÚ"
       dbb918000217015d          #       "Û¹\x18\x00\x02\x17\x01]"
     58 40                       #     bytes(64)
-      2574c628fb3ca309b51b470d  #       "%tÆ(û<£\x09µ\x1bG\x0d"
-      6fca529108d1adf5bc8fb6eb  #       "oÊR\x91\x08Ñ\xadõ¼\x8f¶ë"
-      112f58aad3d0d4cf8cfb830a  #       "\x11/XªÓÐÔÏ\x8cû\x83\x0a"
-      8f88756a1035bd5259e7febf  #       "\x8f\x88uj\x105½RYçþ¿"
-      d481970538f1a064e0264fd8  #       "Ô\x81\x97\x058ñ\xa0dà&OØ"
-      fa319dbe                  #       "ú1\x9d¾"
+      8681dd0578a1e156e9444cad  #       "\x86\x81Ý\x05x¡áVéDL\xad"
+      40c00b8aa0ef364a3620cc5f  #       "@À\x0b\x8a\xa0ï6J6 Ì_"
+      9c9739f1cbd366049f274eea  #       "\x9c\x979ñËÓf\x04\x9f'Nê"
+      385d84566a5c658c9c1e7153  #       "8]\x84Vj\e\x8c\x9c\x1eqS"
+      9d148b7c13c8a5f44da5961b  #       "\x9d\x14\x8b|\x13È¥ôM¥\x96\x1b"
+      a0bd4f42                  #       "\xa0½OB"
 
 6.  Referenced Token
 
@@ -900,9 +900,9 @@ d2                              # tag(18)
    d28443a10126a1044231325866a502653132333435017368747470733a2f2f657861
    6d706c652e636f6d061a648c5bea041a8898dfea19ffffa16b7374617475735f6c69
    7374a2636964780063757269782168747470733a2f2f6578616d706c652e636f6d2f
-   7374617475736c697374732f315840f1abf4b19c32ad64be61747ef6178eee743f69
-   0c7cf92b1e30d2476d85933b3c2ad50961540213fe48a1545a1f23f555859d5322c7
-   bc7706e6e1212dba0b882f
+   7374617475736c697374732f3158407aa5d4cea352652a4389546c65673f7991d405
+   df8e8d9949ca7e95e105b4816fe97d012f0b4ccc2010205cab9fc3d386cce24ab022
+   1436760cc9514a82e90c91
 
    The following is the CBOR Annotated Hex output of the example above:
 
@@ -925,12 +925,12 @@ d2                              # tag(18)
          2e636f6d2f7374617475736c  #       ".com/statusl"
          697374732f31              #       "ists/1"
        58 40                       #     bytes(64)
-         f1abf4b19c32ad64be61747e  #       "ñ«ô±\x9c2\xadd¾at~"
-         f6178eee743f690c7cf92b1e  #       "ö\x17\x8eît?i\x0c|ù+\x1e"
-         30d2476d85933b3c2ad50961  #       "0ÒGm\x85\x93;<*Õ\x09a"
-         540213fe48a1545a1f23f555  #       "T\x02\x13þH¡TZ\x1f#õU"
-         859d5322c7bc7706e6e1212d  #       "\x85\x9dS"Ǽw\x06æá!-"
-         ba0b882f                  #       "º\x0b\x88/"
+         7aa5d4cea352652a4389546c  #       "z¥ÔΣRe*C\x89Tl"
+         65673f7991d405df8e8d9949  #       "eg?y\x91Ô\x05ß\x8e\x8d\x99I"
+         ca7e95e105b4816fe97d012f  #       "Ê~\x95á\x05´\x81oé}\x01/"
+         0b4ccc2010205cab9fc3d386  #       "\x0bLÌ \x10 \«\x9fÃÓ\x86"
+         cce24ab0221436760cc9514a  #       "ÌâJ°"\x146v\x0cÉQJ"
+         82e90c91                  #       "\x82é\x0c\x91"
 
    ISO mdoc [ISO.mdoc] may utilize the Status List mechanism by
    introducing the status parameter in the Mobile Security Object (MSO)
@@ -1151,9 +1151,7 @@ d2                              # tag(18)
 
    A response MAY also choose to redirect the client to another URI
    using an HTTP status code in the 3xx range, which clients SHOULD
-   follow.  A client SHOULD detect and intervene in cyclical
-   redirections (i.e., "infinite" redirection loops).  See Section 11.4
-   for further guidance on redirects.
+   follow.  See Section 11.4 for security considerations on redirects.
 
    The following are non-normative examples of a request and response
    for a Status List Token with type application/statuslist+jwt:
@@ -1169,8 +1167,8 @@ d2                              # tag(18)
    yJleHAiOjIyOTE3MjAxNzAsImlhdCI6MTY4NjkyMDE3MCwiaXNzIjoiaHR0cHM6Ly9le
    GFtcGxlLmNvbSIsInN0YXR1c19saXN0Ijp7ImJpdHMiOjEsImxzdCI6ImVOcmJ1UmdBQ
    WhjQlhRIn0sInN1YiI6Imh0dHBzOi8vZXhhbXBsZS5jb20vc3RhdHVzbGlzdHMvMSIsI
-   nR0bCI6NDMyMDB9.8ZzvWsUWWvdRDW2quZcLlj28y8Je3ejw20EqLk662ssZb9rwlnuA
-   gjjtBYBIIkv0VMUxaqQ_OL3CTmJZaDMkiw
+   nR0bCI6NDMyMDB9.y_p6jeXfKQyeXc0kYSSTT6guxCX88eqZscMmiHDRphWOZxA9XCtY
+   gqUjP-uw8LVaWZiymuRpbEwF_C0t5rxaDA
 
 8.2.  Status List Response
 
@@ -1318,8 +1316,8 @@ d2                              # tag(18)
    yJleHAiOjIyOTE3MjAxNzAsImlhdCI6MTY4NjkyMDE3MCwiaXNzIjoiaHR0cHM6Ly9le
    GFtcGxlLmNvbSIsInN0YXR1c19saXN0Ijp7ImJpdHMiOjEsImxzdCI6ImVOcmJ1UmdBQ
    WhjQlhRIn0sInN1YiI6Imh0dHBzOi8vZXhhbXBsZS5jb20vc3RhdHVzbGlzdHMvMSIsI
-   nR0bCI6NDMyMDB9.8ZzvWsUWWvdRDW2quZcLlj28y8Je3ejw20EqLk662ssZb9rwlnuA
-   gjjtBYBIIkv0VMUxaqQ_OL3CTmJZaDMkiw
+   nR0bCI6NDMyMDB9.y_p6jeXfKQyeXc0kYSSTT6guxCX88eqZscMmiHDRphWOZxA9XCtY
+   gqUjP-uw8LVaWZiymuRpbEwF_C0t5rxaDA
 
 9.  Status List Aggregation
 
@@ -1536,18 +1534,20 @@ d2                              # tag(18)
    Clients that follow 3xx (Redirection) class of status codes should be
    aware of possible dangers of redirects, such as infinite redirection
    loops since they could be used as an attack vector for possible
-   denial of service attacks on clients.  The general guidance for
-   redirects given in Section 15.4 of [RFC9110] should be applied.
+   denial of service attacks on clients.  A client SHOULD detect and
+   intervene in cyclical redirections (i.e., "infinite" redirection
+   loops).  More guidance for redirects given in Section 15.4 of
+   [RFC9110] should be applied.
 
 11.5.  Exiration and Caching
 
    Expiration and Caching information is conveyed via the exp and ttl
    claims as explained in Section 13.7.  Clients should check that both
    values are within reasonable ranges before requesting new Status List
    Tokens based on these values to prevent accidentally creating
-   unreasonable amounts of requests for a specific URL.  Status Provider
+   unreasonable amounts of requests for a specific URL.  Status Issuers
    could accidentally or maliciously use this mechanism to effectively
-   DDoS the provided Status List Token URI.
+   DDoS the contained URL of the Status Provider.
 
    Concrete values for both claims heavily depend on the use-case
    requirements and clients should be configured with lower/upper bounds