On 8/30/10 5:10 PM, Bernard Aboba wrote:
Peter St. Andre said:
"an SRV record can be used for two quite different purposes:
1. To point from an application service name to a particular
host/domain name in the same administrative domain (e.g.,
_imap._example.com points to mailhost.example.com for its IMAP
2. To delegate an application service name to a hosting provider
outside in the administrative domain of the application service
(e.g., example.com delegates its IMAP service to
As I see it, RFC 4985 glosses over the foregoing distinction."
[BA] It took some adjustment for me, but as I understand it, the
underlying assumption of RFC 4985 is that if the certificate is
considered valid by RFC 5280 path validation (e.g. chains to a valid
trust anchor, etc.) then delegations both within and outside the
source administrative domain can be validated. This logic, if
pursued, could apply beyond SRV RR validation, to things like NAPTR
validation via a URI/IRI in the certificate.
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.
Scoping (EKUs, name constraints, etc.) is a different question.
Peter also said:
"However, the question arises: what is the client supposed to check
if an SRV lookup for _imap._example.com yields apps.example.net? My
reading of RFC 4985 leads me to think that the certificate presented
by apps.example.net is supposed to contain an SRV-ID of
_imap.example.com, which means roughly "this certificate indicates
that this provider is authorized to provide IMAP service for the
example.com domain". (How the certification authority determines that
the delegation is indeed authorized is outside the scope of this
[BA] That's also my reading of RFC 4985, but I'll let others more
knowledgeable (like the author) weigh in.
That would indeed be helpful.
Ietf mailing list