Basically, yeah, as long as you have DNSSEC. In fact, if you've got
DNSSEC, you don't really even need the application-specific bit at the
end. The goal of the XMPP DNA work (and other analogous things) is to
work around not having DNSSEC in the mean time. In that solution, the
parallel path is:
- Announce the fact that example.com is hosted at
clendarserverfoobar.com in DNS
- Connect to calendarserverfoobar.com over TLS and check that the name
in the cert is indeed calendarfoobar.com
- Obtain an attribute cert for calendarfoobar.com signed by example.com
- Valid signature and certificate for example.com implies that
delegation is OK
The third of these steps of course require some application-specific
magic.
--Richard
On Jun 23, 2010, at 2:52 PM, Patrik Fältström wrote:
On 23 jun 2010, at 16.33, Richard L. Barnes 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
- Do application layer authentication etc over the then encrypted
connection
Sounds ok?
Patrik
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf