Skip to content

Commit

Permalink
Script updating gh-pages from 1f7dffa. [ci skip]
Browse files Browse the repository at this point in the history
  • Loading branch information
ID Bot committed Jan 1, 2025
1 parent 3da7ab5 commit c9c2e80
Show file tree
Hide file tree
Showing 2 changed files with 128 additions and 36 deletions.
56 changes: 39 additions & 17 deletions passport/draft-ietf-lamps-csr-attestation.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -1056,11 +1056,11 @@
<thead><tr>
<td class="left">Internet-Draft</td>
<td class="center">Remote Attestation with CSRs</td>
<td class="right">December 2024</td>
<td class="right">January 2025</td>
</tr></thead>
<tfoot><tr>
<td class="left">Ounsworth, et al.</td>
<td class="center">Expires 2 July 2025</td>
<td class="center">Expires 5 July 2025</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
Expand All @@ -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="2024-12-29" class="published">29 December 2024</time>
<time datetime="2025-01-01" class="published">1 January 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-07-02">2 July 2025</time></dd>
<dd class="expires"><time datetime="2025-07-05">5 July 2025</time></dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
Expand Down Expand Up @@ -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 2 July 2025.<a href="#section-boilerplate.1-4" class="pilcrow"></a></p>
This Internet-Draft will expire on 5 July 2025.<a href="#section-boilerplate.1-4" class="pilcrow"></a></p>
</section>
</div>
<div id="copyright">
Expand All @@ -1151,7 +1151,7 @@ <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
</h2>
<p id="section-boilerplate.2-1">
Copyright (c) 2024 IETF Trust and the persons identified as the
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow"></a></p>
<p id="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Expand Down Expand Up @@ -1259,10 +1259,10 @@ <h2 id="name-copyright-notice">
<p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="auto internal xref">8.1</a>.  <a href="#name-background-check-model-secu" class="internal xref">Background Check Model Security Considerations</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.2">
<p id="section-toc.1-1.8.2.2.1"><a href="#section-8.2" class="auto internal xref">8.2</a>.  <a href="#name-freshness" class="internal xref">Freshness</a></p>
<p id="section-toc.1-1.8.2.2.1"><a href="#section-8.2" class="auto internal xref">8.2</a>.  <a href="#name-freshness-for-the-backgroun" class="internal xref">Freshness for the Background Check Model</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.3">
<p id="section-toc.1-1.8.2.3.1"><a href="#section-8.3" class="auto internal xref">8.3</a>.  <a href="#name-publishing-evidence-in-an-x" class="internal xref">Publishing Evidence in an X.509 extension</a></p>
<p id="section-toc.1-1.8.2.3.1"><a href="#section-8.3" class="auto internal xref">8.3</a>.  <a href="#name-publishing-evidence-in-an-x" class="internal xref">Publishing Evidence in an X.509 Extension</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.4">
<p id="section-toc.1-1.8.2.4.1"><a href="#section-8.4" class="auto internal xref">8.4</a>.  <a href="#name-type-oid-and-verifier-hint" class="internal xref">Type OID and verifier hint</a></p>
Expand Down Expand Up @@ -2467,6 +2467,20 @@ <h4 id="name-initial-registry-contents">
<h2 id="name-security-considerations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
</h2>
<p id="section-8-1">In the RATS architecture, when Evidence or an Attestation Result is presented to a Relying Party (RP), the RP may learn detailed information about the Attester unless that information has been redacted or encrypted. Consequently, a certain amount of trust must be placed in the RP, which raises potential privacy concerns because an RP could be used to track devices. This observation is noted in Section 11 of <span>[<a href="#RFC9334" class="cite xref">RFC9334</a>]</span>.<a href="#section-8-1" class="pilcrow"></a></p>
<p id="section-8-2">Typically, the RPs considered in the RATS architecture are application services that use remote attestation, rather than RAs or CAs. Devices inherently place significant trust in RA/CA infrastructure elements, and therefore any additional information revealed through remote attestation to such entities is generally less concerning than disclosure to application services. The problem of copying Evidence by CAs into an X.509 certificate is discussed in <a href="#sec-con-publishing-x509" class="auto internal xref">Section 8.3</a>.<a href="#section-8-2" class="pilcrow"></a></p>
<p id="section-8-3">These privacy risks can be mitigated using several approaches, including:<a href="#section-8-3" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="section-8-4.1">
<p id="section-8-4.1.1">Shared Attestation Keys: A manufacturer of devices may provision all devices with the same attestation key(s), or share a common attestation key across devices of the same product family. This approach anonymizes individual devices by making them indistinguishable from others using the same key(s). However, it also means losing the ability to revoke a single attestation key if a specific device is compromised. Care must be taken to avoid embedding uniquely identifying information in the Evidence, as that would reduce the privacy benefits of using remote attestation.<a href="#section-8-4.1.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-8-4.2">
<p id="section-8-4.2.1">Per-Device Attestation Keys: Devices may be designed to dynamically generate distinct attestation keys (and request the corresponding certificates) for each use case, device, or session. This is analogous to the Privacy CA model, in which a device is initially provisioned with an attestation key and certificate; then, in conjunction with a privacy-preserving CA, it can obtain unique keys and certificates as needed. This strategy reduces the potential for tracking while maintaining strong security assurances. This is the model described in this document.<a href="#section-8-4.2.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-8-4.3">
<p id="section-8-4.3.1">Anonymous Attestation Mechanisms: Direct anonymous attestation (DAA) or similar cryptographic methods can be employed to generate blinded attestation signatures. In these schemes, the verifier can validate the attestation using a root key but does not gain a global correlation handle. Thus, repeated use of the same attestation key cannot be exploited to track devices. <span>[<a href="#I-D.ietf-rats-daa" class="cite xref">I-D.ietf-rats-daa</a>]</span> extends the RATS architecture with such a DAA scheme, significantly enhancing privacy.<a href="#section-8-4.3.1" class="pilcrow"></a></p>
</li>
</ul>
<div id="background-check-model-security-considerations">
<section id="section-8.1">
<h3 id="name-background-check-model-secu">
Expand Down Expand Up @@ -2611,23 +2625,22 @@ <h3 id="name-background-check-model-secu">
require the use of Evidence in a CSR is out-of-scope for this document.<a href="#section-8.1-8" class="pilcrow"></a></p>
</section>
</div>
<div id="freshness">
<div id="freshness-for-the-background-check-model">
<section id="section-8.2">
<h3 id="name-freshness">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-freshness" class="section-name selfRef">Freshness</a>
<h3 id="name-freshness-for-the-backgroun">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-freshness-for-the-backgroun" class="section-name selfRef">Freshness for the Background Check Model</a>
</h3>
<p id="section-8.2-1">Evidence generated by an Attester generally needs to be fresh to provide
value to the Verifier since the configuration on the device may change
over time. <span><a href="https://rfc-editor.org/rfc/rfc9334#section-10" class="relref">Section 10</a> of [<a href="#RFC9334" class="cite xref">RFC9334</a>]</span> discusses different approaches for
providing freshness, including a nonce-based approach, the use of timestamps
and an epoch-based technique. The use of nonces requires that nonce to be provided by
and an epoch-based technique. The use of nonces requires that nonce to be provided by
the Relying Party in some protocol step prior to Evidence and CSR generation,
and the use of timestamps requires synchronized clocks which cannot be
guaranteed in all operating environments. Epochs also require an out-of-band
communication channel.
This document only specifies how to carry existing Evidence formats inside a CSR,
and so issues of synchronizing freshness data is left to be handled, for example,
via certificate management protocols.
This document leaves the exchange of nonces and other freshness data to
certificate management protocols, see <span>[<a href="#I-D.ietf-lamps-attestation-freshness" class="cite xref">I-D.ietf-lamps-attestation-freshness</a>]</span>.
Developers, operators, and designers of protocols, which embed
Evidence-carrying-CSRs, <span class="bcp14">MUST</span> consider what notion of freshness is
appropriate and available in-context; thus the issue of freshness is
Expand All @@ -2644,12 +2657,13 @@ <h3 id="name-freshness">
time T to have been generated inside the hardware boundary and to be
non-exportable, then it can be assumed that those properties of that key
will continue to hold into the future.<a href="#section-8.2-2" class="pilcrow"></a></p>
<p id="section-8.2-3">Note: Freshness is also a concern for remote attestation in the passport model; however, the protocol between the Attester and the Verifier lies outside the scope of this specification.<a href="#section-8.2-3" class="pilcrow"></a></p>
</section>
</div>
<div id="sec-con-publishing-x509">
<section id="section-8.3">
<h3 id="name-publishing-evidence-in-an-x">
<a href="#section-8.3" class="section-number selfRef">8.3. </a><a href="#name-publishing-evidence-in-an-x" class="section-name selfRef">Publishing Evidence in an X.509 extension</a>
<a href="#section-8.3" class="section-number selfRef">8.3. </a><a href="#name-publishing-evidence-in-an-x" class="section-name selfRef">Publishing Evidence in an X.509 Extension</a>
</h3>
<p id="section-8.3-1">This document specifies an Extension for carrying Evidence in a CRMF Certificate Signing Request (CSR), but it is intentionally <span class="bcp14">NOT RECOMMENDED</span> for a CA to copy the ext-evidence extension into the published certificate.
The reason for this is that certificates are considered public information and the Evidence might contain detailed information about hardware and patch levels of the device on which the private key resides.
Expand All @@ -2674,7 +2688,7 @@ <h3 id="name-type-oid-and-verifier-hint">
<h3 id="name-additional-security-conside">
<a href="#section-8.5" class="section-number selfRef">8.5. </a><a href="#name-additional-security-conside" class="section-name selfRef">Additional Security Considerations</a>
</h3>
<p id="section-8.5-1">In addition to the security considerations listed here, implementers should be familiar with the security considerations of the specifications on this this depends: PKCS#10 <span>[<a href="#RFC2986" class="cite xref">RFC2986</a>]</span>, CRMF <span>[<a href="#RFC4211" class="cite xref">RFC4211</a>]</span>, as well as general security concepts relating to evidence and remote attestation; many of these concepts are discussed in <span><a href="https://rfc-editor.org/rfc/rfc9334#section-6" class="relref">Section 6</a> of [<a href="#RFC9334" class="cite xref">RFC9334</a>]</span>, <span><a href="https://rfc-editor.org/rfc/rfc9334#section-7" class="relref">Section 7</a> of [<a href="#RFC9334" class="cite xref">RFC9334</a>]</span>, <span><a href="https://rfc-editor.org/rfc/rfc9334#section-9" class="relref">Section 9</a> of [<a href="#RFC9334" class="cite xref">RFC9334</a>]</span>, <span><a href="https://rfc-editor.org/rfc/rfc9334#section-11" class="relref">Section 11</a> of [<a href="#RFC9334" class="cite xref">RFC9334</a>]</span>, and <span><a href="https://rfc-editor.org/rfc/rfc9334#section-12" class="relref">Section 12</a> of [<a href="#RFC9334" class="cite xref">RFC9334</a>]</span>. Implementers should also be aware of any security considerations relating to the specific evidence format being carried within the CSR.<a href="#section-8.5-1" class="pilcrow"></a></p>
<p id="section-8.5-1">In addition to the security considerations listed here, implementers should be familiar with the security considerations of the specifications on this this depends: PKCS#10 <span>[<a href="#RFC2986" class="cite xref">RFC2986</a>]</span>, CRMF <span>[<a href="#RFC4211" class="cite xref">RFC4211</a>]</span>, as well as general security concepts relating to remote attestation; many of these concepts are discussed in <span><a href="https://rfc-editor.org/rfc/rfc9334#section-6" class="relref">Section 6</a> of [<a href="#RFC9334" class="cite xref">RFC9334</a>]</span>, <span><a href="https://rfc-editor.org/rfc/rfc9334#section-7" class="relref">Section 7</a> of [<a href="#RFC9334" class="cite xref">RFC9334</a>]</span>, <span><a href="https://rfc-editor.org/rfc/rfc9334#section-9" class="relref">Section 9</a> of [<a href="#RFC9334" class="cite xref">RFC9334</a>]</span>, <span><a href="https://rfc-editor.org/rfc/rfc9334#section-11" class="relref">Section 11</a> of [<a href="#RFC9334" class="cite xref">RFC9334</a>]</span>, and <span><a href="https://rfc-editor.org/rfc/rfc9334#section-12" class="relref">Section 12</a> of [<a href="#RFC9334" class="cite xref">RFC9334</a>]</span>. Implementers should also be aware of any security considerations relating to the specific Evidence and Attestation Result formats being carried within the CSR.<a href="#section-8.5-1" class="pilcrow"></a></p>
</section>
</div>
</section>
Expand Down Expand Up @@ -2743,10 +2757,18 @@ <h3 id="name-informative-references">
<dd>
<span class="refAuthor">Brossard, M.</span>, <span class="refAuthor">Fossati, T.</span>, <span class="refAuthor">Tschofenig, H.</span>, and <span class="refAuthor">H. Birkholz</span>, <span class="refTitle">"An EAT-based Key Attestation Token"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-bft-rats-kat-05</span>, <time datetime="2024-11-21" class="refDate">21 November 2024</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-bft-rats-kat-05">https://datatracker.ietf.org/doc/html/draft-bft-rats-kat-05</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-lamps-attestation-freshness">[I-D.ietf-lamps-attestation-freshness]</dt>
<dd>
<span class="refAuthor">Tschofenig, H.</span> and <span class="refAuthor">H. Brockhaus</span>, <span class="refTitle">"Nonce-based Freshness for Remote Attestation in Certificate Signing Requests (CSRs) for the Certification Management Protocol (CMP) and for Enrollment over Secure Transport (EST)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-lamps-attestation-freshness-03</span>, <time datetime="2024-11-05" class="refDate">5 November 2024</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-lamps-attestation-freshness-03">https://datatracker.ietf.org/doc/html/draft-ietf-lamps-attestation-freshness-03</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-rats-ar4si">[I-D.ietf-rats-ar4si]</dt>
<dd>
<span class="refAuthor">Voit, E.</span>, <span class="refAuthor">Birkholz, H.</span>, <span class="refAuthor">Hardjono, T.</span>, <span class="refAuthor">Fossati, T.</span>, and <span class="refAuthor">V. Scarlata</span>, <span class="refTitle">"Attestation Results for Secure Interactions"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-rats-ar4si-07</span>, <time datetime="2024-09-02" class="refDate">2 September 2024</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-rats-ar4si-07">https://datatracker.ietf.org/doc/html/draft-ietf-rats-ar4si-07</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-rats-daa">[I-D.ietf-rats-daa]</dt>
<dd>
<span class="refAuthor">Birkholz, H.</span>, <span class="refAuthor">Newton, C.</span>, <span class="refAuthor">Chen, L.</span>, and <span class="refAuthor">D. Thaler</span>, <span class="refTitle">"Direct Anonymous Attestation for the Remote Attestation Procedures Architecture"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-rats-daa-06</span>, <time datetime="2024-09-05" class="refDate">5 September 2024</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-rats-daa-06">https://datatracker.ietf.org/doc/html/draft-ietf-rats-daa-06</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-rats-msg-wrap">[I-D.ietf-rats-msg-wrap]</dt>
<dd>
<span class="refAuthor">Birkholz, H.</span>, <span class="refAuthor">Smith, N.</span>, <span class="refAuthor">Fossati, T.</span>, <span class="refAuthor">Tschofenig, H.</span>, and <span class="refAuthor">D. Glaze</span>, <span class="refTitle">"RATS Conceptual Messages Wrapper (CMW)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-rats-msg-wrap-11</span>, <time datetime="2024-11-15" class="refDate">15 November 2024</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-rats-msg-wrap-11">https://datatracker.ietf.org/doc/html/draft-ietf-rats-msg-wrap-11</a>&gt;</span>. </dd>
Expand Down
Loading

0 comments on commit c9c2e80

Please sign in to comment.