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 service). 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 apps.example.net)..... 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. 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 I-D.) [BA] That's also my reading of RFC 4985, but I'll let others more knowledgeable (like the author) weigh in. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf