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 > 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. 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. Agreed. > 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. That would indeed be helpful. Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf