On 9/8/10 5:39 PM, Stefan Santesson wrote: > Peter, > > Thank for the clarifying example. I see now what problem you are addressing. > > Comments in line; I'm short on time right now so will reply briefly at the end. > On 10-09-09 12:35 AM, "Peter Saint-Andre" <stpeter@xxxxxxxxxx> wrote: > > <stuff deleted> > >>> It is not. RFC 4985 says the following in section 2: >>> >>> _Service.Name >>> >>> <snip> >>> >>> Name >>> The DNS domain name of the domain where the specified service >>> is located. >> >> Perhaps some examples would help. >> >> The good folks at example.com have delegated their IM service to >> apps.hosting.net. When the user someone@xxxxxxxxxxx does an SRV lookup >> for _xmpp-client._tcp im.example.com, its client gets back something >> like this: >> >> 20 0 5222 apps.hosting.net. >> >> The client resolves apps.hosting.net to an IP address and connects to >> that machine. >> >> During TLS negotiation, the application service for example.com (which >> is in fact being serviced by apps.hosting.net) presents a certificate >> that contains an SRV-ID. Which of the following is it? >> >> 1. _xmpp.example.com >> >> or: >> >> 2. _xmpp.apps.hosting.net >> > > According to the actual intent of RFC 4985 the right answer is 1, however > reading the definition of the name form it suggests 2, since this is where > the service is located. However I think this is an error in RFC 4985. See > below. > > In case of 2, If the DNS fooled you, then you may end up at an authorized > service for hosting.net that has no business serving example.com, and you > have no way to tell. > > >> If #1, then the "Name" in _Service.Name is indeed a "Name" as defined in >> RFC 2782. >> >> If #2, then the "Name" in _Service.Name is actually a "Target" as >> defined in RFC 2782. >> > > >>> The client now has assurance from the CA that this host is in fact >>> authorized to provide this service. >> >> To use my example, the CA is providing assurance that apps.hosting.net >> is authorized to provide the XMPP service on behalf of example.com. That >> seems reasonable if the presented identifier based on the source domain >> (example.com). However, if the assurance is checked on the client side >> by finding _xmpp.apps.hosting.net as the presented identifier then I >> fail to understand something very basic: how does the client tie that >> SRV-ID to the source domain (example.com) in a secure fashion? The >> presented identifier seems to be a mere assertion without any connection >> whatsoever to the source domain. > > I actually think we made an error in 4985 and that the domain name should be > the domain that the service is authorized to represent. > > RFC 4985 is ambiguous here: the definition of the name form says: > > "The DNS domain name of the domain where the specified service > is located." > > This corresponds to #2 in your example > While the description underneath the definition states: > > "The purpose of the SRVName is limited to authorization of service > provision within a domain." > > Which corresponds to #1. > > I think there should be an errata correcting the definition to be: > > "The DNS domain name of a domain for which the certified subject > is authorized to provide the identified service." > > As it is now, the RFC is ambiguous. > >> If we just wave our hands and say "the >> client can simply let the user believe that it's OK for apps.hosting.net >> to assert a right to provide the IM service for example.com and it >> doesn't matter if there is no basis for that belief because the >> information might not be trustworthy" then I wonder what RFC 4985 really >> accomplishes or whether we want to encourage anyone to use the SRVName >> extension (at least absent DNSSEC, see for example draft-barnes-xmpp-dna). >> > > I agree. But if we can correct the definition (or specify a new OID for a > corrected name form) according to my proposal above, and clarify the use in > your document, would that help in any way? > > I agree that if the SRVName in the cert provides a domain name that is > different from the domain name you asked for (and it's not DNSSEC), then you > will have to rely on local configuration in order to accept it. I'm happy that we're all on the same page and that we only have a spec error in RFC 4985. > I'm not sure how we should fix this. We had quite large review of this RFC > but nobody caught this error. Submitting an erratum is a good first step, I think. Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf