Update to Verifying TLS Server Identities with X.509 Certificates
draft-ietf-uta-use-san-00
Document | Type |
Replaced Internet-Draft
(uta WG)
Expired & archived
|
|
---|---|---|---|
Author | Rich Salz | ||
Last updated | 2021-04-01 | ||
Replaces | draft-rsalz-use-san | ||
Replaced by | draft-ietf-uta-rfc6125bis | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Intended RFC status | (None) | ||
Formats | |||
Additional resources | Mailing list discussion | ||
Stream | WG state | WG Document | |
Document shepherd | (None) | ||
IESG | IESG state | Replaced by draft-ietf-uta-rfc6125bis | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
In the decade since [RFC6125] was published, the subjectAlternativeName extension (SAN), as defined in [RFC5280] has become ubiquitous. This document updates [RFC6125] to specify that the fall-back techniques of using the commonName attribute to identify the service must not be used. This document also places some limitations on the use of wildcards in SAN fields. The original context of [RFC6125] using X.509 certificates for server identity with Transport Layer Security (TLS), is not changed.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)