RFC 3261 Português Página 211

RFC 3261 SIP: Session Initiation Protocol Junho 2002

ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756

--boundary42-

23.4.3 Tunelando Criptografia

Também pode ser desejável usar esse mecanismo para criptografar um corpo MIME "mensagem/sip" dentro de uma mensagem CMS EnvelopedData corpo S/MIME, mas na prática, a muitos campos-cabeçalhos são de, ao menos, algum uso na rede; o uso geral de criptografia com S/MIME deve assegurar corpos de mensagens como o SDP, em vez de cabeçalhos de mensagens. Alguns campos-cabeçalhos informacionais, tais como Subject ou Organization talvez possam garantir segurança fim-a-fim. Cabeçalhos definidos por futuras aplicações SIP também pode exigir ofuscação.

Outra aplicação possível de criptografar campos-cabeçalhos é anonimato seletivo. Uma requisição pode ser construída com um campo-cabeçalho From que não contenah nenhuma informação pessoal (por exemplo, sip:anonymous@anonymizer.invalid). Contudo, um segundo campo-cabeçalho From contendo o address-of-record genuíno do originador pode ser criptografado dentro de um corpo MIME "message/sip" onde ele só será visível aos endpoints de um diálogo.

Note que se esse mecanismo for usado para anonimato, o campo-cabeçalho From não mais será usavel pelo receptor de uma mensagem como um índice para seu keychain de certificado para recuperar a chave S/MIME apropriada associada com o remetente. A mensagem precisa primeiro ser descriptografada, e o campo-cabeçalho From "interna" PRECISA ser usado como um índice.

A fim de fornecer integridade fim-a-fim, corpos MIME "message/sip" criptografados DEVEM ser assinados pelo remetente. Isso cria um corpo MIME "multipart/signed" que contém um corpo criptografado e uma assinatura, ambos de tipo "application/pkcs7-mime".

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

Página Anterior

Tabela de Conteúdo

Página Seguinte



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.