Skip to content

Commit

Permalink
Script updating gh-pages from 0fb725a. [ci skip]
Browse files Browse the repository at this point in the history
  • Loading branch information
ID Bot committed Feb 1, 2024
1 parent 0b85e6f commit 86b877a
Show file tree
Hide file tree
Showing 2 changed files with 35 additions and 14 deletions.
23 changes: 16 additions & 7 deletions draft-vesco-vcauthtls.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -1029,11 +1029,11 @@
<thead><tr>
<td class="left">Internet-Draft</td>
<td class="center">TODO - Abbreviation</td>
<td class="right">January 2024</td>
<td class="right">February 2024</td>
</tr></thead>
<tfoot><tr>
<td class="left">Vesco &amp; Perugini</td>
<td class="center">Expires 2 August 2024</td>
<td class="center">Expires 4 August 2024</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
Expand All @@ -1046,12 +1046,12 @@
<dd class="internet-draft">draft-vesco-vcauthtls-latest</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2024-01-30" class="published">30 January 2024</time>
<time datetime="2024-02-01" class="published">1 February 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="2024-08-02">2 August 2024</time></dd>
<dd class="expires"><time datetime="2024-08-04">4 August 2024</time></dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
Expand Down Expand Up @@ -1104,7 +1104,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 August 2024.<a href="#section-boilerplate.1-4" class="pilcrow"></a></p>
This Internet-Draft will expire on 4 August 2024.<a href="#section-boilerplate.1-4" class="pilcrow"></a></p>
</section>
</div>
<div id="copyright">
Expand Down Expand Up @@ -1657,7 +1657,8 @@ <h2 id="name-security-considerations">
<p id="section-7-1">All the security considerations presented in <span>[<a href="#RFC8446" class="cite xref">RFC8446</a>]</span> applies to this document as well.
Further considerations can be made on the DID resolution process. Assuming that a DID resolution is performed in clear, a man-in-the-middle could impersonate the DLT node, forge a DID Document containing the authenticating endpoint's DID, associate it with a key pair that he owns, and then return it to the DID resolver. Thus, the attacker is able to compute a valid CertificateVerify message by possessing the long term private key. In practice, the man-in-the-middle attacker breaks in transit the immutability feature provided by the DLT, i.e. the RoT for the public keys.
A possible solution to this attack is to esthablish a TLS channel towards the DLT node and authenticate only the latter to rely on the received data. The DLT node <span class="bcp14">MUST</span> be authenticated through an X.509 certificate. The session resumption and 0 round-trip time (0-RTT) features of TLS 1.3 can be used to reduce the overhead of establishing this TLS channel.
In addition, since confidentiality is not a requirement for DID resolution, another solution is to configure the DLT node to sign the replies such that the DID resolver can verify the origin and the integrity of the data received.<a href="#section-7-1" class="pilcrow"></a></p>
In addition, the communication with the DLT node can be protected with Internet Protocol Security
(IPsec) <span>[<a href="#RFC6071" class="cite xref">RFC6071</a>]</span> and Internet Key Exchange (IKE) <span>[<a href="#RFC5996" class="cite xref">RFC5996</a>]</span> in endpoint-to-endpoint transport mode for even better performance in term of latency of DID resolution.<a href="#section-7-1" class="pilcrow"></a></p>
</section>
</div>
<div id="iana-considerations">
Expand All @@ -1682,6 +1683,14 @@ <h3 id="name-normative-references">
<dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc2119">https://www.rfc-editor.org/rfc/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5996">[RFC5996]</dt>
<dd>
<span class="refAuthor">Kaufman, C.</span>, <span class="refAuthor">Hoffman, P.</span>, <span class="refAuthor">Nir, Y.</span>, and <span class="refAuthor">P. Eronen</span>, <span class="refTitle">"Internet Key Exchange Protocol Version 2 (IKEv2)"</span>, <span class="seriesInfo">RFC 5996</span>, <span class="seriesInfo">DOI 10.17487/RFC5996</span>, <time datetime="2010-09" class="refDate">September 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc5996">https://www.rfc-editor.org/rfc/rfc5996</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6071">[RFC6071]</dt>
<dd>
<span class="refAuthor">Frankel, S.</span> and <span class="refAuthor">S. Krishnan</span>, <span class="refTitle">"IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap"</span>, <span class="seriesInfo">RFC 6071</span>, <span class="seriesInfo">DOI 10.17487/RFC6071</span>, <time datetime="2011-02" class="refDate">February 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc6071">https://www.rfc-editor.org/rfc/rfc6071</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7250">[RFC7250]</dt>
<dd>
<span class="refAuthor">Wouters, P., Ed.</span>, <span class="refAuthor">Tschofenig, H., Ed.</span>, <span class="refAuthor">Gilmore, J.</span>, <span class="refAuthor">Weiler, S.</span>, and <span class="refAuthor">T. Kivinen</span>, <span class="refTitle">"Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"</span>, <span class="seriesInfo">RFC 7250</span>, <span class="seriesInfo">DOI 10.17487/RFC7250</span>, <time datetime="2014-06" class="refDate">June 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc7250">https://www.rfc-editor.org/rfc/rfc7250</a>&gt;</span>. </dd>
Expand Down Expand Up @@ -1728,7 +1737,7 @@ <h3 id="name-informative-references">
<h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
</h2>
<p id="appendix-A-1">We would like to thank Nicola Tuveri for his very helpful suggestions in the preparation of the first version of this document.<a href="#appendix-A-1" class="pilcrow"></a></p>
<p id="appendix-A-1">We would like to thank Nicola Tuveri for his very helpful suggestions during the preparation of the first version of this technical specification.<a href="#appendix-A-1" class="pilcrow"></a></p>
</section>
</div>
<div id="authors-addresses">
Expand Down
26 changes: 19 additions & 7 deletions draft-vesco-vcauthtls.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@
WG A. Vesco
Internet-Draft L. Perugini
Intended status: Standards Track LINKS Foundation
Expires: 2 August 2024 30 January 2024
Expires: 4 August 2024 1 February 2024


Transport Layer Security (TLS) Authentication with Verifiable Credential
Expand Down Expand Up @@ -53,7 +53,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 2 August 2024.
This Internet-Draft will expire on 4 August 2024.

Copyright Notice

Expand Down Expand Up @@ -612,10 +612,11 @@ Figure 1: Generation of the identity compliant with the SSI model and
on the received data. The DLT node MUST be authenticated through an
X.509 certificate. The session resumption and 0 round-trip time
(0-RTT) features of TLS 1.3 can be used to reduce the overhead of
establishing this TLS channel. In addition, since confidentiality is
not a requirement for DID resolution, another solution is to
configure the DLT node to sign the replies such that the DID resolver
can verify the origin and the integrity of the data received.
establishing this TLS channel. In addition, the communication with
the DLT node can be protected with Internet Protocol Security (IPsec)
[RFC6071] and Internet Key Exchange (IKE) [RFC5996] in endpoint-to-
endpoint transport mode for even better performance in term of
latency of DID resolution.

8. IANA Considerations

Expand All @@ -630,6 +631,16 @@ Figure 1: Generation of the identity compliant with the SSI model and
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.

[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, DOI 10.17487/RFC5996, September 2010,
<https://www.rfc-editor.org/rfc/rfc5996>.

[RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and
Internet Key Exchange (IKE) Document Roadmap", RFC 6071,
DOI 10.17487/RFC6071, February 2011,
<https://www.rfc-editor.org/rfc/rfc6071>.

[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport
Expand Down Expand Up @@ -662,7 +673,8 @@ Figure 1: Generation of the identity compliant with the SSI model and
Acknowledgments

We would like to thank Nicola Tuveri for his very helpful suggestions
in the preparation of the first version of this document.
during the preparation of the first version of this technical
specification.

Authors' Addresses

Expand Down

0 comments on commit 86b877a

Please sign in to comment.