ac tecnisign polÍtica de certificados do tipo a3 oid:...

1 AC TECNISIGN - POLÍTICA DE CERTIFICADO – v 1.0

CLASSIFCAÇÃO DA INFORMAÇÃO: PÚBLICA

AC TECNISIGN

POLÍTICA DE CERTIFICADOS DO TIPO A3

OID: 1.3.6.1.4.1.47402.2.8 Versão 1.0

17 de setembro de 2018



Histórico de Atualização:

Versão Data de Criação Autor Item Alterado Descrição da Alteração

v1.0 17/09/2018 Normas e Compliance

Não se aplica Criação da AC TECNISIGN

APROVADO POR:

___________________________________________



SUMÁRIO

SUMÁRIO ................................................................................................................................ 3

1. INTRODUÇÃO ..................................................................................................................... 7

1.1 Visão geral ...................................................................................................................... 8

1.2. Nome do documento e identificação .......................................................................... 8

1.2.1 Identificadores de Políticas de CABF .......................................................................... 8

1.3 Comunidade (Participantes da PKI) ................................................................................... 8

1.3.1 Autoridade Certificadora .............................................................................................. 8

1.3.2 Autoridades de registro................................................................................................ 8

1.3.3 Candidato .................................................................................................................... 9

1.3.4 Assinantes ................................................................................................................... 9

1.3.5 Partes Confiáveis ...................................................................................................... 10

1.3.6 Entidade Credenciadora ............................................................................................ 10

1.3.7 Prestador de Serviço de Suporte ............................................................................... 10

1.3.8 Outros participantes .................................................................................................. 11

1.4 Titulares de Certificado .................................................................................................... 11

1.4.1 Aplicabilidade ................................................................................................................ 11

1.4.1 Usos apropriados do certificado ................................................................................ 11

1.5 Administração de Políticas ............................................................................................... 12

1.5.1 Organização que administra o documento ................................................................ 12

1.5.2 Dados de Contato ...................................................................................................... 12

1.5.3 Pessoa que determina a adequação do DPC como política...................................... 12

1.5.4 Procedimento de aprovação da PC ........................................................................... 12

1.6 Definições e Acrônimos ................................................................................................... 12

1.6.1 Definições .................................................................................................................. 12

1.6.2 Acrônimos .................................................................................................................. 13

1.6.3. Referências .............................................................................................................. 13

1.6.4. Convenções .............................................................................................................. 13

2. Responsabilidades de Publicação e Repositório ............................................................... 13

2.1 Repositório ................................................................................................................... 13

2.2 Publicação da Informação do Certificado ..................................................................... 13

2.3 Tempo ou frequência da publicação ................................................................................ 13

2.4 Controles de Acesso em Repositórios ............................................................................. 13

3. Identificação e Autenticação .............................................................................................. 13

3.1 NOMEAÇÃO ................................................................................................................. 14

3.1.2 Necessidade de nomes serem significativos ............................................................. 14



3.1.3 Anonimato ou pseudônimo de assinantes ................................................................. 14

3.1.4 Regras para Interpretar Vários Formulários de Nomes ............................................. 14

3.1.5 Unicidade de Nomes ................................................................................................. 14

3.1.6 Reconhecimento, Autenticação e Regras para Marcas Registradas ......................... 14

3.2 Validação inicial de identidade ......................................................................................... 15

3.2.1 Método para comprovar a posse de chave privada ................................................... 15

3.3 Informação Não Verificada do Subscritor ..................................................................... 15

3.4 Critérios de Interoperabilidade ......................................................................................... 15

3.5 Identificação e Autenticação para solicitação de nova chave .......................................... 16

3.6 Identificação e Autenticação para Solicitação de Revogação .......................................... 16

4. REQUISITOS OPERACIONAIS DO CICLO DE VIDA DO CERTIFICADO ....................... 16

4.1. Solicitação de Certificado ............................................................................................... 16

4.2 Processo de Requisição de Certificado ........................................................................... 16

4.3 Emissão de Certificado .................................................................................................... 16

4.4 Aceitação de Certificado .................................................................................................. 16

4.5 Par de chaves e uso do Certificado ................................................................................. 16

4.6 Re-certificação do Certificado .......................................................................................... 17

4.7 Renovação do Certificado ................................................................................................ 17

4.8 Modificação do Certificado ............................................................................................... 17

4.9 Suspensão e Revogação de certificados ......................................................................... 17

4.10 Serviços de Status do Certificado .................................................................................. 17

4.11 Fim da subscrição .......................................................................................................... 17

4.12 Custódia e Recuperação das Chaves ............................................................................ 17

5. Instalações, Gerenciamento e Controles Operacionais ..................................................... 17

5.1 Controles Físicos ............................................................................................................. 17

5.2 Controles procedimentais ................................................................................................ 18

5.3 Controles de pessoal ....................................................................................................... 18

5.3.4 Frequência e Requisitos de Reciclagem ....................................................................... 18

5.3.5 Frequência e sequência de rotação de trabalho ........................................................... 18

5.3.6 Sanções para Ações Não Autorizadas ......................................................................... 18

5.3.7 Requisitos para terceiros independentes ...................................................................... 18

5.3.8 Documentação Fornecida ao Pessoal .......................................................................... 18

5.4 Procedimentos de Auditoria de Segurança ...................................................................... 18

5.5 Arquivamento de Registros .............................................................................................. 18

5.6 Troca de Chaves.............................................................................................................. 19

Comprometimento e recuperação de desastre ...................................................................... 19



5.8 Extinção de AC ou AR ..................................................................................................... 19

5.9 Segurança de dados ........................................................................................................ 19

6.1 Geração de par de chaves e instalação ....................................................................... 19

6.1.1 Para certificados do Tipo A3 emitidos pela AC TECNISIGN ..................................... 19

6.1.2 Mídia Armazenadora ................................................................................................. 19

6.2 Outros aspectos do gerenciamento de par de chaves ..................................................... 20

6.3 Dados de Ativação ........................................................................................................... 20

6.4 Controles de segurança computacional ........................................................................... 20

6.4.2 Controles Técnicos do Ciclo de Vida ............................................................................ 20

6.4.3 Controles de gerenciamento de segurança .................................................................. 20

6.4.4 Controles de Segurança do Ciclo de Vida .................................................................... 20

6.5 Controles de segurança de rede ...................................................................................... 20

6.6 Carimbo de Tempo .......................................................................................................... 20

7. PERFIS DE CERTIFICADO, CRL E OCSP ....................................................................... 20

7.1. Número (s) da versão .................................................................................................. 21

7.1.1 Extensões de Certificado ........................................................................................... 21

7.2 Perfil do Certificado.......................................................................................................... 21

7.2.1 Perfil do Certificado de AC ........................................................................................ 21

7.2.1 Perfil do Certificado de usuário final .......................................................................... 22

7.3 Subject Alternative Name ................................................................................................ 23

7.4. Requisitos CABF de nomes ............................................................................................ 24

7.4.1. Aplicação da RFC 5280 ............................................................................................ 24

7.4.2 Identificadores dos algoritmos ................................................................................... 24

7.4.2.1 Requisitos CABF para Identificadores de algoritmos ............................................. 25

7.4.3 Formatos de Nomes .................................................................................................. 25

7.4.3.1. Informações do emissor (Issuer) ........................................................................... 25

7.4.3.2.Informações do emitente (Subject) - Certificados de Usuário Final ........................ 25

7.4.3.2.1.1. Endereço IP Reservado ou Nome Interno ....................................................... 26

7.4.3.2.2. Requisitos CABF para o campo Subject Distinguished Name Fields ................. 26

7.4.3.3. Subject Information – para Certificados de AC Raiz e AC Subordinadas .............. 28

7.4.3.3.1. Subject Distinguished Name Fields .................................................................... 28

7.5 Requisitos CABF Restrições de Nome ............................................................................ 29

7.6 Identificador do Objeto da Política de Certificados .......................................................... 30

7.6.1. identificadores CP Reservados (Reserved CP Identifiers) ...................................... 30

7.6.2. Certificados de AC Raiz............................................................................................ 30

7.6.2.1 Certificados de AC Subordinadas ........................................................................... 30



7.6.2.2 Certificados de Usuário Final .................................................................................. 31

7.6.3 Requisitos CABF para PC Object Identifier .................................................................. 31

7.6.3.1 Requisitos CABF para PC Object Identifier para EV .............................................. 31

7.6.4 Uso da Extensão de Restrições de Políticas ............................................................. 31

7.6.5 Sintaxe e Semântica dos Qualificadores de Política ................................................. 31

7.6.6 Semântica de processamento para Extensões Críticas ............................................ 31

Não se aplica. ..................................................................................................................... 32

7.7 PERFIL DA LCR .............................................................................................................. 32

7.7.1 Versão ....................................................................................................................... 32

7.7.2 Extensões de LCR e suas entradas .......................................................................... 32

7.8 Perfil OCSP ..................................................................................................................... 33

7.8.1 Número (s) da versão ................................................................................................ 33

8. Auditoria de Conformidade e Outras Avaliações ............................................................... 33

9. Outros assuntos comerciais e legais ................................................................................. 33

Apêndice A: Tabela de Siglas e Acrônimos ........................................................................... 34

Apêndice B: Referências ....................................................................................................... 36



1. INTRODUÇÃO

Este documento, “Políticas de Certificados da AC TECNISIGN” (PC) é a principal política que rege a AC

TECNISIGN. A PC estabelece os requisitos comerciais, legais e técnicos para aprovação, emissão,

gerenciamento, uso, revogação e renovação de Certificados Digitais dentro da AC TECNISIGN e o

fornecimento de serviços de confiança associados para todos os participantes da AC TECNISIGN. Esses

requisitos protegem a segurança e a integridade da AC TECNISIGN e abrangem um único conjunto de

regras que se aplicam amplamente, proporcionando, assim, garantias de confiança uniforme em toda

a AC TECNISIGN. A PC não é um acordo legal entre a VALID e os participantes; em vez disso, as

obrigações contratuais entre a VALID e os participantes são estabelecidas por meio de acordos com

tais participantes. Este documento destina-se a:

• Prestadores de serviços de Infraestrutura de PKI da AC TECNISIGN que têm que operar em termos de

sua própria Declaração de Práticas de Certificação (DPC) e atender aos requisitos estabelecidos pela

PC;

• Assinantes dos certificados da AC TECNISIGN que precisam entender como são autenticados e quais

são suas obrigações como assinantes da AC TECNISIGN e como eles são protegidos pela AC TECNISIGN;

e

• Terceiros de confiança que precisam entender quanta confiança depositar em um certificado da AC

TECNISIGN ou uma assinatura digital usando esse certificado.

Esta PC está em conformidade com a RFC 3647 da Internet Engineering Task Force (IETF) para a

construção de Declaração de Práticas de Certificação e Política de Certificação.

Esta PC está em conformidade com a RFC 3647 da Força-Tarefa de Engenharia da Internet (IETF) para

a construção da Declaração de Práticas de Certificação e Política de Certificação.

A PC da AC TECNISIGN está em conformidade com a versão atual do:

a) CA/Browser Forum - Baseline Requirements Certificate Policy for the Issuance and Management of

Publicly-Trusted Certificates- versão 1.6.2 (disponível em https://cabforum.org/baseline-

requirements-documents/).

b) CA/Browser Forum - Guidelines For The Issuance And Management Of Extended Validation

Certificates – versão 1.6.8 (available at https://cabforum.org/extended-validation/); e

c) CA/Browser Forum - Guidelines For The Issuance And Management Of Extended Validation Code

Signing Certificates – versão 1.4 (available at https://cabforum.org/ev-code-signing-certificate-

guidelines/)

Em caso de inconsistência entre este documento e essas Diretrizes, este documento prevalece.

https://cabforum.org/baseline-requirements-documents/






https://cabforum.org/extended-validation/);

https://cabforum.org/ev-code-signing-certificate-guidelines/

https://cabforum.org/ev-code-signing-certificate-guidelines/



1.1 Visão geral

Esta Política de Certificados (PC) descreve as características e as utilizações dos certificados de Assinatura Digital que podem ser do tipo A3, emitidos pela Autoridade Certificadora AC TECNISIGN. A VALID e Afiliados podem agir como ARs para emissão de certificados. A VALID e Afiliadas também

celebram relações contratuais com empresas que desejam gerenciar suas próprias solicitações de

certificados.

1.2. Nome do documento e identificação

Esta PC é chamada “Política de Certificado de Assinatura Digital da Autoridade Certificadora AC TECNISIGN” e referida como “PC da AC TECNISIGN”. O Object Identifier (OID) atribuído para esta PC é 1.3.6.1.4.1.47402.2.8

1.2.1 Identificadores de Políticas de CABF

Não se aplica.

1.3 Comunidade (Participantes da PKI)

Esta PC é implementada pela Autoridade Certificadora AC TECNISIGN.

Os serviços de certificado de assinatura eletrônica da AC TECNISIGN estão incorporados em uma infraestrutura de confiança. Basicamente: Autoridade Certificadora (PSC), Autoridades de Registro (AR), assinante, terceiros que dependem de certificados e Entidade de Credenciamento.

1.3.1 Autoridade Certificadora

AC ou Autoridade Certificadora é a organização responsável pela criação, emissão, revogação e gerenciamento de Certificados.

O termo se aplica igualmente às ACs Raízes e ACs Subordinadas.

As práticas e procedimentos de certificação utilizados pela AC TECNISIGN estão descritas em sua Política de Certificado (PC da AC TECNISIGN), que se encontra publicada no seguinte endereço:

http://ac.tecnisign.net/ac-tecnisign/cps-ac-tecnisignv1.pdf

1.3.2 Autoridades de registro

Uma Autoridade de Registro (AR) é uma entidade que realiza identificação e autenticação de requerentes de certificado para usuários finais, inicia ou transfere solicitações de revogação de




certificados de usuários finais e aprova solicitações de renovação em nome da AC TECNISIGN. No caso de um terceiro agir, como agente de registro, a atividade deve ser realizada em total conformidade com o contrato de mandato e com esta Declaração de Práticas de Certificação. A VALID PODE atuar como uma AR para emissão de certificados.

Terceiras Partes que estabelecem uma relação contratual com a TECNISIGN PODEM operar sua própria AR e autorizar a emissão de certificados pela AC TECNISIGN. As ARs de terceiros DEVEM obedecer a todos os requisitos desta DPC da AC TECNISIGN, e os termos de seu contrato de serviços corporativos com a AC TECNISIGN. As ARs PODEM, no entanto, implementar práticas mais restritivas com base em seus requisitos internos.

Antes da VALID autorizar uma Terceira Parte a desempenhar uma função de AR, a VALID DEVERÁ exigir contratualmente que a Terceira Parte:

(1) Atender aos requisitos de qualificação da seção 5.3.1 da DPC, quando aplicável à função de AR;

(2) Guardar a documentação de acordo com a seção 5.5.2 da DPC;

(3) Cumprir as outras disposições destes Requisitos aplicáveis à função; e

(4) Cumprir com as políticas (DPC e PC) da AC VALID.

A VALID pode designar uma empresa como AR para verificar solicitações de certificados desta própria organização.

1.3.3 Candidato

As pessoas que aceitam solicitar um certificado digital, preenchem o formulário de solicitação e fornecem todo o histórico exigido por lei e esta PC para comprovar sua identidade de forma confiável.

1.3.4 Assinantes

Os assinantes (ou Subscritores ou Titulares) incluem todos os usuários finais (incluindo entidades) de certificados emitidos pela AC TECNISIGN. Um assinante é a entidade nomeada como usuário final de um certificado. Os assinantes PODEM ser indivíduos, organizações ou componentes de infraestrutura, como firewalls, roteadores, servidores confiáveis ou outros dispositivos usados para proteger comunicações dentro de uma organização.

Em alguns casos, os certificados são emitidos diretamente para indivíduos ou entidades para uso próprio. No entanto, geralmente existem outras situações em que a parte que requer um certificado é diferente do “subject” a quem o certificado se aplica. Por exemplo, uma organização PODE demandar certificados para seus funcionários para permitir que eles representem a organização em transações / negócios eletrônicos. Em tais situações, a entidade que subscreve a emissão de certificados (ou seja, paga por eles, seja através da subscrição de um serviço específico, quer como o próprio emissor) é diferente da entidade que é o “requerente” do certificado (geralmente, o detentor do certificado).

Dois termos diferentes são usados na Política de Certificado (PC) da AC TECNISIGN para distinguir entre esses dois papéis: "Assinante" é a entidade que contrata a VALID para a emissão de credenciais e;



"ASSUNTO (Requerente)" é a pessoa a quem a credencial está vinculada. O Assinante assume a responsabilidade final pelo uso do certificado, mas o ASSUNTO é o indivíduo que é autenticado quando o certificado é apresentado.

Quando "ASSUNTO" é usado é para indicar uma distinção do Assinante. Quando "Assinante" é usado, pode significar apenas o Assinante como uma entidade distinta, mas também pode usar o termo para abranger os dois. O contexto de uso na PC invocará o entendimento correto.

As ACs são tecnicamente também assinantes de certificados dentro da AC TECNISIGN, seja como uma AC que emite um certificado auto assinado para si, seja como uma AC que emitiu um Certificado por uma AC superior. As referências a "entidades finais" e "assinantes" na Política de Certificado (PC) da AC TECNISIGN, no entanto, aplicam-se apenas a usuários finais.

1.3.5 Partes Confiáveis

A parte Confiável é uma pessoa física ou jurídica que confia de um certificado e/ou assinatura digital emitida pela AC TECNISIGN. A Terceira parte Confiável pode ou não pode ser um assinante dentro da AC TECNISIGN.

A parte que confia deve ter mecanismos que permitam validar se é um certificado autêntico e se esse certificado era válido no momento em que a assinatura do documento foi produzida.

1.3.6 Entidade Credenciadora

A Direção-geral da Propriedade Intelectual (DIGEPIH) que está dentro do Instituto da Propriedade (IP). A Lei de Assinatura Eletrônica foi aprovada pelo Congresso Nacional sob o decreto número 149-2013 de 30 de julho de 2013.

1.3.7 Prestador de Serviço de Suporte

A AC TECNISIGN utiliza os seguintes Prestadores de Serviço de Suporte (PSS) nas suas operações: a) VALID CERTIFICADORA DIGITAL LTDA.

b) VALID SOLUÇÕES S.A.

PSS são entidades utilizados pela AC TECNISIGN e/ou suas ARs vinculadas para desempenhar atividade descrita nesta PC e DPC implementada pela AC TECNISIGN e se classificam em três categorias conforme o tipo de atividade prestada: a) disponibilização de infraestrutura física e lógica; b) disponibilização de recursos humanos especializados; ou c) disponibilização de infraestrutura física e lógica e de recursos humanos especializados.



1.3.8 Outros participantes

Não se aplica.

1.4 Titulares de Certificado

Podem ser titulares de certificados emitidos segundo esta PC pessoas físicas ou jurídicas de direito público ou privado, nacionais ou estrangeiras.

1.4.1 Aplicabilidade

1.4.1 Usos apropriados do certificado

1.4.1.1 Neste item são relacionadas as aplicações para as quais os certificados definidos por esta PC são adequados.

1.4.1.2 As aplicações e demais programas que admitem o uso de certificado digital de um determinado tipo, aceitam qualquer certificado de mesmo tipo, ou superior, emitido por qualquer AC credenciada.

1.4.1.3 A AC TECNISIGN leva em conta o nível de segurança previsto para o certificado definido por esta PC na definição das aplicações para o certificado. Esse nível de segurança é caracterizado pelos requisitos definidos para aspectos como: tamanho da chave criptográfica, mídia armazenadora da chave, processo de geração do par de chaves, procedimentos de identificação do titular de certificado, frequência de emissão da correspondente Lista de Certificados Revogados (LCR) e extensão do período de validade do certificado.

1.4.1.4 Os certificados emitidos pela AC TECNISIGN no âmbito desta PC podem ser utilizados em aplicações como:

• Assinatura digital em correio eletrônico;

• Assinatura digital de documentos utilizando software de assinatura elaborado por órgãos,

entidades ou empresas diversas;

• Confirmação de identidade na Web;

• Transações eletrônicas e transações on-line;

• Redes privadas virtuais (VPN);

• Cifração de chaves de sessão;

1.4.1.5 No caso de certificados de pessoas jurídicas, o “Termo de Titularidade”, poderá limitar as aplicações para as quais são adequados os certificados de assinatura tipo A3 emitidos pela AC TECNISIGN, determinando restrições ou proibições de uso destes certificados.



1.5 Administração de Políticas

1.5.1 Organização que administra o documento

VALID CERTIFICADORA DIGITAL LTDA.

Avenida Paulista, 2064 – 15. Andar

São Paulo/SP - Brasil

1.5.2 Dados de Contato

Normas e Compliance

VALID CERTIFICADORA DIGITAL LTDA.

Avenida Paulista, 2064 – 15. Andar

São Paulo/SP - Brasil

Telefone: (55) 11-2575-6800

E-mail: [email protected]

1.5.3 Pessoa que determina a adequação do DPC como política

O Departamento de Política de Gerenciamento da AC TECNISIGN, nomeado como "Padrões e Conformidade", determina a adequação e aplicabilidade da DPC.

O Departamento de Gerenciamento de Políticas - Departamento de Gerenciamento de Políticas (PMD) da AC TECNISIGN, nomeado como "Normas e Compliance" determina a adequação e aplicabilidade da DPC.

1.5.4 Procedimento de aprovação da PC

A aprovação desta PC e as subsequentes alterações serão feitas pelo Política de Gestão (PMD). As

alterações DEVEM ser apresentadas na forma de um documento que contenha um formulário alterado

da PC ou de um aviso de atualização.

Versões alteradas serão disponibilizadas em: http://ac.tecnisign.net/ac-tecnisign

Atualizações substituem quaisquer disposições designadas ou conflitantes da versão desta PC.

1.6 Definições e Acrônimos

1.6.1 Definições

Veja o apêndice A para uma tabela de definições.

http://ac.tecnisign.net/ac-tecnisign



1.6.2 Acrônimos

Veja o apêndice A para uma tabela de Acrônimos.

1.6.3. Referências

Veja o apêndice B para consultar a lista de referências.

1.6.4. Convenções

As palavras-chave "DEVE", "NÃO DEVE", "OBRIGATÓRIO", "DEVEM", "NÃO", "DEVEM", "NÃO

DEVEM", "RECOMENDADOS", "PODE", e "OPCIONAIS" nestes requisitos devem ser interpretadas de

acordo com a RFC 2119.

2. Responsabilidades de Publicação e Repositório

2.1 Repositório

Conforme descrito na Declaração de Práticas de Certificação da AC TECNISIGN.

2.2 Publicação da Informação do Certificado


2.3 Tempo ou frequência da publicação


2.4 Controles de Acesso em Repositórios


3. Identificação e Autenticação




3.1 NOMEAÇÃO

A menos que seja indicado o contrário nesta PC, e DPC, os nomes que aparecem em Certificados emitidos sob VALID são autenticados.

3.1.2 Necessidade de nomes serem significativos

Certificados da AC TECNISIGN, contém nomes com semânticas comumente entendido, permitindo a determinação da identidade da AC que é o “ASSUNTO” (SUBJECT) do certificado.

Os Certificados de usuário final devem conter nomes com semântica comumente entendida, permitindo a determinação da identidade do indivíduo ou organizações que é o “ASSUNTO” (SUBJECT) do certificado.

3.1.3 Anonimato ou pseudônimo de assinantes

Os assinantes não podem usar pseudônimos (nomes que não sejam o nome pessoal ou organizacional

verdadeiro do Assinante). Cada pedido de anonimato em um certificado será avaliado em seus méritos

pelo PMD e, se permitido, o certificado indicará que a identidade foi autenticada, mas está protegida.

3.1.4 Regras para Interpretar Vários Formulários de Nomes

Não se aplica.

3.1.5 Unicidade de Nomes

VALID e Afiliados asseguram através de componentes automatizados do processo de emissão do certificado que o Distinguished Name(DN) do assinante é único dentro do domínio de uma AC. É possível que um Assinante tenha 2 ou mais certificados com o mesmo Distinguished Name (DN).

3.1.6 Reconhecimento, Autenticação e Regras para Marcas Registradas

A VALID como prestadora de serviços da AC TECNISIGN, não assume compromissos na emissão de certificados sobre o uso de marcas. Os Candidatos ao Certificado NÃO DEVEM usar nomes em suas solicitações de certificado que infrinjam os Direitos de Propriedade Intelectual de terceiros. A VALID DEVE determinar se um solicitante de certificado possui Direitos de Propriedade Intelectual ao nome que aparece em um pedido de certificado ou para arbitrar, mediar ou resolver qualquer disputa relacionada à propriedade de qualquer nome de domínio, nome comercial, marca comercial ou marca de serviço.

A VALID tem o direito de rejeitar ou suspender qualquer Pedido de Certificado por causa de tal disputa.



3.2 Validação inicial de identidade

3.2.1 Método para comprovar a posse de chave privada

A VALID como provedor de serviços da AC TECNISIGN usa vários circuitos para a emissão de certificados onde a chave privada é gerenciada de maneira diferente. A chave privada pode ser gerada pelo usuário e para a Entidade Certificadora (EC).

O método para provar a posse de uma chave privada DEVE ser PKCS#10, outra demonstração

criptograficamente equivalente, ou outro método aprovado pela VALID. Este requisito não se aplica

quando um par de chaves é gerado por uma AC em nome de um Assinante.

a) Geração de chaves pela EC.

Em Hardware: As chaves podem ser entregues pela EC ao Assinante, diretamente ou através de uma

entidade de registro em um dispositivo de criação de assinatura qualificado.

b) Geração das chaves pelo Assinante.

O Assinante tem um mecanismo de geração de chaves, seja software ou hardware. A prova da posse

da chave privada nesses casos é a solicitação recebida pela EC no formato PKCS#10.

3.3 Informação Não Verificada do Subscritor

As informações do assinante não verificadas incluem: Unidade Organizacional (OU) com certas exceções; Qualquer outra informação designada como não verificada em sua PC.

3.4 Critérios de Interoperabilidade

A VALID PODE fornecer serviços de interoperabilidade que permitam que qualquer AC possa interoperar com a AC TECNISIGN certificando unilateralmente esta AC. As ACs autorizadas para interoperar dessa maneira estarão em conformidade com a AC TECNISIGN, conforme implementado por políticas adicionais, quando necessário. A AC TECNISIGN só permitirá a interoperabilidade com qualquer AC em circunstâncias em que a AC TECNISIGN no mínimo: • Entra em um acordo contratual com a VALID ou um Afiliado; • Opera sob uma DPC que atenda aos requisitos da AC TECNISIGN para o tipo de certificado que será emitido; • Passa uma avaliação de conformidade antes de ter permissão para interoperar; • Passa por uma avaliação de conformidade anual para elegibilidade contínua para interoperar.



A AC TECNISIGN DEVERÁ divulgar todas as certificações cruzadas que identificam a AC TECNISIGN como ASSUNTO, desde que a AC TECNISIGN tenha estabelecido ou aceito o estabelecimento da relação de confiança (ou seja, o certificado cruzado tenha sido emitido).

3.5 Identificação e Autenticação para solicitação de nova chave


3.6 Identificação e Autenticação para Solicitação de Revogação


4. REQUISITOS OPERACIONAIS DO CICLO DE VIDA DO CERTIFICADO


4.1. Solicitação de Certificado


4.2 Processo de Requisição de Certificado


4.3 Emissão de Certificado


4.4 Aceitação de Certificado


4.5 Par de chaves e uso do Certificado




4.6 Re-certificação do Certificado


4.7 Renovação do Certificado


4.8 Modificação do Certificado


4.9 Suspensão e Revogação de certificados


4.10 Serviços de Status do Certificado


4.11 Fim da subscrição


4.12 Custódia e Recuperação das Chaves


5. Instalações, Gerenciamento e Controles Operacionais


5.1 Controles Físicos




5.2 Controles procedimentais


5.3 Controles de pessoal


5.3.4 Frequência e Requisitos de Reciclagem


5.3.5 Frequência e sequência de rotação de trabalho


5.3.6 Sanções para Ações Não Autorizadas


5.3.7 Requisitos para terceiros independentes


5.3.8 Documentação Fornecida ao Pessoal


5.4 Procedimentos de Auditoria de Segurança


5.5 Arquivamento de Registros




5.6 Troca de Chaves


Comprometimento e recuperação de desastre


5.8 Extinção de AC ou AR


5.9 Segurança de dados


6.1 Geração de par de chaves e instalação

Quando o titular de certificado for uma pessoa física, esta será a responsável pela geração dos pares de chaves criptográficas.

Quando o titular de certificado for uma pessoa jurídica, esta indicará por seu(s) representante(s) legal(is), a pessoa responsável pela geração dos pares de chaves criptográficas e pelo uso do certificado.

6.1.1 Para certificados do Tipo A3 emitidos pela AC TECNISIGN

A geração do par de chaves criptográficas ocorre utilizando cartão inteligente ou token, ambos com capacidade de geração de chave e protegidos por senha, e/ou identificação biométrica.

Certificados do tipo A3 previstos nesta PC podem ter a validade de até 5 anos.

6.1.2 Mídia Armazenadora

Essa mídia de armazenamento não modifica os dados a serem assinados, nem impede que esses dados sejam apresentados ao signatário antes do processo de assinatura.

TIPO DE CERTIFICADO

MÍDIA ARMAZENADORA DE CHAVE CRIPTOGRÁFICA (Requisitos Mínimos)

A3 Cartão Inteligente ou Token, ambos com capacidade de geração de chave e protegidos por senha e/ou identificação biométrica, ou hardware criptográfico homologado.



Tabela - Mídia Armazenadora

6.2 Outros aspectos do gerenciamento de par de chaves

Conforme descrito na Declaração de Práticas de Certificação a AC TECNISIGN.

6.3 Dados de Ativação


6.4 Controles de segurança computacional


6.4.2 Controles Técnicos do Ciclo de Vida


6.4.3 Controles de gerenciamento de segurança


6.4.4 Controles de Segurança do Ciclo de Vida


6.5 Controles de segurança de rede


6.6 Carimbo de Tempo


7. PERFIS DE CERTIFICADO, CRL E OCSP

Todos os Certificados e Listas de Revogação de Certificados DEVEM cumprir com a RFC 5280.



7.1. Número (s) da versão

Os Certificados da AC TECNISIGN e Certificados de assinantes são do tipo X.509 Versão 3.

7.1.1 Extensões de Certificado

A VALID pode preencher os Certificados da AC TECNISIGN X.509 Versão 3 com as extensões exigidas por esta Seção.

7.2 Perfil do Certificado

Os certificados da AC TECNISIGN estão em conformidade com (a) ITU-T Recommendation X.509 (1997): Information Technology - Open Systems Interconnection - The Directory: Authentication Framework, June 1997 and (b) RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile, April 2002 (“RFC 5280”).

Conforme aplicável ao tipo de certificado, os Certificados da AC TECNISIGN estão em conformidade com a versão atual da CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates.

7.2.1 Perfil do Certificado de AC

Para o certificado da AC TECNISIGN contém: - um nome distinto X.501 (DN) no Common Name dos campos Issuer e Subject, - pode conter vários atributos OU, - seu DN é formado como abaixo:

Campo em português(Atributo)

Campo em inglês (Attribute)

Campo em inglês (Value) Campo em português (Valor)

País Country (C) = 2-letter ISO country code 2-letras Código do País ISO

Organização Organization (O) = <organization name> < VALID CERTIFICADORA DIGITAL LTDA >

Nome Comum Common Name (CN) = < Name of AC> < Nome da AC >

Tabela Atributos de nome distinto em certificados de AC Sendo:

Emissor:

CN = VALID ROOT CA

O = VALID CERTIFICADORA DIGITAL LTDA

C = BR



Requerente:

CN = AC TECNISIGN V1

OU = VALID ROOT CA

O = VALID CERTIFICADORA DIGITAL LTDA

C = HN

Para identificar um Assinante, as ACs QUE emitem certificados para usuários finais, devem seguir as regras de nomenclatura e identificação que incluem tipos de nomes atribuídos ao Assunto, como nomes distintos X.500 RFC-822 e nomes X.400. Onde DNs (Distinguished Name) são usados, os CNs (Common Name)

7.2.1 Perfil do Certificado de usuário final

Os certificados de usuário final contém: - um nome distinto X.501 Distinguished Name (DN) no Common Name dos campos Issuer e Subject; - pode conter vários atributos OU; - seu Distinguished Name (DN) é formado como abaixo:

Campo em português(Atributo)

Campo em inglês (Attribute)

Campo em inglês (Value) Campo em português (Valor)

País Country (C) = 2-letter ISO country code 2-letras Código do País ISO

Organização Organization (O) = <organization name> < Nome da organização>

Unidade Organizacional Organizational Unit (OU) = < organizational unit > <unidade de organização>

Estado ou Província State or Province (ST) = Indicates the State or Province of the

Subscriber (OPTIONAL

Indica o Estado ou a Província do

Assinante

Localidade Locality (L) =

Indicates the Subscriber’s Locality

(Locality is not a REQUIRED field in

certificates issued to individuals).

(Optional)

Indica a localidade do assinante

Nome Comum Common Name (CN) =

Organization name (for corporate

certificates)

Name of person (for physical certificates

Nome da organização (para certificados

de pessoa jurídica)

Nome da pessoa (para certificados

pessoa física

Tabela - Atributos de Nome Distintos em Certificados de Usuário Final

NOTA 1: Será escrito o nome até o limite do tamanho do campo disponível, vedada à abreviatura. NOTA 2: Caso qualquer um dos campos OU acima não seja utilizado, o mesmo será grafado com o texto "(EM BRANCO)".



NOTA 3: Campo Locality (L) para certificados de pessoa física é um campo opcional, para certificados de pessoa jurídica o conteúdo corresponde ao nome da cidade onde a empresa está localizada. O campo deve ser preenchido sem acentos nem abreviaturas.

7.3 Subject Alternative Name

A AC TECNISIGN implementa nos certificados emitidos segundo esta PC a extensão “Subject Alternative Name", definida como obrigatória, não crítica, com os seguintes formatos:

a) Para Certificados de Pessoa Física

a.1) campo otherName, não obrigatório, contendo:

i. campo rfc822Name contendo o endereço e-mail do titular do certificado.

ii. campo otherName com OID = 1.3.6.1.4.1.311.20.2.3 e conteúdo UPN (User Principal Name), com a identificação do endereço de login do titular do certificado no diretório ActiveDirect (AD) Microsoft. Esse campo é aplicável apenas em certificados utilizados para logon de rede.

a.2) extensão "Extended Key Usage", não crítica, contendo o valor:

i. "client authentication" (id-kp-clientAuth) (OID 1.3.6.1.5.5.7.3.2);

ii. "e-mail protection" (id-kp-emailProtection) (OID 1.3.6.1.5.5.7.3.4);

iii. “smart card logon” (id-ms-kp-smartcard-logon) (OID 1.3.6.1.4.1.311.20.2.2). Esse campo é aplicável apenas em certificados utilizados para logon de rede.

b) Para Certificados de Pessoa Jurídica

b.1) extensão “Subject Alternative Name”

i. sub-extensão "rfc822Name", contendo o endereço e-mail da Pessoa Jurídica titular do certificado.

ii. campo otherName com OID = 1.3.6.1.4.1.311.20.2.3 e conteúdo UPN (User Principal Name), com a identificação do endereço de login do titular do certificado no diretório ActiveDirect (AD) Microsoft. Esse campo é aplicável apenas em certificados utilizados para logon de rede.

b.2) extensão "Extended Key Usage", não crítica, contendo o valor:

i. "client authentication" (id-kp-clientAuth) (OID 1.3.6.1.5.5.7.3.2);

ii. "e-mail protection" (id-kp-emailProtection) (OID 1.3.6.1.5.5.7.3.4);

iii. “smart card logon” (id-ms-kp-smartcard-logon) (OID 1.3.6.1.4.1.311.20.2.2) Esse campo é aplicável apenas em certificados utilizados para logon de rede.



7.4. Requisitos CABF de nomes

Os Certificados estão em conformidade com os requisitos do CA/Browser Forum Baseline Requirement. Campos do Emissor Os seguintes atributos de nomenclatura DEVERÃO ser usados para preencher o Emissor em certificados emitidos sob esta PC. CountryName (REQUERIDO) O componente countryName (C =) é NECESSÁRIO e contém o código de país ISO 3166-1 de duas letras para o país no qual o local de negócios do emissor está localizado. Nome da organização (REQUERIDO) O campo organizationName (O =) é NECESSÁRIO e contém o nome da organização do Emissor (ou sua abreviação), marca comercial ou outro identificador significativo para a AC, que identifica precisamente a AC. O campo NÃO DEVE conter uma designação genérica como "Root" ou "CA1". Nome da AC commonName (OPCIONAL) Se o campo Issuer commonName (CN =) estiver presente, DEVE conter um nome que identifique com precisão a AC de emissão. Campos de SUBJECT Os seguintes atributos DEVEM ser usados para preencher o SUBJECT em certificados emitidos sob esta PC: subjectAlternativeName (REQUERIDO) - A extensão subjectAlternativeName é REQUERIDA e contém pelo menos uma entrada. - Nos Certificados SSL, cada entrada é um dNSName contendo o FQDN ou um iPAddress contendo o endereço IP de um servidor. - A AC TECNISIGN confirma que o Solicitante controla o FQDN ou o endereço IP ou que recebeu o direito de usá-lo pelo Responsável pelo Domínio ou pelo Responsável pelo endereço IP, conforme apropriado. - FQDNs com asterico (*) são permitidos. - A emissão de um certificado com uma extensão subjectAlternativeName ou um campo SubjectNameName contendo um endereço IP reservado ou um nome interno do servidor NÃO é permitido.

7.4.1. Aplicação da RFC 5280


7.4.2 Identificadores dos algoritmos

Os Certificados da VALID são assinados usando um dos seguintes algoritmos: sha256withRSAEncryption OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549)

pkcs(1) pkcs-1(1) 11}



ecdsa-with-Sha256 OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2 (3) 2}

ecdsa-with-Sha512 OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2 (3) 4}

sha-512WithRSAEncryption OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 13}

sha512withRSAEncryption Assinaturas de certificado produzidas usando esses algoritmos DEVEM estar em conformidade com a RFC 3279.

7.4.2.1 Requisitos CABF para Identificadores de algoritmos

As ACs NÃO DEVEM emitir novos certificados de assinante ou ACs Subordinadas usando o algoritmo de hash SHA- 1. Esta seção não se aplica à AC raiz ou AC de certificação cruzada.

7.4.3 Formatos de Nomes

Os certificados da VALID são preenchidos com o nome do emissor e o nome distinto do Assunto requeridos pela seção 3.1.1 da DPC. Os certificados da AC TECNISIGN são preenchidos com o Nome do Emissor e o Nome Distinto do Assunto requeridos pela Seção 7.1.2 da sua PC.

7.4.3.1. Informações do emissor (Issuer)

O conteúdo do campo Nome Distinto do Emissor do Certificado DEVE corresponder ao DN do Assunto da AC de Emissão para suportar o encadeamento de Nome, conforme especificado na RFC 5280, seção 4.1.2.4.

7.4.3.2.Informações do emitente (Subject) - Certificados de Usuário Final

Ao emitir o Certificado, a VALID declara que seguiu o procedimento estabelecido em suas políticas (DPC e PC) para verificar se, a partir da data de emissão do Certificado, todas as Informações do Assunto estavam corretas. Para Certificados SSL, o VALID incluirá um nome de domínio ou endereço IP em um atributo Subject.

7.4.3.2.1. CABF Subject Alternative Name Extension Requirements Campo de certificado: extensões: subjectAltName Obrigatório / Opcional: Obrigatório



Conteúdo:

A extensão subjectAlternativeName é OBRIGATÓRIA e contém pelo menos uma entrada.

Nos Certificados SSL, cada entrada é um dNSName contendo o FQDN ou um iPAddress contendo o endereço IP de um servidor.

A AC TECNISIGN confirma que o solicitante controla o FQDN ou o endereço IP ou recebeu o direito de usá-lo pelo Responsável pelo Nome de Domínio ou pelo Responsável pelo endereço IP, conforme apropriado.

Wildcard FQDNs são permitidos.

7.4.3.2.1.1. Endereço IP Reservado ou Nome Interno

A AC deve notificar o requerente de que o uso de tais Certificados foi proibido pelo CA / Browser Forum e que a prática foi eliminada em outubro de 2016 e não emitirá um certificado com uma extensão subjectAlternativeName ou Subject commonName contendo um Endereço IP Reservado ou Nome Interno.

7.4.3.2.2. Requisitos CABF para o campo Subject Distinguished Name Fields

1. Campo de Certificado: subject: commonName (OID 2.5.4.3) Necessário / Opcional: Reprovado (Desencorajado, mas não proibido) Conteúdo: Se presente, commonName MUST contém um Nome FQDN que também é um dos valores contidos na extensão subjectAlternativeName do Certificado.

2. Campo do Certificado: subject: organizationName (OID 2.5.4.10)

Obrigatório / Opcional: Obrigatório. Conteúdo: Ele DEVE conter o nome Subject da AC ou o DBA. Se o subject for uma pessoa natural, porque os atributos de nome de ASSUNTO para indivíduos (por exemplo, givenName (2.5.4.42) e sobrenome (2.5.4.4) não são amplamente suportados pelo software aplicativo, a AC PODE usar o campo subject: organizationName para transmitir o nome do ASSUNTO ou DBA. Se os campos incluírem discrepâncias que a AC considere menores, como variações e abreviações comuns, a AC DEVE documentar a discrepância e DEVE usar abreviações aceitas localmente ao abreviar o nome da organização (por exemplo, se o registro oficial mostrar "Nome da Empresa Incorporado"), a AC DEVE inclui “Company Name, Inc.”).

3. Campo de Certificação: subject: givenName (2.5.4.42) e subject: surname (2.5.4.4)

Obrigatório / Opcional: Opcional. Conteúdo: Se presente, o ASSUNTO: campo givenName e campo Assunto: Nome de Sobrenome DEVE conter um nome de pessoa física como verificado na Seção 7 Um Certificado contendo um ASSUNTO: c givenName field ou subject:surname: o campo sobrenome deve conter o OID da PC (2.23.140.1.2.3)



4. Campo do certificado: Número e rua: subject: streetAddress (OID: 2.5.4.9)

Obrigatório / Opcional: . Opcional se o SUBJECT: campo organizationName, givenName field, ou subject: os campos estão presentes Proibido se o subject: campo organizationName, ASSUNTO: givenName e subject: campo sobrenome estão ausentes. Conteúdo: Se estiver presente, o campo subject: streetAddress deveconter as informações do endereço da pessoa, conforme verificado na Seção 3.2.2.1.

5. Campo do Certificado: subject: localityName (OID: 2.5.4.7)

Obrigatório / Opcional: Obrigatório Se o subject: campo organizationName, assunto: campo givenName ou assunto: campo sobrenome estão presentes e o campo assunto: stateOrProvinceName está ausente. Opcional se o campo assunto: stateOrProvinceName e o assunto: campo organizationName, assunto: campo givenName ou assunto: campo sobrenome estiverem presentes. Proibido se o assunto: campo organizationName, assunto: givenName e assunto: sobrenome estão ausentes. Conteúdo: Se presente, o campo assunto: localityName DEVE conter as informações de localidade do subject, conforme verificado na Seção 3.2.2.1. Se o campo assunto: countryName especificar o código atribuído pelo usuário ISO 3166‐1 de acordo com a Seção 7.1.4.2.2 (g), o campo localityName PODE conter a localidade do Assunto e / ou informações do estado ou província, conforme verificado em Seção 3.2.2.1.

6. Campo de Certificado: subject: stateOrProvinceName (OID: 2.5.4.8) Obrigatório / Opcional: Obrigatório se o ASSUNTO: campo organizationName, ASSUNTO: campo givenName ou ASSUNTO: campo sobrenome estão presentes e ASSUNTO: campo localityName está ausente. Opcional se o ASSUNTO: campo localityName e o ASSUNTO: campo organizationName e ASSUNTO: campo givenName ou ASSUNTO: campo sobrenome estão presentes. Proibido se o ASSUNTO: campo organizationName, ASSUNTO: campo givenName ou ASSUNTO: campo sobrenome estão ausentes. Conteúdo: Se presente, o campo ASSUNTO: stateOrProvinceName deve conter as informações de estado ou província do Assunto, conforme verificado na Seção 3.2.2.1. Se o campo ASSUNTO: countryName especificar o código atribuído pelo usuário ISO 3166‐1 de acordo com a Seção 7.1.4.2.2 (g), o campo ASSUNTO: stateOrProvinceName PODE conter o nome completo das informações do país do Assunto, conforme verificado em Seção 3.2.2.1.

7. Campo do Certificado: subject: postalCode (OID: 2.5.4.17)

Obrigatório / Opcional: Opcional se os campos subject: organizationName, subject: givenName ou subject: sobrenome estiverem presentes. Proibido se o ASSUNTO: campo organizationName, ASSUNTO: campo givenName ou ASSUNTO: campo sobrenome estão ausentes.



Conteúdo: Se estiver presente, o campo subject: postalCode DEVE conter as informações de zip ou postal do Assunto, conforme verificado na Seção 3.2.2.1. 8. Campo do Certificado: subject: countryName (OID: 2.5.4.6)

Obrigatório / Opcional: Obrigatório se o ASSUNTO: campo organizationName, ASSUNTO: givenName ou ASSUNTO: sobrenome estão presentes. Opcional se o ASSUNTO: campo organizationName, ASSUNTO: campo givenName e ASSUNTO: campo sobrenome estão ausentes. Conteúdo: Se o campo subject: organizationName estiver presente, o ASSUNTO: countryName DEVE conter o código de país ISO 3166‐1 de duas letras associado\á localização do ASSUNTO verificado na Seção 3.2.2.1. Se o campo subject: organizationName estiver ausente, o ASSUNTO: countryName MAY conterá o código de país ISO 3166‐1 de duas letras associado ao Assunto, conforme verificado de acordo com a Seção 3.2.2.3.

Se um país não estiver representado por um código de país oficial da norma ISO 3166‐1, a AC TECNISIGN pode especificar o código atribuído pelo usuário ISO 3166‐1 de XX, indicando que um código ISO 3166‐1 alfa-2 oficial não foi atribuído. 9. Campo de certificado: SUBJECT: organizationalUnitName

Obrigatório / Opcional: Opcional. A AC implementa um processo que impede que um atributo OU inclua um nome, DBA, nome comercial, marca registrada, endereço, local ou outro texto que se refira a uma pessoa física ou jurídica específica, a menos que a AC tenha verificado essas informações de acordo com a seção da PC 7. e o Certificado também contém os seguintes atributos: organizationName, subject: localityName e subject: countryName, também verificados de acordo com a seção 7 da PC.

10. Outros Atributos do Assunto

Atributos opcionais, quando presentes no campo ASSUNTO, devem conter informações que foram verificadas pela AC. Metadados como '.', '-' e '' (ou seja, espaço) caracteres, e / ou qualquer outra indicação de que o valor está ausente, incompleto ou não aplicável, não devem ser usados.

7.4.3.3. Subject Information – para Certificados de AC Raiz e AC Subordinadas

Ao emitir um Certificado de AC Subordinada, a AC TECNISIGN, declara que seguiu o procedimento estabelecido na DPC e nesta PC para verificar se, a partir da data de emissão do Certificado, todas as Informações sobre o SUBJECT estavam corretas.

7.4.3.3.1. Subject Distinguished Name Fields

1. Campo do Certificado: subject: commonName (OID 2.5.4.3)



Obrigatório / Opcional: Obrigatório

Conteúdo: Este campo deve estar presente e o conteúdo deve ser um identificador para o certificado, de forma que o nome do certificado seja único em todos os certificados emitidos pelo certificado de emissão.

2. Campo do Certificado: subject:organizationName (OID 2.5.4.10)

Obrigatório / Opcional: Obrigatório.

Conteúdo: Ele deve conter o nome da AC conforme verificado na Seção 3.2.2.2.

Se o assinante for uma pessoa física, porque os atributos de nome de sujeito para indivíduos (por exemplo, givenName e surname não são amplamente suportados pelo software aplicativo, a AC pode usar o campo subject: organizationName para transmitir o Subject Name.

Se os campos incluírem discrepâncias que a AC considere menores, como variações e abreviações comuns, a AC deve documentar a discrepância e deve usar abreviações aceitas para abreviar o nome da organização (por exemplo, se o registro oficial mostrar “Nome da Empresa Limitada”, a AC pode incluir “Nome da Empresa Ltda.”).

3. Campo do Certificado: subject: countryName (OID: 2.5.4.6)

Obrigatório / Opcional: Obrigatório

Conteúdo: Este campo deve conter o código de país ISO 3166‐1 de duas letras para o país no qual o local de negócios da AC está localizado.

7.5 Requisitos CABF Restrições de Nome

Para que um certificado de AC subordinada seja considerado tecnicamente restrito, o certificado deve incluir:

Extensão EKU (Extended Key Usage), que especifica todos os usos de chaves estendidos para os quais o Certificada AC subordinado está autorizado a emitir certificados. O anyExtendedKeyUsage KeyPurposeId não deve aparecer dentro desta extensão.

Se o certificado de AC subordinada incluir o uso da chave estendida id-kp-serverAuth, a AC Subordinada o certificado deve incluir a extensão X.509v3 de restrições de nome com restrições no dNSName, iPAddress e DirectoryName da seguinte forma:

(a) Para cada dNSName em permittedSubtrees, a AC TECNISIGN deve confirmar que o Requerente registrou o dNSName ou foi autorizado pelo registrante de domínio a agir em nome do registrante, de acordo com as práticas de verificação da seção 3.2.2.4.



(b) Para cada faixa de iPAddress em permittedSubtrees, a AC TECNISIGN deve confirmar que o candidato recebeu a faixa do iPAddress ou foi autorizado pelo remetente a agir em nome do destinatário.

(c) Para cada DirectoryName em permittedSubtrees, a AC TECNISIGN deve confirmar o nome e localização Organizacional e / ou Candidatos da Subsidiária, para que os certificados da entidade final emitidos a partir do Certificado AC subordinado estejam em conformidade com a secção 7.1.2.

Se o certificado da AC subordinada não tiver permissão para emitir certificados com um iPAddress, o certificado de AC subordinada deve especificar os intervalos de endereços IPv4 e IPv6 completos nos subtrados excluídos. O Certificado de AC Subordinada deve incluir dentro de excludedSubtrees um iPAddress GeneralName de 8 octetos zero (cobrindo o intervalo de endereços IPv4 de 0.0.0.0/0). O Certificado de AC Subordinada DEVE incluir também dentro do excludedSubtrees um IPAddress GeneralName de 32 octetos zero (cobrindo o intervalo de endereços IPv6 de: 0/0).

Caso contrário, o certificado de AC Subordinada deve incluir pelo menos um iPAddress nos subdomínios permitidos.

Se a AC subordinada não tiver permissão para emitir certificados com dNSNames, o certificada da AC subordinada deve incluir um dNSName de comprimento zero em excludedSubtrees. Caso contrário, o certificado da AC subordinada deve incluir pelo menos um dNSName em permittedSubtrees.

7.6 Identificador do Objeto da Política de Certificados

Quando a extensão de Políticas de Certificados é usada, os certificados contêm o identificador de objeto (OID) para a Política de Certificado correspondente ao tipo apropriado de Certificado.

7.6.1. Identificadores CP Reservados (Reserved CP Identifiers)

Não se aplica.

7.6.2. Certificados de AC Raiz

Um certificado de AC raiz não deve conter a extensão certificatePolicies.

7.6.2.1 Certificados de AC Subordinadas

Um certificado emitido para uma AC subordinada que não é uma afiliada para emissão de AC: 1. DEVE incluir um ou mais identificadores de política explícitos que indiquem a aderência e conformidade da AC Subordinada a esses Requisitos (ou seja, os identificadores ou identificadores reservados do Ac / Navegador definido por AC TECNISIGN nesta DPC e PC) e



2. NÃO DEVE conter o identificador “anyPolicy” (2.5.29.32.0). Um certificado emitido para uma AC subordinada que é afiliada da emissão de AC: 1. PODE incluir os identificadores reservados da CA/Browser Forum ou um identificador definido pela AC TECNISIGN nesta DPC e PC para indicar a conformidade da AC Subordinada com estes Requisitos e 2. PODE conter o identificador “anyPolicy” (2.5.29.32.0) no lugar de um identificador de política explícito. Uma AC subordinada deve informar, nesta DPC e PC, que todos os Certificados contendo um identificador de política indicando a conformidade com estes Requisitos são emitidos e gerenciados de acordo com estes Requisitos.

7.6.2.2 Certificados de Usuário Final

Um Certificado emitido para um Assinante deve conter um ou mais identificadores de política, definidos pela AC de Emissão, na extensão certificatePolicies do Certificado, que indica a adesão e a conformidade com estes Requisitos. As Autoridades de Certificação que atendem a esses requisitos também podem declarar um dos OIDs de política reservados em tais Certificados. A AC emissora deve documentar nesta DPC e PC que os Certificados que ela emite contendo os identificadores de política especificados são gerenciados de acordo com estes Requisitos.

7.6.3 Requisitos CABF para PC Object Identifier

7.6.3.1 Requisitos CABF para PC Object Identifier para EV

Não se aplica.

7.6.4 Uso da Extensão de Restrições de Políticas

Não se aplica.

7.6.5 Sintaxe e Semântica dos Qualificadores de Política

A VALID emite os Certificados da AC TECNISIGN na Versão 3 do X.509 com um Policy Qualifiers dentro da extensão de Políticas de Certificação. Os Certificados contêm um Policy Qualifiers na DPC que aponta para o Contrato de Parte Confiável aplicável ou DPC da AC TECNISIGN. Além disso, alguns Certificados contêm um Qualificador de Notificação do Usuário que aponta para o Contrato de Parte Confiável aplicável.





7.6.6 Semântica de processamento para Extensões Críticas

Não se aplica.

7.7 PERFIL DA LCR

Conforme aplicável ao tipo de Certificado, as LCRs correspondentes estão em conformidade com a versão atual do CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. As LCRs estão em conformidade com o RFC 5280 e contêm os campos e conteúdos básicos especificados na Tabela abaixo:

Campo em português

Campo em inglês

Campo em inglês Value or Value constraint Campo em português Value or Value constraint

Versão Version See Section 7.2.1. Ver seção 7.2.1.

Algoritmo de assinatura

Signature Algorithm

Algorithm used to sign the CRL in accordance with RFC 3279.

Algoritmo usado para assinar a LCR de acordo com a RFC 3279.

Emissor Issuer Entity who has signed and issued the CRL Entidade que assinou e emitiu a LCR

Data efetiva Effective Date

Issue date of the CRL. CRLs are effective upon issuance.

Data de emissão da LCR. LCR são eficazes no momento da emissão.

próxima atualização

Next Update Date by which the next CRL will be issued. CRL issuance frequency is in accordance with the requirements of Section 4.9.7

Data em que a próxima LCR será emitida. A frequência de emissão da LCR está em conformidade com as exigências da Seção 4.9.7

Certificados revogados Revoked

Certificates

Listing of revoked certificates, including the Serial Number of the revoked Certificate and the Revocation Date

Listagem de certificados revogados, incluindo o Número de Série do Certificado revogado e a Data de Revogação

Tabela – Peril de LCR - Campos Básicos

7.7.1 Versão

A AC TECNISIGN suporta CRLs X.509 e atende aos requisitos do RFC 5280.

7.7.2 Extensões de LCR e suas entradas

7.7.2.1 A AC TECNISIGN adota as seguintes extensões de LCR definidas como obrigatórias:

a) “Authority Key Identifier”, não crítica: contém o resumo SHA-1 da chave pública da AC TECNISIGN que assina a LCR; e

b) “CRL Number”, não crítica: contém número sequencial para cada LCR emitida.

c) “Authority Information Access”, não crítica: contém o método de acesso id-ad-caIssuer, utilizando o protocolo de acesso HTTP, para a recuperação da cadeia de certificação no seguinte endereço: http://ac.tecnisign.net/ac-tecnisign/lcr-ac-tecnisignv1.crl

http://ac.tecnisign.net/ac-tecnisign/lcr-ac-tecnisignv1.crl



http://ac2.tecnisign.net/ac-tecnisign/lcr-ac-tecnisignv1.crl

7.8 Perfil OCSP

O OCSP (Protocolo de Status de Certificados Online) é uma maneira de obter informações atualizadas sobre o status de revogação de um determinado certificado. Os Certificados SSL validados pelo domínio e validados pela organização estão em conformidade com os requisitos do CA/Browser Forum Baseline Requirements. As respostas do OCSP DEVEM obedecer ao RFC 5019 e devem ser:

Assinado pela AC TECNISIGN que emitiu os Certificados cujo status de revogação está sendo verificado, ou

Assinado por um Respondente OCSP cujo Certificado é assinado pela AC TECNISIGN que emitiu o certificado cujo status de revogação está sendo verificado. Esse certificado de assinatura do Respondente OCSP DEVE conter a extensão id-pkix-ocsp-nocheck, conforme definido pelo RFC6960.

A AC TECNISIGN, utilizando o protocolo de acesso HTTP, com o respectivo endereço do respondedor OCSP no seguinte endereço: http://ocsp.tecnisign.net

7.8.1 Número (s) da versão

A versão 1 da especificação do OCSP, conforme definido pela RFC6960 e Versão 1 da especificação do OCSP, conforme definido pelo RFC 5019, é suportada. O Serviço VALID usa um registro de data e hora seguro e um período de validade para estabelecer a atualização atual de cada resposta de OCSP. A VALID não usa um nonce para estabelecer a atualização de cada respostade OCSP e os clientes não devem esperar um nonce na resposta a um pedido que contenha um nonce. Em vez disso, os clientes devem usar o relógio local para verificar o a atualização de reposta.

8. Auditoria de Conformidade e Outras Avaliações


9. Outros assuntos comerciais e legais


http://ac2.tecnisign.net/ac-tecnisign/lcr-ac-tecnisignv1.crl

http://ocsp.tecnisign.net/



Apêndice A: Tabela de Siglas e Acrônimos

Termo em Portugues Termo em ingles Definição

Participante da AC AC Participant Um indivíduo ou organização que tem um ou mais dos seguintes papeis dentro da infraestrutura da AC: AC VALID, Afiliado, Cliente, assinante ou Parte Confiável

PKI AC AC PKI consiste em sistemas que colaboram para fornecer e implementar AC

Repositório da AC AC Repository banco de dados de certificados e outras informações relevantes da AC acessível on-line

Padrões da AC AC Standards Padrões legais e exigências técnicas utilizadas pela AC para a emissão, administração, revogação, renovação e uso de Certificados

Administrador Administrator Uma pessoa de confiança dentro da organização de uma AC ou AR que executa funções de validação da AR ou AC

Certificado de administrador

Administrator Certificate

Um certificado emitido a um administrador que só pode ser utilizado para executar funções de AC ou

AR

Afiliado Affiliate Uma terceira parte confiável (corporação, parceria, joint venture ou outra entidade controladora, controlada ou sob controle comum com outra entidade) que entrou em um acordo com a AC VALIDpara ser uma distribuidora de serviços ou AR dentro de um território específico

AICPA AICPA Instituto Americano de Contadores Públicos Certificados

ANSI ANSI O American National Standards Institute

Requerente Applicant

A pessoa física ou jurídica que requer um certificado ou sua renovação. Uma vez que o certificado seja emitido, o Requerente é referido como “Assinante”. Para Certificados emitidos para dispositivos, o requerente é a entidade que controla ou opera o dispositivo nomeada no certificado



Representante do

Requerente

Applicant Representative

Uma pessoa física que representa o requerente, tendo autoridade expressa para representar o requerente: (i) que solicita o certificado em nome do requerente, e /ou (ii) que assina e envia o Contrato de Assinante em nome do Requerente, e/ou (iii) que reconhece e concorda com os Termos de Uso do Certificado em nome do Requerente

Carta confirmatória Attestation Letter

Uma carta atestando determina informação no processo de requisição do certificado

Período de auditoria Audit Period o período compreendido entre o primeiro dia (início) e o último dia de operações (final) coberto pela análise. (o que é diferente do período de tempo em que os auditores estão realizando a auditoria ).

Relatório de auditoria Audit Report Um relatório de um auditor qualificado afirmando opinião do auditor qualificado sobre se os processos e controles de uma entidade em conformidade com as disposições obrigatórias dessas exigências

Autorização de Domain Name

Authorization Domain Name

Autorização para uso do Domain Name usado na emissão de certificado para um determinado

Tabela - Siglas e Definições



Apêndice B: Referências

• CA/Browser Forum - Baseline Requirements Certificate Policy for the Issuance and

Management of Publicly-Trusted Certificates- version 1.6.7 (available at

https://cabforum.org/baseline-requirementsdocuments/)

• CA/Browser Forum - Guidelines For The Issuance And Management Of Extended Validation

Certificates – version 1.6.8 (available at https://cabforum.org/extended-validation/)

• ETSI EN 319 403, Electronic Signatures and Infrastructures (ESI); Trust Service Provider Conformity Assessment ‐ Requirements for conformity assessment bodies assessing Trust Service Providers.

• ETSI EN 319 411‐1, Electronic Signatures and Infrastructures (ESI); Policy and security

requirements for Trust Service Providers issuing certificates; Part 1: General requirements.

• ETSI TS 102 042, Electronic Signatures and Infrastructures (ESI); Policy requirements for

certification authorities issuing public key certificates.

• FIPS 140‐2, Federal Information Processing Standards Publication ‐ Security Requirements For

Cryptographic Modules, Information Technology Laboratory, National Institute of Standards

and Technology, May 25, 2001.

• ISO 21188:2006, Public key infrastructure for financial services ‐‐ Practices and policy

framework.

Network and Certificate System Security Requirements, v.1.0, 1/1/2013.

• NIST SP 800‐89, Recommendation for Obtaining Assurances for Digital Signature Applications,

https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-89.pdf.

• RFC2119, Request for Comments: 2119, Key words for use in RFCs to Indicate Requirement

Levels, Bradner, March 1997.

• RFC2527, Request for Comments: 2527, Internet X.509 Public Key Infrastructure: Certificate

Policy and Certification Practices Framework, Chokhani, et al, March 1999.


Policy and Certification Practices Framework, Chokhani, et al, November 2003.

• RFC4366, Request for Comments: 4366, Transport Layer Security (TLS) Extensions, Blake‐

Wilson, et al, April 2006.

• RFC5019, Request for Comments: 5019, The Lightweight Online Certificate Status Protocol

(OCSP) Profile for High‐Volume Environments, A. Deacon, et al, September 2007.


and Certificate Revocation List (CRL) Profile, Cooper et al, May 2008.

• RFC6844, Request for Comments: 6844, DNS Certification Authority Authorization (CAA)

Resource Record, Hallam‐Baker, Stradling, January 2013.

• RFC6960, Request for Comments: 6960, X.509 Internet Public Key Infrastructure Online

Certificate Status Protocol ‐ OCSP. Santesson, Myers, Ankney, Malpani, Galperin, Adams, June

2013.

• WebTrust for Certification Authorities , SSL Baseline with Network Security, Version 2.1,

available at http://www.webtrust.org/principles-and-criteria/docs/item85228.pdf









https://cabforum.org/extended-validation/





https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-89.pdf

http://www.webtrust.org/principles-and-criteria/docs/item85228.pdf



• X.509, Recommendation ITU‐T X.509 (10/2012) | ISO/IEC 9594‐8:2014 (E), Information

technology – Open Systems Interconnection – The Diretory: Public‐key and attribute

certificate frameworks.

• Ley Sobre Firmas Electrónicas Decreto N°,149-2013 publicado en el Diario Oficial LA GACETA

el 11 de diciembre del 2013

• ACUERDO EJECUTIVO № 41-2014, emitido el 12 de diciembre del 2014 (Oficio SECM №155-

2015) y publicado en el Diario Oficial LA GACETA el 21 de mayo del 2015

ac tecnisign polÍtica de certificados do tipo a3 oid:...

Documents