Sorry about the delayed reply, and thanks for your persistence. On 11/21/10 7:57 AM, Dan Winship wrote: > On 11/20/2010 11:46 PM, Peter Saint-Andre wrote: >> On 11/20/10 2:28 PM, Dan Winship wrote: >>> draft-saintandre-tls-server-id-check-11, section 3.2 says: >>> >>> A certificate for the IMAP-accessible email server at >>> "mail.example.net" might include SRV-IDs of "_imap.mail.example.net" >>> and "_imaps.mail.example.net" (see [EMAIL-SRV]) and a DNS-ID of >>> "mail.example.net". >>> >>> As I understand it, the SRV-ID is based on the source domain, not the >>> derived domain, and so "_imap.mail.example.net" would only be correct if >>> you were expecting clients to do a SRV lookup for >>> "_imap._tcp.mail.example.net". But the more usual case would be doing a >>> lookup for "_imap._tcp.example.net", in which case the corresponding >>> SRV-ID would "_imap.example.net". Right? >> >> Why assume so? >> >> Although my email address is [email protected], my email server is >> "mailhost.stpeter.im" and I have explicitly configured my email client >> to connect to that server. In that case, "mailhost.stpeter.im" is a >> source domain. > > Right, but there would be no SRV-IDs involved in that case, because your > email client didn't need to do a SRV lookup.
Not necessarily. Let's say that I've delegated my XMPP application to Google's hosting service at gmail.com. So in my client I hardcode the equivalent of "for stpeter.im, connect to gmail.com". But my client might still need to do an SRV lookup for the target domain, leading to results like this: $ dig +short -t SRV _xmpp-client._tcp.gmail.com 20 0 5222 talk1.l.google.com. 20 0 5222 talk2.l.google.com. 20 0 5222 talk3.l.google.com. 20 0 5222 talk4.l.google.com. 5 0 5222 talk.l.google.com. > Maybe I'm misusing the source/derived domain terminology, so forget > about that part... Well, it's important to understand the terminology so we're sure that we're talking about the same things. So far I think we might be talking about different things, but both are important. > What I was trying to say is that the example is weird, because it seems > like it's probably talking about the IMAP server that is used by the guy > whose email address is "[email protected]", but actually it's talking > about the IMAP server that is used by "[email protected]". > "[email protected]"'s IMAP server would have to present a SRV-ID of > "_imap.example.net", not "_imap.mail.example.net", regardless of the > hostname of the server it was running on (assuming I'm reading > draft-daboo-srv-email-05 and RFC 4985 right). I think it would be helpful to have one example of foo.example.tld servicing addresses of the form [email protected] and one example of foo.example.tld servicing addresses of the form [email protected], because both approaches are legitimate and it's good to show the differences between the two. Thus I suggest: ### 3.2. Examples Consider a simple website at "www.example.com", which is not discoverable via DNS SRV lookups. A certificate for this service might include only a DNS-ID of "www.example.com" (and, strictly as a fallback for existing client software, a CN-ID of "www.example.com"). Consider an IMAP-accessible email server at "mail.example.net" servicing email addresses of the form "[email protected]" and discoverable via DNS SRV lookups on the "example.net" domain. A certificate for this service might include SRV-IDs of "_imap.example.net" and "_imaps.example.net" (see [EMAIL-SRV]) along with a DNS-ID of "example.net". Consider an XMPP-compatible instant messaging server at "im.example.org" servicing IM addresses of the form "[email protected]" and discoverable via DNS SRV lookups on the "im.example.org" domain. A certificate for this service might include SRV-IDs of "_xmpp-client.im.example.org" and "_xmpp- server.im.example.org" (see [XMPP]), a DNS-ID of "im.example.org", and an XMPP-specific "XmppAddr" of "im.example.org" (see [XMPP]). ### Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
