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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


Cada agente-usuário que suporta S/MIME PRECISA conter um keyring especificamente para certificados de usuários finais. Esse keyring deve mapear entre endereços de registro e certificados correspondentes. Com o passar do tempo, usuários DEVEM usar o mesmo certificado, quando eles preencheram o URI originador de sinalização (o campo-cabeçalho From) com o mesmo endereço de registro.

Quaisquer mecanismos dependendo da existência de certificados de usuário final estão seriamente limitados porque não há virtualmente nenhuma autoridade consolidada hoje que forneça certificados para aplicações de usuário final. Contudo, usuários DEVEM adquirir certificados de autoridades de certificação pública conhecida. Como alternativa, usuários PODEM criar certificados auto-assinados. As implicações de certificados auto-assinados são exploradas mais na Seção 26.4.2. Implementações podem também usar certificados pré-configurados em instalações em que uma relação de confiança anterior existe entre todas as entidades SIP.

Em adição ao problema de aquirir um certificado de usuário final, existem alguns diretórios centralizados bem conhecidos que distribuem certificados de usuário final. Entretanto, o titular de um certificado DEVE publicar seu certificado em quaisquer diretórios públicos conforme apropriado. De forma similar, UAC's DEVEM suportar um mecanismo para importar (manual ou automaticamente) certificados descoberto em diretórios públicos que correspondem aos URI's destinos de requisições SIP.


23.2 Troca de Chave S/MIME

SIP em si também pode ser usado como um meio para distribuir as chaves públicas na maneira seguinte.

Sempre que a mensagem SignedData CMS é usada em S/MIME no SIP, ela PRECISA conter o certificado contendo a chave pública necessária para verificar a assinatura.

Quando um UAC envia uma requisição contendo um corpo S/MIME que inicia um diálogo, ou envia uma requisição não-INVITE fora do contexto de um diálogo, o UAC DEVE estruturar o corpo como um corpo SignedData CMS 'multipart/signed' S/MIME. Se o serviço CMS desejado é EnvelopedData (e a chave pública do usuário-alvo é conhecida), o UAC DEVE enviar a mensagem EnvelopedData encapsulada dentro de uma mensagem SignedData.

Quando um UAS recebe uma requisição contendo um corpo S/MIME CMS que inclui um certificado, a UAS DEVE primeiro validar o certificado, se possível, com qualquer certificado raiz disponível por autoridades de certificação. O UAS DEVE também determinar o assunto do certificado (para S/MIME, o SubjectAltName deve conter a identificação apropriada) e comparar esse valor com o campo-cabeçalho From da requisição.



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

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.