Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)
updates
Extracted elements (26)
The bootstrapping procedure is designed to require only minimal user input (an email or calendar user address plus a password), enabling automatic client configuration without requiring users to know FQDNs, port numbers, or path details.
Well-known URIs are used because CalDAV or CardDAV services may not be located at the HTTP server root; SRV records only supply an FQDN and port, not a path. The well-known URI provides a stable, discoverable stub that redirects to the actual context path, decoupling discovery from deployment topology.
CalDAV and CardDAV servers SHOULD support authentication with the 'mailbox' portion of mailto: URIs or email addresses as user identifiers. User identifiers extracted this way MUST NOT conflict with other login names on the server to avoid ambiguity.
Clients MUST honor Priority and Weight values in SRV RRs as described by RFC 2782 when selecting among multiple returned SRV records.
For authentication, clients MUST first use the full 'mailbox' portion of a mailto: calendar user address, and if that fails, SHOULD fall back to just the 'local-part'. If these fail, the client SHOULD prompt the user for a valid identifier.
If the context path derived from a TXT record generates HTTP errors, the client SHOULD repeat bootstrapping using the appropriate well-known URI instead.
If TLS is used, service providers MUST ensure an installed certificate can be verified per RFC 6125; certificates SHOULD include SRV-ID and DNS-ID identifiers as appropriate.
Once successful account discovery is completed, clients SHOULD cache the service details (user identity and principal-URL with full scheme/host/port) and reuse them on subsequent connections. On persistent failure, clients SHOULD retry SRV lookup and discovery.
Servers MUST force authentication for PROPFIND requests retrieving DAV:current-user-principal to ensure the returned principal-URL corresponds to the authenticated requesting user.
Servers MUST redirect HTTP requests for the well-known URI to the actual context path using HTTP redirect mechanisms (e.g., 301, 303, or 307). Clients MUST handle HTTP redirects on well-known URIs. Servers MUST NOT locate the actual service endpoint at the well-known URI.
Servers SHOULD set an appropriate Cache-Control header in the redirect response to control caching behavior; for example, 'no-cache' if the redirect location might change over time.
The client issues a PROPFIND request to the initial context path; the request body SHOULD include the DAV:current-user-principal property. If the server returns 404, clients MAY retry on the root URI '/' or prompt the user.
The server MAY require authentication before issuing the well-known URI redirect, returning a 401 to unauthenticated requests and only redirecting after successful authentication, to support per-user context paths.
The value of the 'path' key in the DNS TXT record MUST be the actual context path to the corresponding service on the server. When present, clients MUST use this path value as the context path for HTTP requests.
When an SRV lookup returns a valid record, the client MUST also query for a corresponding TXT record and check for a 'path' key; if present, that value is used as the initial context path.
When connecting using _caldavs or _carddavs services, the client MUST perform certificate verification using the procedure in RFC 6125 Section 6 with the SRV RR as the starting point.
When no SRV record is found, clients MUST first attempt an HTTP connection with TLS using default HTTPS port numbers before falling back to non-TLS connections.
DNS TXT records following RFC 6763 syntax are used alongside SRV records to advertise CalDAV and CardDAV services. A 'path' key in the TXT record carries the context path for the service (e.g., 'path=/caldav').
Two SRV service labels are defined for CalDAV: '_caldav' for HTTP without TLS and '_caldavs' for HTTP with TLS. These allow DNS-based discovery of CalDAV servers by clients.
Two well-known URIs are defined: '/.well-known/caldav' for CalDAV and '/.well-known/carddav' for CardDAV. These serve as stable entry points that redirect clients to the actual service context path.
IANA registered four service names per RFC 6335: 'caldav' (CalDAV non-TLS, TCP, defined here) and 'caldavs' (CalDAV over TLS, TCP, defined here); 'carddav' (CardDAV non-TLS, TCP) and 'carddavs' (CardDAV over TLS, TCP) are registered here but originally defined in RFC 6352. All support the TXT key 'path=<context path>'.
IANA registered two well-known URIs under RFC 5785: 'caldav' (for CalDAV service discovery, referencing RFC 4791) and 'carddav' (for CardDAV service discovery, referencing RFC 6352).
A malicious attacker controlling DNS can redirect clients to arbitrary servers. Without secure DNS, clients SHOULD verify the SRV target FQDN matches the queried domain, or prompt the user if it does not. When the FQDN does not match, clients MUST check the SRV-ID in the server certificate; if it does match, clients MUST check SRV-ID or, absent SRV-ID, DNS-ID identifiers.
Clients and servers MUST NOT request, offer, or use SSL 2.0 due to known security vulnerabilities, as noted in RFC 5246 Appendix E.2.
Clients that support TLS SHOULD try _caldavs/_carddavs services before _caldav/_carddav. If the user explicitly requested TLS, clients MUST NOT use non-TLS service records. Clients MUST follow the certificate-verification process in RFC 6125.
The client bootstrapping procedure has five stages: (1) parse user input to extract domain and local-part, (2) SRV lookup for _caldavs/_carddavs (then _caldav/_carddav if no TLS result), (3) determine context path via TXT record or well-known URI, (4) determine user identifier from mailbox or userinfo, (5) connect, issue PROPFIND for DAV:current-user-principal to obtain principal-URL.