Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace most instances of "WIMSE identity" #59

Merged
merged 2 commits into from
Sep 4, 2024
Merged

Replace most instances of "WIMSE identity" #59

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
f166149
Replace most instances of "WIMSE identity"
Aug 30, 2024
ca0d309
Typo
Aug 30, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions draft-ietf-wimse-s2s-protocol.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -488,22 +488,22 @@ A signed response would be:

The WIMSE workload identity may be carried within an X.509 certificate. The WIMSE workload identity MUST be encoded in a SubjectAltName extension of type URI. There MUST be only one SubjectAltName extension of type URI in a WIMSE certificate. The WIMSE certificate may contain SubjectAltName extensions of other types such as DNSName.

WIMSE identities may be used to validate server and client connections. When validating a WIMSE identity the relying party MUST validate that the CA issuer for the WIMSE identity is authorized to issue certificates for the trust domain of the WIMSE identity in the certificate. Other PKIX path validation rules apply.
WIMSE certificates may be used to secure both server and client connections. When validating a WIMSE certificate, the relying party MUST validate that the CA issuer for the WIMSE certificate is authorized to issue certificates for the trust domain of the WIMSE workload identified by the certificate. Other PKIX path validation rules apply.

Servers wishing to use the WIMSE identity for authorizing the client MUST require client certificate authentication in the TLS handshake. Other methods of post handshake authentication are not specified by this document.
Servers wishing to use the WIMSE certificate for authorizing the client MUST require client certificate authentication in the TLS handshake. Other methods of post handshake authentication are not specified by this document.

WIMSE clients and servers MUST validate that the trust domain portion of the WIMSE certificate matches the expected trust domain for the other side of the connection.

## Host Name Validation

<cref>TODO: need to define trust root used to validate the certificate is appropriate for the trust domain.</cref>

It is RECOMMENDED that the server certificate contain a DNS SAN that the client can use to perform standard host name validation ({{Section 6.3 of RFC9525}}). The client SHOULD also extract the WIMSE identity from the certificate if it is present and validate that the WIMSE trust domain matches the intended trust domain for the server. The client MAY then further use the WIMSE identity in applying authorization policy to the server. If the client does not use the DNS SAN then the client MUST match the WIMSE identity in the certificate against the WIMSE identity of the workload of the intended server according to a locally defined policy. The host portion of the WIMSE URI is NOT treated as a host name as specified in 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.
It is RECOMMENDED that the server certificate contain a DNS SAN that the client can use to perform standard host name validation ({{Section 6.3 of RFC9525}}). The client SHOULD also extract the WIMSE identifier from the certificate if it is present and validate that the WIMSE trust domain matches the intended trust domain for the server. The client MAY then further use the WIMSE identifier in applying authorization policy to the server. If the client does not use the DNS SAN then the client MUST match the WIMSE identifier in the certificate against the WIMSE identity of the workload of the intended server according to a locally defined policy. The host portion of the WIMSE URI is NOT treated as a host name as specified in section 6.4 of {{!RFC9525}} but rather as a trust domain. The server identity is encoded in the path portion of the WIMSE identifier in a deployment specific way.


## Authorization Using the WIMSE Identity

The client or server application may retrieve the WIMSE identity from the TLS layer for use in authorization, accounting and auditing. For example, the full URI may be matched against ACLs and other policy constructs to authorize actions requested by the peer.
The client or server application may retrieve the WIMSE identifier from the TLS layer for use in authorization, accounting and auditing. For example, the full URI may be matched against ACLs and other policy constructs to authorize actions requested by the peer.


# Security Considerations
Expand Down
Loading