ietf
[Top] [All Lists]

Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard

2010-06-23 09:05:09
On 23 jun 2010, at 00.59, Thomson, Martin wrote:

It seems that Section 7 has an old example in it.  Did you previously use 
NAPTR with a "D" flag?

Actually, no. If you do know what protocol you look for, you can use the URI RR 
directly. The idea with the NAPTR and the "D" flag was that it would list what 
URI records exists in the zone.

Let me expand a bit also including the caldav example:

$ORIGIN example.com.

     IN NAPTR 200 10 "D" "EM:protA"  (      ; service
     ""                                     ; regexp
     "example.com."                  )      ; replacement

     IN NAPTR 200 10 "D" "caldav:caldav"  (      ; service
     ""                                     ; regexp
     "example.com."                  )      ; replacement

     IN NAPTR 200 10 "D" "caldav:carddav"  (      ; service
     ""                                     ; regexp
     "example.com."                  )      ; replacement

_protA._EM IN URI "prota://somehost.example.com/"

_carddav._caldav IN URI "http://somehost.example.com/whateveruri";

_caldav._caldav IN URI "http://somehost.example.com/someotheruri";

I.e. if you know you want the carddav/caldav URI, you just look up the 
{IN,URI,_carddav._caldav.example.com} RRSET, if you want to know the services 
example.com has, you look up {IN,NAPTR,example.com} and then with flag "D" you 
see what you can find using lookup of URI RR.

So, the NAPTR and flag "D" is not really needed for the resolution. It is a 
"list the services" feature.

But, I will remove that part because it is not really a piece of the URI 
definition.

For security considerations, I have one to add.  RFC 3958 (S-NAPTR) has this 
nasty little authentication hitch, that you should really consider in this 
draft.  The reference identifier (see draft-saintandre-tls-server-id-check) 
that you are required to use for authenticating the host is the one that is 
input to the resolution process...not the product of the process.

Basically, if you search for _http._web.example.net and get 
"http://www.example.com/ ", then you are expected to authenticate against 
_http._web.example.net (or maybe example.net, I'm not sure - NAPTR doesn't 
use the '_' prefix).

I thought you should authenticate against example.net?

I.e. you want "caldav"/"caldav" for "example.com" and get back 
"http://www.calendarserverfoobar.com/caldav/example.com/caldav"; (for a 
PROPFIND), what is the best to require for authentication? example.com or 
www.calendarserverfoobar.com? I presume example.com (the domain name used 
_before_ the URI lookup happens.

   Patrik


I'm happy to expand on the problems that I faced with this little security 
tangle.  The problem doesn't end there.


Attachment: PGP.sig
Description: This is a digitally signed message part

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
<Prev in Thread] Current Thread [Next in Thread>