I am proposing the following for the security section. Any comments? In
particular, what about the “multiple identifiers” at the last few lines?
Should that go away now? If so, that will have ripple effects. This text is
currently at https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/29
# Security Considerations {#security}
## Wildcard Certificates {#security-wildcards}
Wildcard certificates, those that have an identifier with "\*" as the
left-most DNS label, automatically vouch for any single-label host names
within their domain, but not multiple levels of domains. This can be
convenient for administrators but also poses the risk of vouching for rogue
or buggy hosts. See for example {{Defeating-SSL}} (beginning at slide 91) and
{{HTTPSbytes}} (slides 38-40).
Protection against a wildcard that identifies a public suffix
{{Public-Suffix}}, such as `*.co.uk` or `*.com`, is beyond the scope of this
document.
## Internationalized Domain Names {#security-idn}
Allowing internationalized domain names can lead to the inclusion of visually
similar, or confusable, characters in certificates. For discussion, see for
example {{IDNA-DEFS}}.
## Multiple Identifiers {#security-multi}
A given application service might be addressed by multiple DNS domain names
for a variety of reasons, and a given deployment might service multiple
domains or protocols. The client MUST use the TLS Server Name Identification
(SNI) extension as discussed in {{TLS, Section 4.4.2.2}}. If multiple
protocols share the same port, the client MUST use the Application-Layer
Protocol Negotiation as described in {{ALPN}}.
To accommodate the workaround that was needed before the development
of the SNI extension, this specification allows multiple DNS-IDs,
SRV-IDs, or URI-IDs in a certificate.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
