From 7954491edc9ac3a738a62dcd9a91df664d0412be Mon Sep 17 00:00:00 2001 From: ID Bot Date: Sun, 9 Jun 2024 00:40:39 +0000 Subject: [PATCH] Script updating gh-pages from ac6154e. [ci skip] --- js-mtls-1/draft-sheffer-wimse-s2s-protocol.html | 8 ++++++-- js-mtls-1/draft-sheffer-wimse-s2s-protocol.txt | 6 +++++- 2 files changed, 11 insertions(+), 3 deletions(-) diff --git a/js-mtls-1/draft-sheffer-wimse-s2s-protocol.html b/js-mtls-1/draft-sheffer-wimse-s2s-protocol.html index 7f0cffb..d715693 100644 --- a/js-mtls-1/draft-sheffer-wimse-s2s-protocol.html +++ b/js-mtls-1/draft-sheffer-wimse-s2s-protocol.html @@ -1373,7 +1373,7 @@

4.1. Host Name Validation

[TODO: the following paragraph needs better alignment with RFC 9525. The following is a very drafty straw man]

-

WIMSE clients MUST validate that the trust domain portion of the WIMSE certificate matches the expected trust domain for the server side of the connection. It is also RECOMMENDED that the client match the WIMSE identity in the certificate against the WIMSE identity of the workload of the intended server. In this case the trust domain portion of the URI is NOT treated as a host name as specified section 6.4 of RFC 9525 but rather as a trust domain, the server identity is encoded in the path portion of the WIMSE identity in a deployment specific way.

+

WIMSE clients MUST validate that the trust domain portion of the WIMSE certificate matches the expected trust domain for the server side of the connection. It is also RECOMMENDED that the client match the WIMSE identity in the certificate against the WIMSE identity of the workload of the intended server. In this case the trust domain portion of the URI is NOT treated as a host name as specified section 6.4 of [RFC9525] but rather as a trust domain, the server identity is encoded in the path portion of the WIMSE identity in a deployment specific way.

In some cases the WIMSE client may connect to the server using a DNS host name in which case the client MUST perform host name validation as defined in 6.3 in RFC 9525.

@@ -1424,9 +1424,13 @@

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9421]
-
+
Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, , <https://www.rfc-editor.org/rfc/rfc9421>.
+
[RFC9525]
+
+Saint-Andre, P. and R. Salz, "Service Identity in TLS", RFC 9525, DOI 10.17487/RFC9525, , <https://www.rfc-editor.org/rfc/rfc9525>.
+
diff --git a/js-mtls-1/draft-sheffer-wimse-s2s-protocol.txt b/js-mtls-1/draft-sheffer-wimse-s2s-protocol.txt index 73829e6..ecab9d1 100644 --- a/js-mtls-1/draft-sheffer-wimse-s2s-protocol.txt +++ b/js-mtls-1/draft-sheffer-wimse-s2s-protocol.txt @@ -224,7 +224,7 @@ Table of Contents the WIMSE identity in the certificate against the WIMSE identity of the workload of the intended server. In this case the trust domain portion of the URI is NOT treated as a host name as specified section - 6.4 of RFC 9525 but rather as a trust domain, the server identity is + 6.4 of [RFC9525] but rather as a trust domain, the server identity is encoded in the path portion of the WIMSE identity in a deployment specific way. @@ -274,6 +274,10 @@ Table of Contents Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, . + [RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS", + RFC 9525, DOI 10.17487/RFC9525, November 2023, + . + 7.2. Informative References [I-D.ietf-wimse-arch]