Skip to content

Commit

Permalink
Script updating gh-pages from b038860. [ci skip]
Browse files Browse the repository at this point in the history
  • Loading branch information
ID Bot committed Jul 18, 2024
1 parent 611e649 commit 823f7e5
Show file tree
Hide file tree
Showing 2 changed files with 91 additions and 59 deletions.
95 changes: 56 additions & 39 deletions draft-vesco-vcauthtls.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -10,26 +10,25 @@
<meta content="
This document defines a new certificate type and extension for the exchange of Verifiable Credentials in the handshake of the Transport Layer Security (TLS) protocol. The new certificate type is intended to add the Verifiable Credentials as a new means of authentication. The resulting authentication process leverages a distributed ledger as the root of trust of the TLS endpoints' public keys. The endpoints can use different distributed ledger technologies to store their public keys and to perform the TLS handshake.
" name="description">
<meta content="xml2rfc 3.19.2" name="generator">
<meta content="xml2rfc 3.22.0" name="generator">
<meta content="TLS" name="keyword">
<meta content="VC" name="keyword">
<meta content="DID" name="keyword">
<meta content="DLT" name="keyword">
<meta content="draft-vesco-vcauthtls-latest" name="ietf.draft">
<!-- Generator version information:
xml2rfc 3.19.2
Python 3.11.6
xml2rfc 3.22.0
Python 3.12.3
ConfigArgParse 1.7
google-i18n-address 3.1.0
intervaltree 3.1.0
Jinja2 3.1.2
lxml 4.9.3
platformdirs 4.2.0
Jinja2 3.1.4
lxml 4.9.4
platformdirs 4.2.2
pycountry 22.3.5
PyYAML 6.0.1
requests 2.31.0
setuptools 68.2.2
six 1.16.0
requests 2.32.3
setuptools 69.5.1
wcwidth 0.2.13
-->
<link href="draft-vesco-vcauthtls.xml" rel="alternate" type="application/rfc+xml">
Expand Down Expand Up @@ -1029,11 +1028,11 @@
<thead><tr>
<td class="left">Internet-Draft</td>
<td class="center">TLS Auth with VC</td>
<td class="right">February 2024</td>
<td class="right">July 2024</td>
</tr></thead>
<tfoot><tr>
<td class="left">Vesco &amp; Perugini</td>
<td class="center">Expires 19 August 2024</td>
<td class="center">Expires 19 January 2025</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
Expand All @@ -1046,12 +1045,12 @@
<dd class="internet-draft">draft-vesco-vcauthtls-latest</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2024-02-16" class="published">16 February 2024</time>
<time datetime="2024-07-18" class="published">18 July 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-19">19 August 2024</time></dd>
<dd class="expires"><time datetime="2025-01-19">19 January 2025</time></dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
Expand Down Expand Up @@ -1099,7 +1098,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 19 August 2024.<a href="#section-boilerplate.1-4" class="pilcrow"></a></p>
This Internet-Draft will expire on 19 January 2025.<a href="#section-boilerplate.1-4" class="pilcrow"></a></p>
</section>
</div>
<div id="copyright">
Expand Down Expand Up @@ -1186,24 +1185,27 @@ <h2 id="name-copyright-notice">
<p id="section-toc.1-1.7.1"><a href="#section-7" class="auto internal xref">7</a>.  <a href="#name-security-considerations" class="internal xref">Security Considerations</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8">
<p id="section-toc.1-1.8.1"><a href="#section-8" class="auto internal xref">8</a>.  <a href="#name-iana-considerations" class="internal xref">IANA Considerations</a></p>
<p id="section-toc.1-1.8.1"><a href="#section-8" class="auto internal xref">8</a>.  <a href="#name-privacy-considerations" class="internal xref">Privacy Considerations</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9">
<p id="section-toc.1-1.9.1"><a href="#section-9" class="auto internal xref">9</a>.  <a href="#name-references" class="internal xref">References</a></p>
<p id="section-toc.1-1.9.1"><a href="#section-9" class="auto internal xref">9</a>.  <a href="#name-iana-considerations" class="internal xref">IANA Considerations</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10">
<p id="section-toc.1-1.10.1"><a href="#section-10" class="auto internal xref">10</a>. <a href="#name-references" class="internal xref">References</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.1">
<p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="auto internal xref">9.1</a>.  <a href="#name-normative-references" class="internal xref">Normative References</a></p>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.1">
<p id="section-toc.1-1.10.2.1.1"><a href="#section-10.1" class="auto internal xref">10.1</a>.  <a href="#name-normative-references" class="internal xref">Normative References</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.2">
<p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="auto internal xref">9.2</a>.  <a href="#name-informative-references" class="internal xref">Informative References</a></p>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.2">
<p id="section-toc.1-1.10.2.2.1"><a href="#section-10.2" class="auto internal xref">10.2</a>.  <a href="#name-informative-references" class="internal xref">Informative References</a></p>
</li>
</ul>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10">
<p id="section-toc.1-1.10.1"><a href="#appendix-A" class="auto internal xref"></a><a href="#name-acknowledgments" class="internal xref">Acknowledgments</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11">
<p id="section-toc.1-1.11.1"><a href="#appendix-B" class="auto internal xref"></a><a href="#name-authors-addresses" class="internal xref">Authors' Addresses</a></p>
<p id="section-toc.1-1.11.1"><a href="#appendix-A" class="auto internal xref"></a><a href="#name-acknowledgments" class="internal xref">Acknowledgments</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12">
<p id="section-toc.1-1.12.1"><a href="#appendix-B" class="auto internal xref"></a><a href="#name-authors-addresses" class="internal xref">Authors' Addresses</a></p>
</li>
</ul>
</nav>
Expand Down Expand Up @@ -1339,9 +1341,9 @@ <h2 id="name-did_methods-extension">
<div class="alignLeft art-text artwork" id="section-4-4">
<pre>
enum {
btcr(0),
ethr(1),
iota(2),
name0(0),
name1(1),
name2(2),
..
(65535)
} DIDMethod
Expand Down Expand Up @@ -1653,34 +1655,44 @@ <h2 id="name-security-considerations">
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, 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>
(IPsec) <span>[<a href="#RFC4301" class="cite xref">RFC4301</a>]</span> <span>[<a href="#RFC6071" class="cite xref">RFC6071</a>]</span> and Internet Key Exchange Version 2 (IKEv2) <span>[<a href="#RFC7296" class="cite xref">RFC7296</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">
<div id="privacy-considerations">
<section id="section-8">
<h2 id="name-iana-considerations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
<h2 id="name-privacy-considerations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-privacy-considerations" class="section-name selfRef">Privacy Considerations</a>
</h2>
<p id="section-8-1">To be addressed<a href="#section-8-1" class="pilcrow"></a></p>
<p id="section-8-1">Even though the <code>did_methods</code> extension in the <code>ClientHello</code> message is sent in clear no privacy issues arise as its content is not considered strictly confidential.
However, privacy issues can arise when the client resolves the server's DID on a public DLT node. The DLT node can monitor all the servers a client connects to. This problem disappears when DLT nodes are deployed as an integral part of the IoT system itself.<a href="#section-8-1" class="pilcrow"></a></p>
</section>
</div>
<div id="iana-considerations">
<section id="section-9">
<h2 id="name-iana-considerations">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
</h2>
<p id="section-9-1">To be addressed<a href="#section-9-1" class="pilcrow"></a></p>
</section>
</div>
<div id="sec-combined-references">
<section id="section-10">
<h2 id="name-references">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-references" class="section-name selfRef">References</a>
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-references" class="section-name selfRef">References</a>
</h2>
<div id="sec-normative-references">
<section id="section-9.1">
<section id="section-10.1">
<h3 id="name-normative-references">
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
<a href="#section-10.1" class="section-number selfRef">10.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
</h3>
<dl class="references">
<dt id="RFC2119">[RFC2119]</dt>
<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>
<dt id="RFC4301">[RFC4301]</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>
<span class="refAuthor">Kent, S.</span> and <span class="refAuthor">K. Seo</span>, <span class="refTitle">"Security Architecture for the Internet Protocol"</span>, <span class="seriesInfo">RFC 4301</span>, <span class="seriesInfo">DOI 10.17487/RFC4301</span>, <time datetime="2005-12" class="refDate">December 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc4301">https://www.rfc-editor.org/rfc/rfc4301</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6071">[RFC6071]</dt>
<dd>
Expand All @@ -1690,6 +1702,10 @@ <h3 id="name-normative-references">
<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>
<dd class="break"></dd>
<dt id="RFC7296">[RFC7296]</dt>
<dd>
<span class="refAuthor">Kaufman, C.</span>, <span class="refAuthor">Hoffman, P.</span>, <span class="refAuthor">Nir, Y.</span>, <span class="refAuthor">Eronen, P.</span>, and <span class="refAuthor">T. Kivinen</span>, <span class="refTitle">"Internet Key Exchange Protocol Version 2 (IKEv2)"</span>, <span class="seriesInfo">STD 79</span>, <span class="seriesInfo">RFC 7296</span>, <span class="seriesInfo">DOI 10.17487/RFC7296</span>, <time datetime="2014-10" class="refDate">October 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc7296">https://www.rfc-editor.org/rfc/rfc7296</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
<dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc8174">https://www.rfc-editor.org/rfc/rfc8174</a>&gt;</span>. </dd>
Expand All @@ -1702,9 +1718,9 @@ <h3 id="name-normative-references">
</section>
</div>
<div id="sec-informative-references">
<section id="section-9.2">
<section id="section-10.2">
<h3 id="name-informative-references">
<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
<a href="#section-10.2" class="section-number selfRef">10.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
</h3>
<dl class="references">
<dt id="DID">[DID]</dt>
Expand All @@ -1727,6 +1743,7 @@ <h3 id="name-informative-references">
</section>
</div>
</section>
</div>
<div id="acknowledgments">
<section id="appendix-A">
<h2 id="name-acknowledgments">
Expand Down
55 changes: 35 additions & 20 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: 19 August 2024 16 February 2024
Expires: 19 January 2025 18 July 2024


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

Copyright Notice

Expand Down Expand Up @@ -86,10 +86,11 @@ Table of Contents
6.4. Mutual authentication with Client using X.509 Certificate
and Server using Verifiable Credential
7. Security Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
8. Privacy Considerations
9. IANA Considerations
10. References
10.1. Normative References
10.2. Informative References
Acknowledgments
Authors' Addresses

Expand Down Expand Up @@ -266,9 +267,9 @@ Figure 1: Generation of the identity compliant with the SSI model and
extension is shown below.

enum {
btcr(0),
ethr(1),
iota(2),
name0(0),
name1(1),
name2(2),
..
(65535)
} DIDMethod
Expand Down Expand Up @@ -607,27 +608,36 @@ Figure 1: Generation of the identity compliant with the SSI model and
(0-RTT) features of TLS 1.3 can be used to reduce the overhead of
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.
[RFC4301] [RFC6071] and Internet Key Exchange Version 2 (IKEv2)
[RFC7296] in endpoint-to-endpoint transport mode for even better
performance in term of latency of DID resolution.

8. IANA Considerations
8. Privacy Considerations

Even though the did_methods extension in the ClientHello message is
sent in clear no privacy issues arise as its content is not
considered strictly confidential. However, privacy issues can arise
when the client resolves the server's DID on a public DLT node. The
DLT node can monitor all the servers a client connects to. This
problem disappears when DLT nodes are deployed as an integral part of
the IoT system itself.

9. IANA Considerations

To be addressed

9. References
10. References

9.1. Normative References
10.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
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>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/rfc/rfc4301>.

[RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and
Internet Key Exchange (IKE) Document Roadmap", RFC 6071,
Expand All @@ -640,6 +650,11 @@ Figure 1: Generation of the identity compliant with the SSI model and
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <https://www.rfc-editor.org/rfc/rfc7250>.

[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/rfc/rfc7296>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
Expand All @@ -648,7 +663,7 @@ Figure 1: Generation of the identity compliant with the SSI model and
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.

9.2. Informative References
10.2. Informative References

[DID] W3C, "Decentralized Identifiers (DIDs) v1.0", July 2022,
<https://www.w3.org/TR/did-core/>.
Expand Down

0 comments on commit 823f7e5

Please sign in to comment.