RFC 3261 SIP: Session Initiation Protocol Junho 2002
Se o certificado não pode ser verificado, porque é auto-assinado, ou assinado por nenhuma
autoridade conhecida, ou se é verificável, mas seu assunto não corresponde ao campo-cabeçalho
From da requisição, o UAS PRECISA notificar seu usuário do status do certificado (incluindo o
assunto do certificado, seu signatário, e qualquer informação de impressão digital da chave) e
solicitar permissão explícita antes de prosseguir. Se o certificado foi verificado com sucesso
e o assunto do certificado corresponde ao campo-cabeçalho From da requisição SIP, ou se o
usuário (após a notificação) autoriza explicitamente o uso do certificado, o UAS DEVE adicionar
esse certificado a um keyring local, indexado pelo endereço de registro do titular do certificado.
Quando um UAS envia uma resposta contendo um corpo S/MIME que responde a primeira requisição em
um diálogo, ou uma resposta a uma requisição não-INVITE fora do contexto de um diálogo, o UAS
DEVE estruturar o corpo como um corpo SignedData CMS 'multipart/signed' S/MIME. Se o serviço CMS
desejado é EnvelopedData, o UAS DEVE enviar a mensagem EnvelopedData encapsulada dentro de uma
mensagem SignedData.
Quando um UAC recebe uma resposta contendo um corpo CMS S/MIME que inclui um certificado, o UAC
DEVE primeiro validar o certificado, se possível, com qualquer certificado raiz apropriado. O
UAC DEVE também definir o objeto do certificado e comparar esse valor ao campo To da resposta,
embora os dois possam muito bem ser diferente, e isso não é necessariamente indicativo de uma
falha de segurança. Se o certificado não pode ser verificado, porque é auto-assinado, ou assinado
por nenhuma autoridade conhecida, o UAC PRECISA notificar a seu usuário do status do certificado
(incluindo o assunto do certificado, a sua Signator, e qualquer informação de impressão digital da
chave) e solicitar permissão explícita antes de prosseguir. Se o certificado foi verificado com
sucesso, e o assunto do certificado corresponde ao campo-cabeçalho To na resposta, ou se o usuário
(após a notificação) autoriza explicitamente o uso do certificado, o UAC DEVE adicionar este
certificado a um keyring local, indexado pelo endereço de registro do titular do certificado. Se o
UAC não transmitiu seu próprio certificado ao UAS em qualquer transação anterior, ele DEVE usar um
corpo SignedData CMS em sua próxima requisição ou resposta.
Em ocasiões futuras, quando o UA receber requisições ou respostas que contenham um campo-cabeçalho
From que corresponde a um valor em seu keyring, o UA DEVE comparar o certificado oferecido nessas
mensagens com o certificado existente em seu keyring. Se houver uma discrepância, o UA PRECISA
notificar seu usuário de uma mudança no certificado (de preferência em termos que indica que isso é
um potencial violação de segurança) e adquirir a permissão do usuário antes de continuar a
Rosenberg, et. al. Standards Track [Página 203]
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