Script updating gh-pages from 165f190. [ci skip]

ietf-wg-wimse · Dec 23, 2024 · 4a87e3f · 4a87e3f
1 parent ad93a5c
commit 4a87e3f
Show file tree

Hide file tree

Showing 6 changed files with 44 additions and 3,610 deletions.
diff --git a/draft-ietf-wimse-s2s-protocol.html b/draft-ietf-wimse-s2s-protocol.html
@@ -22,21 +22,21 @@
 Service B with mutual TLS authentication, while the next call from Service B to Service C
 would be authenticated at the application level. 
     " name="description">
-<meta content="xml2rfc 3.24.0" name="generator">
+<meta content="xml2rfc 3.25.0" name="generator">
 <meta content="workload" name="keyword">
 <meta content="identity" name="keyword">
 <meta content="draft-ietf-wimse-s2s-protocol-latest" name="ietf.draft">
 <!-- Generator version information:
-  xml2rfc 3.24.0
-    Python 3.12.7
+  xml2rfc 3.25.0
+    Python 3.12.8
     ConfigArgParse 1.7
     google-i18n-address 3.1.1
     intervaltree 3.1.0
     Jinja2 3.1.4
     lxml 5.3.0
     platformdirs 4.3.6
-    pycountry 22.3.5
-    PyYAML 6.0.1
+    pycountry 24.6.1
+    PyYAML 6.0.2
     requests 2.32.3
     setuptools 70.3.0
     wcwidth 0.2.13
@@ -548,7 +548,11 @@
   }
   pre, svg {
     display: inline-block;
-    overflow-x: auto;
+    /* In the horizontal direction, sometimes people make over-sized figures.
+       Scrollbars for those is therefore necessary: auto adds them as necessary..
+       In the vertical direction, the line-height can combine with the font
+       asender/descender height to produce scrollbars: hidden avoids that. */
+    overflow: auto hidden;
   }
   pre {
     max-width: 100%;
@@ -1058,7 +1062,7 @@
 </tr></thead>
 <tfoot><tr>
 <td class="left">Campbell, et al.</td>
-<td class="center">Expires 4 June 2025</td>
+<td class="center">Expires 26 June 2025</td>
 <td class="right">[Page]</td>
 </tr></tfoot>
 </table>
@@ -1071,12 +1075,12 @@
 <dd class="internet-draft">draft-ietf-wimse-s2s-protocol-latest</dd>
 <dt class="label-published">Published:</dt>
 <dd class="published">
-<time datetime="2024-12-01" class="published">1 December 2024</time>
+<time datetime="2024-12-23" class="published">23 December 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-06-04">4 June 2025</time></dd>
+<dd class="expires"><time datetime="2025-06-26">26 June 2025</time></dd>
 <dt class="label-authors">Authors:</dt>
 <dd class="authors">
 <div class="author">
@@ -1148,7 +1152,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 4 June 2025.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
+        This Internet-Draft will expire on 26 June 2025.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="copyright">
@@ -2073,15 +2077,20 @@ <h2 id="name-using-mutual-tls-for-servic">
         <h3 id="name-server-name-validation">
 <a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-server-name-validation" class="section-name selfRef">Server Name Validation</a>
         </h3>
-<p id="section-5.1-1">If the WIMSE client uses a hostname to connect to the server and the server certificate contain a DNS SAN the client <span class="bcp14">MUST</span> perform standard host name validation (<span><a href="https://rfc-editor.org/rfc/rfc9525#section-6.3" class="relref">Section 6.3</a> of [<a href="#RFC9525" class="cite xref">RFC9525</a>]</span>) unless it is configured with the information necessary to validate the peer's WIMSE identity. If the client did not perform standard host name validation then the WIMSE client <span class="bcp14">SHOULD</span> further use the WIMSE workload identifier to validate the server.  The host portion of the WIMSE URI is NOT treated as a host name as specified in section 6.4 of <span>[<a href="#RFC9525" class="cite xref">RFC9525</a>]</span> but rather as a trust domain. The server identity is encoded in the path portion of the WIMSE workload identifier in a deployment specific way. Validating the WIMSE workload identity could be a simple match on the trust domain and path portions of the identifier or validation may be based on the specific details on how the identifier is constructed. The path portion of the WIMSE identifier <span class="bcp14">MUST</span> always be considered in the scope of the trust domain.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
+<p id="section-5.1-1">If the WIMSE client uses a hostname to connect to the server and the server certificate contain a DNS SAN the client <span class="bcp14">MUST</span> perform standard host name validation (<span><a href="https://rfc-editor.org/rfc/rfc9525#section-6.3" class="relref">Section 6.3</a> of [<a href="#RFC9525" class="cite xref">RFC9525</a>]</span>) unless it is configured with the information necessary to validate the peer's WIMSE identity.
+If the client did not perform standard host name validation then the WIMSE client <span class="bcp14">SHOULD</span> further use the WIMSE workload identifier to validate the server.
+The host portion of the WIMSE workload identifier is NOT treated as a host name as specified in section 6.4 of <span>[<a href="#RFC9525" class="cite xref">RFC9525</a>]</span> but rather as a trust domain. The server identity is encoded in the path portion of the WIMSE workload identifier in a deployment specific way.
+Validating the WIMSE workload identity could be a simple match on the trust domain and path portions of the identifier or validation may be based on the specific details on how the identifier is constructed. The path portion of the WIMSE identifier <span class="bcp14">MUST</span> always be considered in the scope of the trust domain.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="client-name">
 <section id="section-5.2">
         <h3 id="name-client-authorization-using-">
 <a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-client-authorization-using-" class="section-name selfRef">Client Authorization Using the WIMSE Identity</a>
         </h3>
-<p id="section-5.2-1">The server application retrieves the client certificate WIMSE URI subjectAltName from the TLS layer for use in authorization, accounting and auditing.  For example, the full WIMSE URI may be matched against ACLs to authorize actions requested by the peer and the URI may be included in log messages to associate actions to the client workload for audit purposes. A deployment may specify other authorization policies based on the specific details of how the WIMSE identifier is constructed. The path portion of the WIMSE identifier <span class="bcp14">MUST</span> always be considered in the scope of the trust domain.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
+<p id="section-5.2-1">The server application retrieves the WIMSE workload identifier from the client certificate subjectAltName, which in turn is obtained from the TLS layer. The identifier is used in authorization, accounting and auditing.
+For example, the full WIMSE workload identifier may be matched against ACLs to authorize actions requested by the peer and the identifier may be included in log messages to associate actions to the client workload for audit purposes.
+A deployment may specify other authorization policies based on the specific details of how the WIMSE identifier is constructed. The path portion of the WIMSE identifier <span class="bcp14">MUST</span> always be considered in the scope of the trust domain.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
 </section>
 </div>
 </section>

diff --git a/draft-ietf-wimse-s2s-protocol.txt b/draft-ietf-wimse-s2s-protocol.txt
@@ -5,12 +5,12 @@
 Workload Identity in Multi System Environments               B. Campbell
 Internet-Draft                                             Ping Identity
 Intended status: Standards Track                              J. Salowey
-Expires: 4 June 2025                                              Venafi
+Expires: 26 June 2025                                             Venafi
                                                       A. Schwenkschuster
                                                                    SPIRL
                                                               Y. Sheffer
                                                                   Intuit
-                                                         1 December 2024
+                                                        23 December 2024
 
 
                 WIMSE Service to Service Authentication
@@ -66,7 +66,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 4 June 2025.
+   This Internet-Draft will expire on 26 June 2025.
 
 Copyright Notice
 
@@ -829,27 +829,29 @@ Table of Contents
    WIMSE identity.  If the client did not perform standard host name
    validation then the WIMSE client SHOULD further use the WIMSE
    workload identifier to validate the server.  The host portion of the
-   WIMSE URI is NOT treated as a host name as specified in section 6.4
-   of [RFC9525] but rather as a trust domain.  The server identity is
-   encoded in the path portion of the WIMSE workload identifier in a
-   deployment specific way.  Validating the WIMSE workload identity
-   could be a simple match on the trust domain and path portions of the
-   identifier or validation may be based on the specific details on how
-   the identifier is constructed.  The path portion of the WIMSE
-   identifier MUST always be considered in the scope of the trust
-   domain.
+   WIMSE workload identifier is NOT treated as a host name as specified
+   in section 6.4 of [RFC9525] but rather as a trust domain.  The server
+   identity is encoded in the path portion of the WIMSE workload
+   identifier in a deployment specific way.  Validating the WIMSE
+   workload identity could be a simple match on the trust domain and
+   path portions of the identifier or validation may be based on the
+   specific details on how the identifier is constructed.  The path
+   portion of the WIMSE identifier MUST always be considered in the
+   scope of the trust domain.
 
 5.2.  Client Authorization Using the WIMSE Identity
 
-   The server application retrieves the client certificate WIMSE URI
-   subjectAltName from the TLS layer for use in authorization,
-   accounting and auditing.  For example, the full WIMSE URI may be
+   The server application retrieves the WIMSE workload identifier from
+   the client certificate subjectAltName, which in turn is obtained from
+   the TLS layer.  The identifier is used in authorization, accounting
+   and auditing.  For example, the full WIMSE workload identifier may be
    matched against ACLs to authorize actions requested by the peer and
-   the URI may be included in log messages to associate actions to the
-   client workload for audit purposes.  A deployment may specify other
-   authorization policies based on the specific details of how the WIMSE
-   identifier is constructed.  The path portion of the WIMSE identifier
-   MUST always be considered in the scope of the trust domain.
+   the identifier may be included in log messages to associate actions
+   to the client workload for audit purposes.  A deployment may specify
+   other authorization policies based on the specific details of how the
+   WIMSE identifier is constructed.  The path portion of the WIMSE
+   identifier MUST always be considered in the scope of the trust
+   domain.
 
 6.  Security Considerations
 

diff --git a/index.html b/index.html
@@ -24,14 +24,6 @@ <h1>Editor's drafts for main branch of <a href="https://github.com/ietf-wg-wimse
         <td></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="ys-acks">ys-acks</a></h2>
-    <table id="branch-ys-acks">
-      <tr>
-        <td><a href="ys-acks/draft-ietf-wimse-s2s-protocol.html" class="html draft-ietf-wimse-s2s-protocol" title="WIMSE Service to Service Authentication (HTML)">WIMSE S2S Auth</a></td>
-        <td><a href="ys-acks/draft-ietf-wimse-s2s-protocol.txt" class="txt draft-ietf-wimse-s2s-protocol" title="WIMSE Service to Service Authentication (Text)">plain text</a></td>
-        <td><a href="https://author-tools.ietf.org/api/iddiff?url_1=https://ietf-wg-wimse.github.io/draft-ietf-wimse-s2s-protocol/draft-ietf-wimse-s2s-protocol.txt&amp;url_2=https://ietf-wg-wimse.github.io/draft-ietf-wimse-s2s-protocol/ys-acks/draft-ietf-wimse-s2s-protocol.txt" class="diff draft-ietf-wimse-s2s-protocol">diff with main</a></td>
-      </tr>
-    </table>
     <h2>Preview for branch <a href="arndt">arndt</a></h2>
     <h2>Preview for branch <a href="arndt/rfcfold_make">arndt/rfcfold_make</a></h2>
     <table id="branch-arndt/rfcfold_make">
@@ -62,7 +54,7 @@ <h2>Preview for branch <a href="issue-49">issue-49</a></h2>
       <tr>
         <td><a href="issue-49/draft-ietf-wimse-s2s-protocol.html" class="html draft-ietf-wimse-s2s-protocol" title="WIMSE Service to Service Authentication (HTML)">WIMSE S2S Auth</a></td>
         <td><a href="issue-49/draft-ietf-wimse-s2s-protocol.txt" class="txt draft-ietf-wimse-s2s-protocol" title="WIMSE Service to Service Authentication (Text)">plain text</a></td>
-        <td><a href="https://author-tools.ietf.org/api/iddiff?url_1=https://ietf-wg-wimse.github.io/draft-ietf-wimse-s2s-protocol/draft-ietf-wimse-s2s-protocol.txt&amp;url_2=https://ietf-wg-wimse.github.io/draft-ietf-wimse-s2s-protocol/issue-49/draft-ietf-wimse-s2s-protocol.txt" class="diff draft-ietf-wimse-s2s-protocol">diff with main</a></td>
+        <td>same as main</td>
       </tr>
     </table>
     <script>