RFC 3261 SIP: Session Initiation Protocol Junho 2002
A RFC 2543 não permitia o uso do campo-cabeçalho Authentication-Info (efetivamente usada a RFC 2069). No entanto, nós agora permitimos o uso desse campo-cabeçalho, uma vez que ele fornece verificações de integridade dos corpos e fornece autenticação mútua. A RFC 2617 [17] define mecanismos por retro-compatibilidade usando o atributo qop na requisição. Esses mecanismos PRECISAM ser usados por um servidor determinar se o cliente suporta os novos mecanismos na RFC 2617 que não eram especificados na RFC 2069.
23 S/MIME
Mensagens SIP transportam corpos MIME e o padrão MIME inclui mecanismos para proteger o conteúdo MIME para assegurar tanto a integridade quanto a confidencialidade (incluindo a 'multipart/signed' e tipos MIME 'application/ pkcs7-mime', ver a RFC 1847 [22], RFC 2630 [23] e RFC 2633 [24]). Implementadores devem observar, no entanto, que pode haver raras redes intermediárias (não típico servidores proxy) que dependem da visualização ou modificação dos corpos de mensagens SIP (especialmente o SDP), e que MIME seguro pode evitar esses tipos de intermediários de funcionar.
Isso se aplica particularmente a certos tipos de firewalls.
O mecanismo PGP para criptograr os campos-cabeçalhos e corpos de mensagens SIP descritos na RFC 2543 foi descontinuado.
23.1 Certificados S/MIME
Os certificados que são usados para identificar um usuário final para os propósitos do S/MIME diferem daqueles usados por servidores em um aspecto importante - em vez de afirmar que a identidade do titular corresponde a um hostname particular, esses certificados afirmar que o titular é identificado por um endereço do usuário final. Este endereço é composto da concatenação das partes "userinfo" "@" e "domainname" de um URI do SIP ou do SIPS (em outras palavras, um endereço de e-mail na forma "bob@biloxi.com"), que corresponde mais comumente a um endereço-de-registro de um usuário.
Esses certificados estão também associados com chaves que são usadas para assinar ou criptografar corpos de mensagens SIP. Corpos são assinados com a chave privada do remetente (que pode incluir sua chave pública com a mensagem conforme o apropriado), mas corpos são criptografados com a chave pública do destino pretendido. Obviamente, remetentes precisam ter presciência da chave pública dos destinos, a fim de criptografar o corpo das mensagens. Chaves públicas podem ser armazenadas dentro de um UA em um keyring virtual.
Rosenberg, et. al. Standards Track [Página 201]
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.
Nenhum comentário:
Postar um comentário