Hi Patrik,
--On June 23, 2010 8:52:45 PM +0200 Patrik Fältström <paf(_at_)cisco(_dot_)com>
wrote:
In principle, example.com is the proper domain to authenticate, but in
practice, that causes a lot of problems. Consider the case where the
target of the redirection is a separate entity from the origin; this
could arise, for example, in a situation whereexample.com has outsourced
its calendaring services to calendardserverfoobar.com.
So, the "connect the dots" is to:
- Announce the fact example.com is hosted at calendarserverfoobar.com
(with some URL) in DNS
- Secure that announcement in DNS with DNSSEC
- Verify the SSL (for example) cert for the connection to
calendarserverfoobar.com matches
So the srv-caldav (and srv-email) drafts reference Section 3 of
draft-saintandre-tls-server-id-check which describes how clients can go
about verifying a server identity when using TLS under various
circumstances, including an initial discovery via SRV records.
- Do application layer authentication etc over the then encrypted
connection
Sounds ok?
Well the key here is DNSSEC of course!
--
Cyrus Daboo
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf