If that's the logic, I'd at the least like to see a "4985bis" spec make
that clear, because IMHO it's not spelled out now.
RFC 4985 refers to authentication of service discovery in Sections 1 and 2. Section 1 states:
"
This document specifies a name form for inclusion in X.509"
certificates that may be used by a certificate relying party to
verify that a particular host is authorized to provide a specific
service within a domain.
RFC 2782 [N3] defines a DNS RR (Resource Record) for specifying the
location of services (SRV RR), which allows clients to ask for a
specific service/protocol for a specific domain and get back the
names of any available servers.
Existing name forms in X.509 certificates support authentication of a
host name. This is useful when the name of the host is known by the
client prior to authentication.
When a server host name is discovered through DNS RR lookup query
based on service name, the client may need to authenticate the
server's authorization to provide the requested service in addition
to the server's host name.
While DNS servers may have the capacity to provide trusted
information, there may be many other situations where the binding
between the name of the host and the provided service needs to be
supported by additional credentials.
Current dNSName GeneralName Subject Alternative name form only
provides for DNS host names to be expressed in "preferred name
syntax", as specified by RFC 1034 [N4]. This definition is therefore
not broad enough to allow _expression_ of a service related to that
domain.
Section 2 states:
"
Even though this name form is based on the service resource record"
(SRV RR) definition in RFC 2782 [N3] and may be used to enhance
subsequent authentication of DNS-based service discovery, this
standard does not define any new conditions or requirements regarding
use of SRV RR for service discovery or where and when such use is
appropriate.
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf