[prev in list] [next in list] [prev in thread] [next in thread]
List: ietf-tls
Subject: Re: [TLS] [xmpp] Review of draft-saintandre-tls-server-id-check
From: Bernard Aboba <bernard.aboba () gmail ! com>
Date: 2010-09-07 0:25:37
Message-ID: AANLkTi=DgKbkomuZDkpwJ0+_ZzXsxVXSnXb_Cig-y2L8 () mail ! gmail ! com
[Download RAW message or body]
Peter said:
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.
"
[Attachment #3 (text/html)]
Peter said:<br><br><div class="gmail_quote"><blockquote class="gmail_quote" \
style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); \
padding-left: 1ex;"> If that's the logic, I'd at the least like to see a \
"4985bis" spec make<br> that clear, because IMHO it's not spelled out \
now.<br></blockquote><div><br><br>RFC 4985 refers to authentication of service \
discovery in Sections 1 and 2. Section 1 states:<br><br>"<pre> This document \
specifies a name form for inclusion in X.509<br>
certificates that may be used by a certificate relying party to<br> verify that \
a particular host is authorized to provide a specific<br> service within a \
domain.<br><br> RFC 2782 [N3] defines a DNS RR (Resource Record) for specifying \
the<br>
location of services (SRV RR), which allows clients to ask for a<br> specific \
service/protocol for a specific domain and get back the<br> names of any available \
servers.<br><br> Existing name forms in X.509 certificates support authentication \
of a<br>
host name. This is useful when the name of the host is known by the<br> client \
prior to authentication.<br><br> When a server host name is discovered through DNS \
RR lookup query<br> based on service name, the client may need to authenticate \
the<br>
server's authorization to provide the requested service in addition<br> to \
the server's host name.<br><br> While DNS servers may have the capacity to \
provide trusted<br> information, there may be many other situations where the \
binding<br>
between the name of the host and the provided service needs to be<br> supported \
by additional credentials.<br><br> Current dNSName GeneralName Subject Alternative \
name form only<br> provides for DNS host names to be expressed in "preferred \
name<br>
syntax", as specified by RFC 1034 [N4]. This definition is therefore<br> \
not broad enough to allow expression of a service related to that<br> \
domain.<br><br></pre>"<br><br>Section 2 states:<br><br>"<pre>
Even though this name form is based on the service resource record<br> (SRV RR) \
definition in RFC 2782 [N3] and may be used to enhance<br> subsequent \
authentication of DNS-based service discovery, this<br> standard does not define \
any new conditions or requirements regarding<br>
use of SRV RR for service discovery or where and when such use is<br> \
appropriate.<br></pre>"<br></div></div><br>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic