Norma
17/09/2021
#183021

PORTARIA CONJUNTA ITI/CC/PR SGD/SEDGG/ME Nº 1, DE 8 DE SETEMBRO DE 2021

Estabelece padrões criptográficos para assinaturas eletrônicas avançadas na administração pública federal.

Estabelece os padrões criptográficos referenciais para as assinaturas eletrônicas avançadas nas comunicações que envolvam a administração pública federal direta, autárquica e fundacional.

O DIRETOR-PRESIDENTE DO INSTITUTO NACIONAL DE TECNOLOGIA DA INFORMAÇÃO e o SECRETÁRIO DE GOVERNO DIGITAL DA SECRETARIA ESPECIAL DE DESBUROCRATIZAÇÃO, GESTÃO E GOVERNO DIGITAL DO MINISTÉRIO DA ECONOMIA, no uso das atribuições que lhes conferem o inciso I do art. 9º do Decreto nº 10.543, de 13 de novembro de 2020, resolvem:

O DIRETOR-PRESIDENTE DO INSTITUTO NACIONAL DE TECNOLOGIA DA INFORMAÇÃO e o SECRETÁRIO DE GOVERNO DIGITAL DA SECRETARIA ESPECIAL DE DESBUROCRATIZAÇÃO, GESTÃO E GOVERNO DIGITAL DO MINISTÉRIO DA ECONOMIA

Art. 1º Aprovar, na forma prevista no Anexo I desta Portaria, os padrões criptográficos referenciais para as assinaturas eletrônicas avançadas nas comunicações que envolvam a administração pública federal direta, autárquica e fundacional.

§ 1º Os padrões criptográficos previstos nesta portaria são de observância obrigatória nos casos de uso de assinaturas eletrônicas avançadas nas comunicações e iterações envolvendo entes ou entidades da Administração Federal direta, autárquica e fundacional, entre si ou com pessoas naturais ou entes e entidades de direito privado.

§ 2º Os padrões aprovados nocaputpoderão ser revistos ou atualizados por meio de portaria conjunta, a qualquer momento, em razão dos avanços tecnológicos em criptografia e assinaturas eletrônicas.

Art. 2º Esta Portaria entra em vigor no dia 1º de outubro de 2021.

Diretor-Presidente do Instituto Nacional

de Tecnologia da Informação

Secretário de Governo Digital

ANEXO

1. INTRODUÇÃO

1.1 Este regulamento estabelece os padrões referenciais de hardware, algoritmos e parâmetros criptográficos a serem empregados nos processos que envolvem a realização de assinaturas eletrônicas avançadas, compreendendo:

a) geração de chaves criptográficas;

b) solicitação, emissão e revogação de certificados digitais avançados;

c) geração e verificação de assinaturas eletrônicas avançadas;

d) cifração de mensagens;

e) autenticação com certificados digitais avançados.

1.2. As diretrizes aqui constantes devem ser obrigatoriamente observadas por órgãos e entidades, públicos e privados, provedores de serviços de emissão de certificados digitais avançados e de aplicações que realizem e verifiquem assinaturas eletrônicas avançadas.

2. ALGORITMOS E PARÂMETROS CRIPTOGRÁFICOS

2.1. Solicitação de certificado digital avançado à Autoridade Certificadora emissora:

2.1.1. Formato Padrão PKCS#10

2.2. Entrega de certificado digital avançado emitido pela Autoridade Certificadora:

2.2.1. Formato Padrão PKCS#7

2.3 Geração de chaves criptográficas assimétricas de Autoridade Certificadora emissora de certificados digitais avançados:

2.3.1. Algoritmos admitidos:

a) RSA;

b) ECC-Brainpool (conforme RFC 5639);

c) Ed448-Goldilocks (PureEdDSA e HashEdDSA, conforme RFC 8032);

d) E-521 (Conforme parâmetros da curva estabelecidos no item 2.13, PureEdDSA e HashEdDSA, conforme RFC 8032).

2.3.2 Tamanhos de Chaves admitidos:

a) RSA - 4096 bits;

b) ECC-Brainpool - 512 bits (curva P512r1);

c) Ed448-Goldilocks - 448 bits;

d) E-521 - 521 bits.

2.4. Geração de chaves criptográficas assimétricas de usuário final de certificados digitais avançados:

2.4.1. Algoritmos admitidos:

a) RSA;

b) ECC-Brainpool (conforme RFC 5639);

c) Curve25519 (conforme RFC 7748);

d) Ed25519 (PureEdDSA e HashEdDSA, conforme RFC 8032);

e) Ed448-Goldilocks (PureEdDSA e HashEdDSA, conforme RFC 8032);

f) E-521 (Conforme parâmetros da curva estabelecidos no item 2.13, PureEdDSA e HashEdDSA, conforme RFC 8032).

2.4.2. Tamanhos de Chaves admitidos:

a) RSA - 2048 e 4096 bits;

b) ECC-Brainpool - 256 e 512 bits (curvas P256r1 e P512r1, respectivamente);

c) Curve25519 - 256 bits;

d) Ed25519 - 256 bits;

e) Ed448-Goldilocks - 448 bits;

f) E-521 - 521 bits.

2.5. Assinatura de certificados de Autoridades Certificadoras emissoras de certificados digitais avançados:

2.5.1 Suítes de assinatura admitidas:

a) sha512WithRSAEncryption;

b) sha512WithECDSAEncryption;

c) sha3-512WithRSAEncryption;

d) sha3-512WithECDSAEncryption;

e) id-Ed448;

f) id-Ed448ph;

g) id-Ed521;

h) id-Ed521ph.

2.6. Assinatura de certificados avançados de usuários finais:

2.6.1. Suítes de assinatura admitidas:

a) sha256WithRSAEncryption;

b) sha3-256WithRSAEncryption;

c) sha256WithECDSAEncryption;

d) sha3-256WithECDSAEncryption;

e) sha512WithRSAEncryption;

f) sha3-512WithRSAEncryption;

g) sha512WithECDSAEncryption;

h) sha3-512WithECDSAEncryption;

i) id-Ed25519;

j) id-Ed25519ph;

k) id-Ed448;

l) id-Ed448ph;

m) id-Ed521;

n) id-Ed521ph.

2.7. Assinatura de listas de certificados avançados revogados e de respostas OCSP:

2.7.1 Suítes de assinatura admitidas:

a) sha256WithRSAEncryption;

b) sha3-256WithRSAEncryption;

c) sha256WithECDSAEncryption;

d) sha3-256WithECDSAEncryption;

e) sha512WithRSAEncryption;

f) sha3-512WithRSAEncryption;

g) sha512WithECDSAEncryption;

h) sha3-512WithECDSAEncryption;

i) id-Ed448;

j) id-Ed448ph;

k) id-Ed521;

l) id-Ed521ph.

2.8. Guarda de chaves criptográficas privadas de entidades titulares e de seus backups:

2.8.1 Algoritmos e tamanhos de chaves admitidos:

a) AES - 128 ou 256 bits;

b) Serpent - 128 e 256 bits.

2.8.2. Modos de operação admitidos:

a) GCM.

2.9.1. Funções resumo (Hash) admitidas:

a) SHA-256;

b) SHA-512;

c) SHAKE - 256;

d) SHA3-256;

e) SHA3-512.

2.9.2. Suítes de assinatura admitidas:

a) sha256WithRSAEncryption;

b) sha3-256WithRSAEncryption;

c) sha256WithECDSAEncryption;

d) sha3-256WithECDSAEncryption;

e) sha512WithRSAEncryption;

f) sha3-512WithRSAEncryption;

g) sha512WithECDSAEncryption;

h) sha3-512WithECDSAEncryption;

i) id-Ed25519;

j) id-Ed25519ph;

k) id-Ed448;

l) id-Ed448ph;

m) id-Ed521;

n) id-Ed521ph.

2.10. Assinatura de pedidos e respostas de Carimbos do Tempo:

2.10.1. Funções resumo (Hash) admitidas:

a) SHA-256;

b) SHA-512;

c) SHAKE - 256;

d) SHA3-256;

e) SHA3-512.

2.10.2. Suítes de assinatura admitidas:

a) sha256WithRSAEncryption;

b) sha3-256WithRSAEncryption;

c) sha256WithECDSAEncryption;

d) sha3-256WithECDSAEncryption;

e) sha512WithRSAEncryption;

f) sha3-512WithRSAEncryption;

g) sha512WithECDSAEncryption;

h) sha3-512WithECDSAEncryption;

i) id-Ed25519;

j) id-Ed25519ph;

k) id-Ed448;

l) id-Ed448ph

m) id-Ed521;

n) id-Ed521ph.

2.11. Esquemas de acordos de chaves criptográficas admitidos:

a) ECDH256 ou ECMQV256;

b) ECDH512 ou ECMQV512;

c) ECDHE X25519;

d) ECDHE X448;

e) RSA 2048;

f) RSA 4096.

2.12. Esquemas de envelopes criptográficos admitidos:

a) aes128WithRSA2048Encryption;

b) aes256WithRSA4096Encryption;

c) aes128WithECIES256Encryption;

d) aes256WithECIES512Encryption.

2.13. Parâmetros para a curva E-521:

2.13.1 Tabela de parâmetros e valores correspondentes:

Parâmetros

Valor

p

P da E-521(i.e.,2^521 - 1)

b

528

Codificação do GF(p)

527-bit codificação litlle-endian de {0,1...,p-1}

H(x)

SHAKE256(dom5(phflag,context)||x, 132)

phflag

0

c

Logaritmo base 2 do cofator da E-521(i.e.,2)

n

520

d

D da E-521(i.e., - 376014)

a

1

B

(X(P),Y(P)) da E-521 (i.e., (15710548 94184995387535939749894317568645297350402905821437625 18115230499438118852963259119606760410077267392791511 4267193389905003276673749012051148356041324, 12))

L

ordem da E-521 (i.e., 171619941503265242874 54751997703483043173588250358263523486158647963857958 49413675475876651663657849636693659065234142604319282 948702542317993421293670108523)

PH (X)

x (i.e., a função identidade)

Parâmetros

Valor

p

P da E-521(i.e.,2^521 - 1)

b

528

Codificação do GF(p)

527-bit codificação litlle-endian de {0,1...,p-1}

H(x)

SHAKE256(dom5(phflag,context)||x, 132)

phflag

0

c

Logaritmo base 2 do cofator da E-521(i.e.,2)

n

520

d

D da E-521(i.e., - 376014)

a

1

B

(X(P),Y(P)) da E-521 (i.e., (15710548 94184995387535939749894317568645297350402905821437625 18115230499438118852963259119606760410077267392791511 4267193389905003276673749012051148356041324, 12))

L

ordem da E-521 (i.e., 171619941503265242874 54751997703483043173588250358263523486158647963857958 49413675475876651663657849636693659065234142604319282 948702542317993421293670108523)

PH (X)

x (i.e., a função identidade)

Parâmetros

Valor

Parâmetros

Parâmetros

Valor

Valor

p

P da E-521(i.e.,2^521 - 1)

p

p

P da E-521(i.e.,2^521 - 1)

P da E-521(i.e.,2^521 - 1)

b

528

b

b

528

528

Codificação do GF(p)

527-bit codificação litlle-endian de {0,1...,p-1}

Codificação do GF(p)

Codificação do GF(p)

527-bit codificação litlle-endian de {0,1...,p-1}

527-bit codificação litlle-endian de {0,1...,p-1}

H(x)

SHAKE256(dom5(phflag,context)||x, 132)

H(x)

H(x)

SHAKE256(dom5(phflag,context)||x, 132)

SHAKE256(dom5(phflag,context)||x, 132)

phflag

0

phflag

phflag

0

0

c

Logaritmo base 2 do cofator da E-521(i.e.,2)

c

c

Logaritmo base 2 do cofator da E-521(i.e.,2)

Logaritmo base 2 do cofator da E-521(i.e.,2)

n

520

n

n

520

520

d

D da E-521(i.e., - 376014)

d

d

D da E-521(i.e., - 376014)

D da E-521(i.e., - 376014)

a

1

a

a

1

1

B

(X(P),Y(P)) da E-521 (i.e., (15710548 94184995387535939749894317568645297350402905821437625 18115230499438118852963259119606760410077267392791511 4267193389905003276673749012051148356041324, 12))

B

B

(X(P),Y(P)) da E-521 (i.e., (15710548 94184995387535939749894317568645297350402905821437625 18115230499438118852963259119606760410077267392791511 4267193389905003276673749012051148356041324, 12))

(X(P),Y(P)) da E-521 (i.e., (15710548 94184995387535939749894317568645297350402905821437625 18115230499438118852963259119606760410077267392791511 4267193389905003276673749012051148356041324, 12))

L

ordem da E-521 (i.e., 171619941503265242874 54751997703483043173588250358263523486158647963857958 49413675475876651663657849636693659065234142604319282 948702542317993421293670108523)

L

L

ordem da E-521 (i.e., 171619941503265242874 54751997703483043173588250358263523486158647963857958 49413675475876651663657849636693659065234142604319282 948702542317993421293670108523)

ordem da E-521 (i.e., 171619941503265242874 54751997703483043173588250358263523486158647963857958 49413675475876651663657849636693659065234142604319282 948702542317993421293670108523)

PH (X)

x (i.e., a função identidade)

PH (X)

PH (X)

x (i.e., a função identidade)

x (i.e., a função identidade)

2.13.2. Ed521ph é o mesmo, mas com PH sendo SHA-3 (512 bits) ou SHAKE256(x, 64) e phflag sendo 1, i.e., é feito um hash antes da assinatura com Ed521, com a constante hash modificada.

2.13.3. dom5(x, y): na geração de chave, uma string vazia. Na assinatura e verificação, a string do octeto "SigEd521" || octet(x) || octet(OLEN(y)) || y, onde x está no range 0-255 e y é uma string de octeto com no máximo 255 octetos. "SigEd521" está em ASCII (8 octets).

3. PADRÕES DE HARDWARE

3.1. Módulo criptográfico (HSM) de parametrização, geração e armazenamento de chaves criptográficas assimétricas de usuários finais de certificados digitais avançados em nuvem:

3.1.1. Este requisito se aplica somente para o caso de geração e armazenamento das chaves criptográficas de usuário final pela AC emissora do certificado digital avançado;

3.1.2. NSH-2 - Homologação ICP-Brasil, ou Certificação INMETRO, ou FIPS 140-2 nível 3, ou Common Criteria EAL 4+ eiDAS Protection Profile EN-419-221-5.

3.2. Módulo criptográfico (HSM) de parametrização, geração e armazenamento de chaves criptográficas assimétricas de Autoridade Certificadora emissora de certificados digitais avançados:

3.2.1. NSH-2 - Homologação ICP-Brasil, ou Certificação INMETRO, ou FIPS 140-2 nível 3, ou Common Criteria EAL 4+ eiDAS Protection Profile EN-419-221-5.

3.3. Módulo criptográfico (HSM) de parametrização, geração e armazenamento de chaves criptográficas assimétricas de Autoridade Certificadora Raiz de infraestrutura para emissão de certificados digitais avançados:

3.3.1. NSH-3 - Homologação ICP-Brasil, ou Certificação INMETRO, ou FIPS 140-2 nível 3, ou Common Criteria EAL 4+ eiDAS Protection Profile EN-419-221-5.

4. PERFIL DE CERTIFICADOS

4.1. Perfil de Certificado: em conformidade com o formato definido pelo padrão ITU X.509 ou ISO/IEC 9594-8, de acordo com o perfil estabelecido na RFC 5280;

4.2. Número da versão do certificado: versão 3 de certificado definida no padrão ITU X.509, de acordo com o perfil estabelecido na RFC 5280;

4.3. Extensões de certificado obrigatórias:

4.3.1. Certificados de AC:

4.3.1.1.Authority Key Identifier, não crítica: deve conter o hash SHA-256 da chave pública da AC que emite o certificado;

Authority Key Identifier

4.3.1.2.Subject Key Identifier, não crítica: deve conter o hash SHA-256 da chave pública da AC titular do certificado;

Subject Key Identifier

4.3.1.3.Key Usage, crítica: somente os bits keyCertSign e cRLSign devem estar ativados;

Key Usage

4.3.1.4.Certificate Policies, não crítica:

Certificate Policies

4.3.1.4.1. O campo policyIdentifier deve conter:

4.3.1.4.1.1. O OID da DPC da AC titular do certificado, se essa AC emite certificados para outras ACs; ou

4.3.1.4.1.2. Os OID das PCs que a AC titular do certificado implementa, se essa AC emite certificados para usuários finais;

4.3.1.4.2. O campo policyQualifiers deve conter o endereço Web da DPC da AC que emite o certificado;

4.3.1.5.Basic Constraints, crítica: deve conter o campo cA=True; e

Basic Constraints

4.3.1.6.CRL Distribution Points, não crítica: deve conter o endereço na Web onde se obtém a LCR correspondente ao certificado.

CRL Distribution Points

4.3.2. Certificados de usuário final:

4.3.2.1.Authority Key Identifier, não crítica: deve conter o hash SHA-256 da chave pública da AC que emite o certificado;

Authority Key Identifier

4.3.2.2.Key Usage, crítica: deve conter o bit digitalSignature ativado, podendo conter os bits keyEncipherment e nonRepudiation ativados;

Key Usage

4.3.2.3.Extended Key Usage, não crítica: no mínimo um dos propósitos client authentication (OID = 1.3.6.1.5.5.7.3.2) ou E-mail protection (OID = 1.3.6.1.5.5.7.3.4) deve estar ativado;

Extended Key Usage

4.3.2.4.Certificate Policies, não crítica: deve conter o OID da PC correspondente e o endereço Web da DPC da AC que emite o certificado;

Certificate Policies

4.3.2.5.CRL Distribution Points, não crítica: deve conter o(s) endereço(s) na Web onde se obtém a LCR correspondente;

CRL Distribution Points

4.3.2.6.Authority Information Access, não crítica: A primeira entrada deve conter o método de acesso id-ad-caIssuer, utilizando um dos seguintes protocolos de acesso, HTTP, HTTPS ou LDAP, para a recuperação da cadeia de certificação. A segunda entrada deve conter o método de acesso id-ad-ocsp, com o respectivo endereço do respondedor OCSP, quando implementado, utilizando um dos seguintes protocolos de acesso, HTTP, HTTPS ou LDAP;

Authority Information Access

4.3.2.7.Subject Alternative Name, não crítica, e com os seguintes formatos:

Subject Alternative Name

4.3.2.7.1. Para certificados de pessoas físicas:

4.3.2.7.1.1. CampootherName, obrigatório, contendo OID = 2.16.76.1.3.1 e conteúdo = nas primeiras 8 (oito) posições, a data de nascimento do titular, no formato ddmmaaaa; nas 11 (onze) posições subsequentes, o Cadastro de Pessoa Física (CPF) do titular;

otherName

4.3.2.7.2. O conjunto de informações definido em cada campootherNamedeve ser armazenado como uma cadeia de caracteres do tipo ASN.1 OCTET STRING ou PRINTABLE STRING;

otherName

4.3.2.7.3. Apenas os caracteres de A a Z, de 0 a 9, poderão ser utilizados, não sendo permitidos os demais caracteres especiais;

4.4. Formato de Nome: O nome do titular do certificado, constante do campo "Subject", deverá adotar o "Distinguished Name" (DN) do padrão ITU X.500/ISO 9594, da seguinte forma:

Subject Distinguished Name

C = BR

O = GOV-BR

OU = nome da AC emissora do certificado

CN = (i) se certificado de AC = nome da AC titular do certificado; (ii) se certificado de pessoa física = nome do titular do certificado

4.5. São aplicáveis as seguintes restrições para os nomes de titulares de certificados:

4.5.1. não deverão ser utilizados sinais de acentuação, tremas ou cedilhas; e

4.5.2. além dos caracteres alfanuméricos, poderão ser utilizados somente os seguintes caracteres especiais:

Caractere

Código NBR9611 (hexadecimal)

Branco

20

!

21

"

22

#

23

$

24

%

25

&

26

'

27

(

28

)

29

*

2A

+

2B

,

2C

-

2D

.

2E

/

2F

:

3A

;

3B

=

3D

?

3F

@

40

\

5C

Caractere

Código NBR9611 (hexadecimal)

Branco

20

!

21

"

22

#

23

$

24

%

25

&

26

'

27

(

28

)

29

*

2A

+

2B

,

2C

-

2D

.

2E

/

2F

:

3A

;

3B

=

3D

?

3F

@

40

\

5C

Caractere

Código NBR9611 (hexadecimal)

Caractere

Caractere

Código NBR9611 (hexadecimal)

Código NBR9611 (hexadecimal)

Branco

20

Branco

Branco

20

20

!

21

!

!

21

21

"

22

"

"

22

22

#

23

#

#

23

23

$

24

$

$

24

24

%

25

%

%

25

25

&

26

&

&

26

26

'

27

'

'

27

27

(

28

(

(

28

28

)

29

)

)

29

29

*

2A

*

*

2A

2A

+

2B

+

+

2B

2B

,

2C

,

,

2C

2C

-

2D

-

-

2D

2D

.

2E

.

.

2E

2E

/

2F

/

/

2F

2F

:

3A

:

:

3A

3A

;

3B

;

;

3B

3B

=

3D

=

=

3D

3D

?

3F

?

?

3F

3F

@

40

@

@

40

40

\

5C

\

\

5C

5C

5. PERFIL DE LCR

5.1. Número de versão de LCR: versão 2 do padrão ITU X.509, de acordo com o perfil estabelecido na RFC 5280;

5.2. Extensões obrigatórias de LCR:

5.2.1.Authority Key Identifier, não crítica: deve conter o hash SHA-256 da chave pública da AC que assina a LCR; e

Authority Key Identifier

5.2.2.CRL Number, não crítica: deve conter um número sequencial para cada LCR emitida pela AC;

CRL Number

5.2.3. Frequência de emissão de LCR:

5.2.3.1. Nos casos de AC Raiz e AC Intermediária, no máximo a cada 90 dias;

5.2.3.2. No caso de AC final, no máximo a cada hora (60 minutos).

6. PERFIL DE OSCP

6.1. Número de versão de OSCP: serviços de respostas OCSP deverão implementar a versão 1 do padrão ITU X.509, de acordo com o perfil estabelecido na RFC 6960;

6.2. Extensões de OSCP: se implementado, deve estar em conformidade com a RFC 6960.

7. PADRÕES DE FORMATOS DE ASSINATURAS ELETRÔNICAS AVANÇADAS:

7.1. Padrão CAdES (CMSAdvanced Electronic Signature), conforme definido pela ETSI TS 101 733;

Advanced Electronic Signature

7.2. Padrão XAdES (XMLAdvanced Electronic Signature), conforme definido pela ETSI TS 101 903 e TS 103 171; e

Advanced Electronic Signature

7.3. Padrão PAdES (PDFAdvanced Electronic Signature), conforme definido pela ETSI TS 102 778.

Advanced Electronic Signature)

8. REQUISITOS GERAIS

8.1. Para a emissão de certificado digital avançado, a identificação do titular do certificado deverá ser comprovada por validador de acesso digital cadastrado pela SGD/ME, conforme regulamento editado por aquela Secretaria.

8.2. Disponibilidade de serviços: as entidades provedoras de certificados digitais avançados devem declarar qual a disponibilidade dos seus serviços.

8.2.1. A disponibilidade recomendada é de, no mínimo, 99,5% (noventa e nove vírgula cinco por cento) do mês, 24 (vinte e quatro) horas por dia, 7 (sete) dias por semana.

8.2.2. É responsabilidade do provedor dos serviços publicar regularmente a disponibilidade de seus serviços para conhecimento público.

8.3. As entidades provedoras de certificados digitais avançados devem dispor em suas Declarações de Práticas de Certificação (DPC) e Políticas de Certificados (PC) a conformidade aos parâmetros estabelecidos por este regulamento, bem como os demais que regem suas operações, em conformidade à RFC 3642 da IETF.

8.3.1. As DPCs e PCs referidas no item anterior devem estar publicadas para livre acesso e conhecimento da sociedade em geral.

8.4. Os provedores de serviços de emissão de certificados digitais avançados e de aplicações que realizem e verifiquem assinaturas eletrônicas avançadas deverão solicitar à SGD integração de seus serviços à Plataforma Gov.br.

8.5. Para garantir o reconhecimento das cadeias de confiança envolvidas e a interoperabilidade das assinaturas eletrônicas avançadas, o ITI manterá uma Lista de Serviços de Assinaturas Eletrônicas Avançadas integrados à Plataforma Gov.br, a partir da informação de integração repassada pela SGD.

8.6. Para efeito do disposto no item anterior o ITI poderá avaliar as DPCs, PCs e certificados envolvidos na cadeia de confiança do provedor de certificados digitais avançados, bem como, amostras de documentos com assinaturas eletrônicas avançadas dos provedores de aplicações que realizem e verifiquem assinaturas eletrônicas avançadas.

8.7. A qualquer tempo, ao tomar conhecimento da ocorrência de irregularidades nos serviços prestados pelos provedores incluídos na Lista de Serviços de Assinaturas Eletrônicas Avançadas integrados à Plataforma Gov.br, a SGD solicitará ao ITI a exclusão do provedor correspondente da lista.

8.8. Os serviços incluídos na Lista de Serviços de Assinaturas Eletrônicas Avançadas integrados à Plataforma Gov.br são de responsabilidade exclusiva de seus provedores, respondendo por eventuais danos a que derem causa. A SGD e o ITI não se responsabilizam pelos mesmos sob qualquer hipótese. A referida lista tem por objetivo apenas dar publicidade aos serviços dela constantes e prover interoperabilidade dos documentos digitais assinados através desses serviços.

8.9. No caso de haver necessidade de inclusão de informações adicionais (opcionais) nos certificados digitais avançados, o ITI deverá ser consultado e, se for o caso, atribuirá um OID específico para o caso.

Perguntas e respostas

Quais são as suítes de assinatura admitidas para a assinatura de certificados de Autoridades Certificadoras emissoras de certificados digitais avançados?
As suítes de assinatura admitidas são: sha512WithRSAEncryption, sha512WithECDSAEncryption, sha3-512WithRSAEncryption, sha3-512WithECDSAEncryption, id-Ed448, id-Ed448ph, id-Ed521 e id-Ed521ph.
Quais são os tamanhos de chaves admitidos para a geração de chaves criptográficas assimétricas de Autoridade Certificadora emissora de certificados digitais avançados?
Os tamanhos de chaves admitidos são: RSA - 4096 bits, ECC-Brainpool - 512 bits (curva P512r1), Ed448-Goldilocks - 448 bits e E-521 - 521 bits.
Quais são os padrões de formatos de assinaturas eletrônicas avançadas?
Os padrões de formatos de assinaturas eletrônicas avançadas são: Padrão CAdES (CMS Advanced Electronic Signature), conforme definido pela ETSI TS 101 733; Padrão XAdES (XML Advanced Electronic Signature), conforme definido pela ETSI TS 101 903 e TS 103 171; e Padrão PAdES (PDF Advanced Electronic Signature), conforme definido pela ETSI TS 102 778.
Quais são os componentes abrangidos pelos padrões criptográficos referenciais?
Os padrões criptográficos referenciais abrangem a geração de chaves criptográficas, solicitação, emissão e revogação de certificados digitais avançados, geração e verificação de assinaturas eletrônicas avançadas, cifração de mensagens e autenticação com certificados digitais avançados.
Quais são as extensões obrigatórias para certificados de Autoridades Certificadoras (AC)?
As extensões obrigatórias para certificados de AC são: Authority Key Identifier (não crítica), Subject Key Identifier (não crítica), Key Usage (crítica), Certificate Policies (não crítica), Basic Constraints (crítica) e CRL Distribution Points (não crítica).
Quais são as extensões obrigatórias para certificados de usuários finais?
As extensões obrigatórias para certificados de usuários finais são: Authority Key Identifier (não crítica), Key Usage (crítica), Extended Key Usage (não crítica), Certificate Policies (não crítica), CRL Distribution Points (não crítica), Authority Information Access (não crítica) e Subject Alternative Name (não crítica).
Quais são os formatos padrão para a solicitação e entrega de certificados digitais avançados?
Para a solicitação de certificado digital avançado à Autoridade Certificadora emissora, o formato padrão é PKCS#10. Para a entrega de certificado digital avançado emitido pela Autoridade Certificadora, o formato padrão é PKCS#7.
Quais são os algoritmos e tamanhos de chaves admitidos para a guarda de chaves criptográficas privadas de entidades titulares e de seus backups?
Os algoritmos admitidos são AES (128 ou 256 bits) e Serpent (128 e 256 bits). O modo de operação admitido é GCM.
O que é a Lista de Serviços de Assinaturas Eletrônicas Avançadas integrados à Plataforma Gov.br?
A Lista de Serviços de Assinaturas Eletrônicas Avançadas integrados à Plataforma Gov.br é mantida pelo ITI e inclui os serviços de provedores que solicitaram integração de seus serviços à Plataforma Gov.br. Essa lista visa garantir o reconhecimento das cadeias de confiança envolvidas e a interoperabilidade das assinaturas eletrônicas avançadas.
Quem são os responsáveis pela portaria?
O Diretor-Presidente do Instituto Nacional de Tecnologia da Informação e o Secretário de Governo Digital da Secretaria Especial de Desburocratização, Gestão e Governo Digital do Ministério da Economia.
Quais são os padrões de hardware para módulos criptográficos (HSM) de parametrização, geração e armazenamento de chaves criptográficas assimétricas de usuários finais de certificados digitais avançados em nuvem?
Os padrões de hardware para módulos criptográficos (HSM) de parametrização, geração e armazenamento de chaves criptográficas assimétricas de usuários finais de certificados digitais avançados em nuvem são: NSH-2 - Homologação ICP-Brasil, ou Certificação INMETRO, ou FIPS 140-2 nível 3, ou Common Criteria EAL 4+ eiDAS Protection Profile EN-419-221-5.
Quais são os requisitos gerais para a emissão de certificado digital avançado?
Para a emissão de certificado digital avançado, a identificação do titular do certificado deverá ser comprovada por validador de acesso digital cadastrado pela SGD/ME, conforme regulamento editado por aquela Secretaria. As entidades provedoras de certificados digitais avançados devem declarar a disponibilidade dos seus serviços, sendo a disponibilidade recomendada de, no mínimo, 99,5% do mês, 24 horas por dia, 7 dias por semana. As entidades devem publicar regularmente a disponibilidade de seus serviços para conhecimento público.
Quais são os algoritmos admitidos para a geração de chaves criptográficas assimétricas de Autoridade Certificadora emissora de certificados digitais avançados?
Os algoritmos admitidos são: RSA, ECC-Brainpool (conforme RFC 5639), Ed448-Goldilocks (PureEdDSA e HashEdDSA, conforme RFC 8032) e E-521 (conforme parâmetros da curva estabelecidos no item 2.13, PureEdDSA e HashEdDSA, conforme RFC 8032).
Quais são as responsabilidades dos provedores de serviços de emissão de certificados digitais avançados?
Os provedores de serviços de emissão de certificados digitais avançados devem dispor em suas Declarações de Práticas de Certificação (DPC) e Políticas de Certificados (PC) a conformidade aos parâmetros estabelecidos pelo regulamento, bem como os demais que regem suas operações, em conformidade à RFC 3642 da IETF. As DPCs e PCs devem estar publicadas para livre acesso e conhecimento da sociedade em geral.
O que estabelece a portaria mencionada?
A portaria estabelece os padrões criptográficos referenciais para as assinaturas eletrônicas avançadas nas comunicações que envolvam a administração pública federal direta, autárquica e fundacional.
Quais são as funções resumo (Hash) admitidas?
As funções resumo admitidas são: SHA-256, SHA-512, SHAKE-256, SHA3-256 e SHA3-512.
Quando a portaria entra em vigor?
A portaria entra em vigor no dia 1º de outubro de 2021.