RFC 3261 SIP: Session Initiation Protocol Junho 2002
23.4.1.2 Confidencialidade
Quando mensagens são criptografadas, campos-cabeçalhos podem ser incluídos no corpo criptografado que não estiverem presentes na mensagem "externa".
Alguns campos-cabeçalhos precisam sempre ter uma versão plaintext porque eles são campos-cabeçalhos exigidos em requisições e respostas - esses incluem:
To, From, Call-ID, CSeq, Contact. Embora provavelmente não seja útil para fornecer uma alternativa criptografada aos Call-ID, CSeq ou Contact, fornecer uma alternativa à informação nos To ou From "externos" é permitido. Note que os valores em um corpo criptografado não são usados para finalidade de identificar transações ou diálogos - eles são meramente informativos. Se o campo-cabeçalho From em um corpo criptografado difere do valor na mensagem "externa", o valor dentro do corpo criptografado DEVEM ser exibido ao usuário, mas NÃO PODE ser usado nos campos-cabeçalhos "externos" de quaisquer mensagens futuras.
Primariamente, um agente-usuário desejará criptografar campos-cabeçalhos que tenham uma semântica fim-a-fim, incluindo: Subject, Reply-To, Organization, Accept, Accept-Encoding, Accept-Language, Alert-Info, Error-Info, Authentication-Info, Expires, In-Reply-To, Require, Supported, Unsupported, Retry-After, User-Agent, Server e Warning. Se qualquer desses campos-cabeçalhos estiverem presentes em um corpo criptografado, eles devem ser usados no lugar de quaisquer campos-cabeçalhos "externos", se isso implicar em exibir os valores do campo-cabeçalho aos usuários ou se implicar setar estados internos no UA. Eles NÃO DEVEM, contudo, ser usados nos cabeçalhos "externos" de quaisquer mensagens futuras.
Se presente, o campo-cabeçalho Date PRECISA sempre ser o mesmo nos cabeçalhos "internos" e "externos".
Como corpos MIME são anexados à mensagem "interna", implementações vão usualmente criptografar campos-cabeçalhos específicos do MIME, incluindo: MIME-Version, Content-Type, Content-Length, Content-Language, Content-Encoding e Content-Disposition. A mensagem "externa" terá os campos-cabeçalhos MIME apropriados para corpos S/MIME. Esses campos-cabeçalhos (e quaisquer corpos MIME que eles apresentarem) devem ser tratados como campos-cabeçalhos e corpos MIME normais recebidos em uma mensagem SIP.
Não é particularmente útil criptografar os seguintes campos-cabeçalhos: Min-Expires, Timestamp, Authorization, Priority e WWW-Authenticate. Essa categoria inclui também aqueles campos-cabeçalhos que podem ser alterados por servidores proxy (descritos na seção precedente). UA's nunca DEVEM incluir esses em uma mensagem "interna" se eles não forem
Rosenberg, et. al. Standards Track [Página 208]
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