This looks like an improvement to me. Russ
> On Apr 29, 2025, at 9:48 AM, Douglas Gash (dcmgash) <[email protected]> wrote: > > Dear OPSAWG et al, > > We would like to extend an offline discussion onto the group regarding the > use of wildcards for identities in server certificates. The document > currently prohibits them; however, they are supported in the specific TLS 1.3 > specifications and the case has been made that they are useful. Rather than > prohibiting them, we consider we would be better serving the operators by > instead mentioning the risk and guiding the circumstance that they may be > used. > > For this reason, we are planning to make the following late change, and would > welcome feedback of the group. > > Many thanks. > > 3.4.2. TLS Certificate Identification > > OLD TEXT: > > For the client-side validation of presented TLS TACACS+ server > identities, implementations MUST follow [RFC9525] validation > techniques. Identifier types DNS-ID, IP-ID, or SRV-ID are applicable > for use with the TLS TACACS+ protocol, selected by operators > depending upon the deployment design. TLS TACACS+ does not use URI- > IDs for TLS TACACS+ server identity verification. The wildcard > character MUST NOT be included in the presented TLS TACACS+ server > identities. > > PROPOSED NEW TEXT: > > For the client-side validation of presented TLS TACACS+ server > identities, implementations MUST follow [RFC9525] validation > techniques. Identifier types DNS-ID, IP-ID, or SRV-ID are applicable > for use with the TLS TACACS+ protocol, selected by operators > depending upon the deployment design. TLS TACACS+ does not use URI- > IDs for TLS TACACS+ server identity verification. > > Wildcards in TLS TACACS+ server identities simplify certificate > management by allowing a single certificate to secure multiple > servers in a deployment. However, this introduces security risks, as > compromising the private key of a wildcard certificate impacts all > servers using it. To address these risks, the guidelines in > Section 6.3 of [RFC9525] MUST be followed, and the wildcard > SHOULD be confined to a subdomain dedicated solely to > TLS TACACS+ servers. > > > > From: [email protected] <mailto:[email protected]> > <[email protected] <mailto:[email protected]>> > Date: Sunday, 13 April 2025 at 14:01 > To: [email protected] <mailto:[email protected]> <[email protected] > <mailto:[email protected]>> > Subject: OPSAWG Digest, Vol 215, Issue 45 > > Send OPSAWG mailing list submissions to > [email protected] <mailto:[email protected]> > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > [email protected] <mailto:[email protected]> > > You can reach the person managing the list at > [email protected] <mailto:[email protected]> > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OPSAWG digest..." > > Today's Topics: > > 1. I-D Action: draft-ietf-opsawg-tacacs-tls13-20.txt > ([email protected] <mailto:[email protected]>) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 13 Apr 2025 04:21:28 -0700 > From: [email protected] <mailto:[email protected]> > Subject: [OPSAWG]I-D Action: draft-ietf-opsawg-tacacs-tls13-20.txt > To: <[email protected] <mailto:[email protected]>> > Cc: [email protected] <mailto:[email protected]> > Message-ID: <174454328813.1077590.13779907431627152512@dt-datatracker- > 64c5c9b5f9-hz6qg> > Content-Type: text/plain; charset="utf-8" > > Internet-Draft draft-ietf-opsawg-tacacs-tls13-20.txt is now available. It is a > work item of the Operations and Management Area Working Group (OPSAWG) WG of > the IETF. > > Title: Terminal Access Controller Access-Control System Plus over TLS > 1.3 (TACACS+ over TLS) > Authors: Thorsten Dahm > John Heasley > Douglas C. Medway Gash > Andrej Ota > Name: draft-ietf-opsawg-tacacs-tls13-20.txt > Pages: 17 > Dates: 2025-04-13 > > Abstract: > > The Terminal Access Controller Access-Control System Plus (TACACS+) > protocol provides device administration for routers, network access > servers, and other networked computing devices via one or more > centralized TACACS+ servers. This document adds Transport Layer > Security (TLS 1.3) support to TACACS+ and obsoletes former inferior > security mechanisms. > > This document updates RFC 8907. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-tls13/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-opsawg-tacacs-tls13-20.html > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-tacacs-tls13-20 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org <http://rsync.ietf.org/>::internet-drafts > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OPSAWG mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]> > > > ------------------------------ > > End of OPSAWG Digest, Vol 215, Issue 45 > ***************************************
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
