O subdomínio.exemplo.com pode definir um cookie que pode ser lido por exemplo.com?

Simplesmente não acredito que isso seja tão difícil de determinar.

Mesmo depois de ler as RFCs, não está claro para mim se um servidor no subdomínio.exemplo.com pode definir um cookie que pode ser lido por exemplo.com.

subdomínio.exemplo.com pode definir um cookie cujo atributo Domínio seja .exemplo.com. A RFC 2965 parece declarar explicitamente que esse cookie não será enviado para example.com, mas diz igualmente que, se você definir Domínio = example.com, um ponto será acrescentado, como se você dissesse .example.com. Tomados em conjunto, isso parece dizer que, se example.com retorna um cookie com Domain = example.com, ele não recebe esse cookie de volta! Isso não pode estar certo.

Alguém pode esclarecer quais são realmente as regras?

Citando o mesmo RFC2109 que você leu:

       * Um conjunto de cookies do host de solicitação x.foo.com para o domínio = .foo.com
         Ser aceito.

Então, subdomain.example.compode definir um cookie para .example.com. Por enquanto, tudo bem.

       As regras a seguir se aplicam à escolha de valores de cookies aplicáveis ​​em
       entre todos os cookies que o agente do usuário possui.

       Seleção de Domínio
            O nome completo do host do servidor de origem deve corresponder ao domínio
            o atributo Domínio do cookie

Então, temos uma correspondência de domínio?

   * A é uma string FQDN e tem o formato NB, onde N é um nome não vazio
     string, B tem o formato .B 'e B' é uma string FQDN. (Então, xycom
     corresponde ao domínio .y.com, mas não ao y.com.)

Mas agora example.comnão corresponderia .example.comao domínio de acordo com a definição. Mas www.example.com(ou qualquer outro "nome não vazio" no domínio) seria. Essa RFC é, em teoria, obsoleta pela RFC2965 , que ditava coisas sobre forçar um ponto principal para domínios em Set-Cookie2operações.

Mais importante, como observado por @Tony, é o mundo real. Para ter uma idéia do que os agentes do usuário estão fazendo, consulte

NsCookieService.cpp do Firefox 3

e

Cookie_monster.cc do Chrome

Para perspectiva em que sites reais estão fazendo, tentar jogar com wgetusando --save-cookies, --load-cookiese --debugpara ver o que está acontecendo.

Você provavelmente descobrirá que, na verdade, a maioria dos sites está usando alguma combinação das Set-Cookieespecificações RFC mais antigas com valores "Host", implicitamente sem um ponto inicial (como o twitter.com ) ou definindo valores de Domínio (com um ponto inicial) e redirecionando para um servidor como www.example.com(como o google.com ).

Se o navegador implementa a RFC 6265 , que qualquer navegador moderno deveria estar fazendo neste momento, um cookie definido para .example.comterá o ponto inicial ignorado (seção 5.2.3), e o cookie será enviado para o domínio livre e para todos subdomínios.

Não confie nesse comportamento se você tiver tráfego significativo de navegadores antigos; essa RFC data apenas para 2011.

Não deveria ser possível. No entanto, como você disse, como esse não é um padrão amplamente documentado, depende de qual software você está usando.

A maioria dos navegadores modernos segue um "modelo de segurança da web" definido. O modelo governa efetivamente o comportamento dos navegadores em relação à segurança, em coisas como cookies (especificamente como eles serão enviados de volta para qualquer site). O modelo também tem a regra de que "os navegadores não enviam cookies para nomes de domínio que não os definiram".

Dito isto, domain.com deve poder configurar cookies para js.domain.com. js.domain.com, no entanto, só pode definir cookies para si. Mas tudo isso depende do navegador que você está usando.