Script updating gh-pages from 20fc04d. [ci skip]

hannestschofenig-patch-3/draft-ietf-lamps-csr-attestation.html

@@ -16,7 +16,7 @@
 Attestation Results in Certificate Signing Requests (CSRs), such as PKCS#10 or Certificate Request Message Format (CRMF) payloads. This provides an elegant and automatable mechanism for transporting Evidence to a Certification Authority. 
        Including Evidence and Attestation Results along with a CSR can help to improve the assessment of the security posture for the private key, and can help the Certification Authority to assess whether it satisfies the requested certificate profile. 
     " name="description">
-<meta content="xml2rfc 3.26.0" name="generator">
+<meta content="xml2rfc 3.27.0" name="generator">
 <meta content="PKI" name="keyword">
 <meta content="PKCS#10" name="keyword">
 <meta content="CRMF" name="keyword">
@@ -25,8 +25,8 @@
 <meta content="Certificate Signing Requests" name="keyword">
 <meta content="draft-ietf-lamps-csr-attestation-latest" name="ietf.draft">
 <!-- Generator version information:
-  xml2rfc 3.26.0
-    Python 3.12.8
+  xml2rfc 3.27.0
+    Python 3.12.9
     ConfigArgParse 1.7
     google-i18n-address 3.1.1
     intervaltree 3.1.0
@@ -447,7 +447,7 @@
     margin-bottom: 0;
   }
 }
-dl > dt {
+dl:not(.dlNewline) > dt {
   float: left;
   margin-right: 2ch;
   min-width: 8ch;
@@ -1060,7 +1060,7 @@
 </tr></thead>
 <tfoot><tr>
 <td class="left">Ounsworth, et al.</td>
-<td class="center">Expires 17 August 2025</td>
+<td class="center">Expires 31 August 2025</td>
 <td class="right">[Page]</td>
 </tr></tfoot>
 </table>
@@ -1073,12 +1073,12 @@
 <dd class="internet-draft">draft-ietf-lamps-csr-attestation-latest</dd>
 <dt class="label-published">Published:</dt>
 <dd class="published">
-<time datetime="2025-02-13" class="published">13 February 2025</time>
+<time datetime="2025-02-27" class="published">27 February 2025</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-08-17">17 August 2025</time></dd>
+<dd class="expires"><time datetime="2025-08-31">31 August 2025</time></dd>
 <dt class="label-authors">Authors:</dt>
 <dd class="authors">
 <div class="author">
@@ -1142,7 +1142,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 17 August 2025.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
+        This Internet-Draft will expire on 31 August 2025.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="copyright">
@@ -1979,37 +1979,42 @@ <h3 id="name-evidence-attribute-and-exte">
 include a "userinfo" portion of an authority.  For example, a valid
 server name might be "verifier.example.com" or
 "verifier.example.com:8443", but not "[email protected]".<a href="#section-5.2-10" class="pilcrow">¶</a></p>
-<p id="section-5.2-11">In a typical usage scenario, the Relying Party is pre-configured with
+<p id="section-5.2-11">Relying Parties <span class="bcp14">SHOULD NOT</span> connect to a host name provided in the hint,
+especially if the verifier has no previous trust relationship with that
+host name, instead this <span class="bcp14">SHOULD</span> be used only as a lookup string for
+determining between a list of Verifiers that the Relying Party is
+pre-configured to use.<a href="#section-5.2-11" class="pilcrow">¶</a></p>
+<p id="section-5.2-12">In a typical usage scenario, the Relying Party is pre-configured with
 a list of trusted Verifiers and the corresponding hint values can be used to look
 up appropriate Verifier. The Relying Party is also configured with a trust
 anchor for each Verifier, which allows the Verifier to validate the signature
 protecting the Attestation Result. Tricking a Relying Party into interacting
-with an unknown and untrusted Verifier must be avoided.<a href="#section-5.2-11" class="pilcrow">¶</a></p>
-<p id="section-5.2-12">Usage of the hint field can be seen in the TPM2_attest example in
+with an unknown and untrusted Verifier must be avoided.<a href="#section-5.2-12" class="pilcrow">¶</a></p>
+<p id="section-5.2-13">Usage of the hint field can be seen in the TPM2_attest example in
 <a href="#appdx-tpm2" class="auto internal xref">Appendix A.2</a> where the type OID indicates the OID
 id-TcgAttestCertify and the corresponding hint identifies the Verifier as
-"tpmverifier.example.com".<a href="#section-5.2-12" class="pilcrow">¶</a></p>
-<div class="alignLeft art-text artwork" id="section-5.2-13">
+"tpmverifier.example.com".<a href="#section-5.2-13" class="pilcrow">¶</a></p>
+<div class="alignLeft art-text artwork" id="section-5.2-14">
 <pre>
 EvidenceBundle ::= SEQUENCE {
    evidences SEQUENCE SIZE (1..MAX) OF EvidenceStatement,
    certs SEQUENCE SIZE (1..MAX) OF CertificateChoices OPTIONAL
       -- CertificateChoices MUST only contain certificate or other,
       -- see Section 10.2.2 of [RFC5652]
 }
-</pre><a href="#section-5.2-13" class="pilcrow">¶</a>
+</pre><a href="#section-5.2-14" class="pilcrow">¶</a>
 </div>
-<p id="section-5.2-14">The CertificateChoices structure defined in <span>[<a href="#RFC6268" class="cite xref">RFC6268</a>]</span> allows for carrying certificates in the default X.509 <span>[<a href="#RFC5280" class="cite xref">RFC5280</a>]</span> format, or in other non-X.509 certificate formats. CertificateChoices <span class="bcp14">MUST</span> only contain certificate or other. CertificateChoices <span class="bcp14">MUST NOT</span> contain extendedCertificate, v1AttrCert, or v2AttrCert. Note that for non-ASN.1 certificate formats, the CertificateChoices <span class="bcp14">MUST</span> use <code>other [3]</code> with an <code>OtherCertificateFormat.Type</code> of <code>OCTET STRING</code>, and then can carry any binary data.<a href="#section-5.2-14" class="pilcrow">¶</a></p>
-<p id="section-5.2-15">The <code>certs</code> field contains a set of certificates that
+<p id="section-5.2-15">The CertificateChoices structure defined in <span>[<a href="#RFC6268" class="cite xref">RFC6268</a>]</span> allows for carrying certificates in the default X.509 <span>[<a href="#RFC5280" class="cite xref">RFC5280</a>]</span> format, or in other non-X.509 certificate formats. CertificateChoices <span class="bcp14">MUST</span> only contain certificate or other. CertificateChoices <span class="bcp14">MUST NOT</span> contain extendedCertificate, v1AttrCert, or v2AttrCert. Note that for non-ASN.1 certificate formats, the CertificateChoices <span class="bcp14">MUST</span> use <code>other [3]</code> with an <code>OtherCertificateFormat.Type</code> of <code>OCTET STRING</code>, and then can carry any binary data.<a href="#section-5.2-15" class="pilcrow">¶</a></p>
+<p id="section-5.2-16">The <code>certs</code> field contains a set of certificates that
 is intended to validate the contents of an Evidence statement
 contained in <code>evidences</code>, if required. For each Evidnece statement the set of certificates should contain
 the certificate that contains the public key needed to directly validate the
 Evidence statement. Additional certificates may be provided, for example, to chain the
-Evidence signer key back to an agreed upon trust anchor. No specific order of the certificates in <code>certs</code> <span class="bcp14">SHOULD</span> be expected because certificates contained in <code>certs</code> may be needed to validate different Evidence statements.<a href="#section-5.2-15" class="pilcrow">¶</a></p>
-<p id="section-5.2-16">This specification places no restriction on mixing certificate types within the <code>certs</code> field. For example a non-X.509 Evidence signer certificate <span class="bcp14">MAY</span> chain to a trust anchor via a chain of X.509 certificates. It is up to the Attester and its Verifier to agree on supported certificate formats.<a href="#section-5.2-16" class="pilcrow">¶</a></p>
+Evidence signer key back to an agreed upon trust anchor. No specific order of the certificates in <code>certs</code> <span class="bcp14">SHOULD</span> be expected because certificates contained in <code>certs</code> may be needed to validate different Evidence statements.<a href="#section-5.2-16" class="pilcrow">¶</a></p>
+<p id="section-5.2-17">This specification places no restriction on mixing certificate types within the <code>certs</code> field. For example a non-X.509 Evidence signer certificate <span class="bcp14">MAY</span> chain to a trust anchor via a chain of X.509 certificates. It is up to the Attester and its Verifier to agree on supported certificate formats.<a href="#section-5.2-17" class="pilcrow">¶</a></p>
 <span id="name-definitions-of-csr-attribut"></span><div id="code-extensions">
 <figure id="figure-11">
-          <div class="alignLeft art-text artwork" id="section-5.2-17.1">
+          <div class="alignLeft art-text artwork" id="section-5.2-18.1">
 <pre>
 id-aa-evidence OBJECT IDENTIFIER ::= { id-ata 59 }
 
@@ -2031,8 +2036,8 @@ <h3 id="name-evidence-attribute-and-exte">
 <a href="#name-definitions-of-csr-attribut" class="selfRef">Definitions of CSR attribute and extension</a>
           </figcaption></figure>
 </div>
-<p id="section-5.2-18">The Extension variant illustrated in <a href="#code-extensions" class="auto internal xref">Figure 11</a> is intended only for use within CRMF CSRs and is <span class="bcp14">NOT RECOMMENDED</span> to be used within X.509 certificates due to the privacy implications of publishing Evidence about the end entity's hardware environment. See <a href="#sec-con-publishing-x509" class="auto internal xref">Section 8.3</a> for more discussion.<a href="#section-5.2-18" class="pilcrow">¶</a></p>
-<p id="section-5.2-19">By the nature of the PKIX ASN.1 classes <span>[<a href="#RFC5912" class="cite xref">RFC5912</a>]</span>, there are multiple ways to convey multiple Evidence statements: by including multiple copies of <code>attr-evidence</code> or <code>ext-evidence</code>, multiple values within the attribute or extension, and finally, by including multiple <code>EvidenceStatement</code> structures within an <code>EvidenceBundle</code>. The latter is the preferred way to carry multiple Evidence statements. Implementations <span class="bcp14">MUST NOT</span> place multiple copies of <code>attr-evidence</code> into a PKCS#10 CSR due to the <code>COUNTS MAX 1</code> declaration. In a CRMF CSR, implementers <span class="bcp14">SHOULD NOT</span> place multiple copies of <code>ext-evidence</code>.<a href="#section-5.2-19" class="pilcrow">¶</a></p>
+<p id="section-5.2-19">The Extension variant illustrated in <a href="#code-extensions" class="auto internal xref">Figure 11</a> is intended only for use within CRMF CSRs and is <span class="bcp14">NOT RECOMMENDED</span> to be used within X.509 certificates due to the privacy implications of publishing Evidence about the end entity's hardware environment. See <a href="#sec-con-publishing-x509" class="auto internal xref">Section 8.3</a> for more discussion.<a href="#section-5.2-19" class="pilcrow">¶</a></p>
+<p id="section-5.2-20">By the nature of the PKIX ASN.1 classes <span>[<a href="#RFC5912" class="cite xref">RFC5912</a>]</span>, there are multiple ways to convey multiple Evidence statements: by including multiple copies of <code>attr-evidence</code> or <code>ext-evidence</code>, multiple values within the attribute or extension, and finally, by including multiple <code>EvidenceStatement</code> structures within an <code>EvidenceBundle</code>. The latter is the preferred way to carry multiple Evidence statements. Implementations <span class="bcp14">MUST NOT</span> place multiple copies of <code>attr-evidence</code> into a PKCS#10 CSR due to the <code>COUNTS MAX 1</code> declaration. In a CRMF CSR, implementers <span class="bcp14">SHOULD NOT</span> place multiple copies of <code>ext-evidence</code>.<a href="#section-5.2-20" class="pilcrow">¶</a></p>
 </section>
 </div>
 </section>

hannestschofenig-patch-3/draft-ietf-lamps-csr-attestation.txt

@@ -5,14 +5,14 @@
 Network Working Group                                       M. Ounsworth
 Internet-Draft                                                   Entrust
 Intended status: Standards Track                           H. Tschofenig
-Expires: 17 August 2025                                          Siemens
+Expires: 31 August 2025                                          Siemens
                                                              H. Birkholz
                                                           Fraunhofer SIT
                                                               M. Wiseman
                                                          Beyond Identity
                                                                 N. Smith
                                                        Intel Corporation
-                                                        13 February 2025
+                                                        27 February 2025
 
 
      Use of Remote Attestation with Certification Signing Requests
@@ -65,7 +65,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 17 August 2025.
+   This Internet-Draft will expire on 31 August 2025.
 
 Copyright Notice
 
@@ -594,6 +594,12 @@ Table of Contents
    a valid server name might be "verifier.example.com" or
    "verifier.example.com:8443", but not "[email protected]".
 
+   Relying Parties SHOULD NOT connect to a host name provided in the
+   hint, especially if the verifier has no previous trust relationship
+   with that host name, instead this SHOULD be used only as a lookup
+   string for determining between a list of Verifiers that the Relying
+   Party is pre-configured to use.
+
    In a typical usage scenario, the Relying Party is pre-configured with
    a list of trusted Verifiers and the corresponding hint values can be
    used to look up appropriate Verifier.  The Relying Party is also