Admirável Mundo Novo: Tudo Sobre Asterisk, OpenSER, Linux e Tecnologias de Voz sobre IP

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


processar a sinalização. Se o usuário autorizar esse certificado, ele DEVE ser adicionado ao keyring ao lado de qualquer valor(es) anterior(es) para esse endereço de registro.

Note bem que, no entanto, esse mecanismo de troca de chaves não garante a troca segura de chaves quando certificados auto-assinados ou certificados assinados por uma autoridade obscura, são usados – ele é vulnerável a ataques conhecidos. Na opinião dos autores, no entanto, a segurança que ele fornece é proverbialmente melhor do que nada, de fato, é comparável à aplicação SSH amplamente usada. Essas limitações são exploradas em maior detalhe na Seção 26.4.2.

Se um UA recebe um corpo S/MIME que foi criptografado com uma chave pública desconhecida ao destino, ele PRECISA rejeitar a requisição com uma resposta 493 (Undecipherable). Essa resposta DEVE conter um certificado válido ao respondente (que corresponde, se possível, a qualquer endereço de dado registro no campo-cabeçalho To da requisição rejeitada) dentro de um corpo MIME com um parâmetro "smime-type" igual a 'certs-only'.

Uma 493 (Undecipherable) enviada sem qualquer certificado indica que o respondente não pode ou não utilizará mensagens S/MIME criptografadas, embora ele possa ainda suportar assinaturas S/MIME.

Note que um agente-usuário que recebe uma requisição contendo um corpo S/MIME que não é opcional (com um parâmetro de cabeçalho "handling" igual a "required" no Content-Disposition) PRECISA rejeitar a requisição com uma resposta 415 (Unsupported Media Type) se o tipo MIME não for compreendido. Um agente-usuário que recebe tal resposta quando S/MIME é enviado DEVE notificar seu usuário que o dispositivo remoto não suporta S/MIME, e ele PODE subseqüentemente reenviar a requisição sem S/MIME, se apropriado; no entanto, essa resposta 415 pode constituir um ataque de downgrade.

Se um agente-usuário envia um corpo S/MIME em uma requisição, mas recebe uma resposta que contém um corpo MIME que não é seguro, o UAC DEVE notificar seu usuário que a sessão não poderá ser segura. Contudo, se um agente-usuário que suporta S/MIME receber uma requisição com um corpo não seguro, ele NÃO DEVE responder com um corpo seguro, mas se ele espera S/MIME do remetente (por exemplo, porque o valor do campo-cabeçalho From do remetente corresponde a uma identidade em seu keychain), o UAS DEVE notificar seu usuário que a sessão poderá não ser segura.

Inúmeras condições que surgem no texto anterior demandam notificação do usuário quando um evento de gerenciamento de certificado anômalo ocorre. Os usuários podem muito bem perguntar o que devem fazer nessas circunstâncias. Em primeiro lugar, uma mudança inesperada em um certificado, ou uma ausência de segurança quando segurança é esperado, são 





Rosenberg, et. al.          Standards Track                   [Página 204]

Observações importantes a cerca dessa tradução:
A tradução de algumas terminologias do SIP:

User agent ficou como agente-usuário;
Header field como campo-cabeçalho;
Requests ficou em português como requisições no plural e no singular requisição.

Quanto às palavras/verbos usadas em documentos RFC's tramitando em trilha de 
padronizações, que obedecem as regras da RFC 2119/IETF, foram traduzidas
para o português conforme a seguir:

MUST:
    PRECISA, REQUERER, OBRIGAR, EXIGIR, FORÇAR, É OBRIGATÓRIO, É FORÇOSO, 
    NECESSITAR, É MANDATÓRIO.

MUST NOT:
    NÃO PODE, É PROIBIDO, É VEDADO.

SHOULD:
    DEVE, É RECOMENDADO.

SHOULD NOT:
    NÃO DEVE, NÃO É RECOMENDADO.

MAY:
    PODE, É OPCIONAL.