RFC 10031: Endereços de Controle de Mídia (MAC) em Certificados X.509

13/08/2026 às 00:0023 visualizações
RFC 10031: Media Access Control (MAC) Addresses in X.509 Certificates. This document defines a new GeneralName.otherName for inclusion in the X.509 Subject Alternative Name (SAN) and Issuer Alternative Name (IAN) extensions to carry an IEEE Media Access Control (MAC) address. The new name form makes it possible to bind a Layer 2 interface identifier to a public key certificate. Additionally, this document defines how constraints on this name form can be encoded and processed in the X.509 Name Constraints extension (NCE)..
RFC 10031: Media Access Control (MAC) Addresses in X.509 Certificates. This document defines a new GeneralName.otherName for inclusion in the X.509 Subject Alternative Name (SAN) and Issuer Alternative Name (IAN) extensions to carry an IEEE Media Access Control (MAC) address. The new name form makes it possible to bind a Layer 2 interface identifier to a public key certificate. Additionally, this document defines how constraints on this name form can be encoded and processed in the X.509 Name Constraints extension (NCE)..
RFC Editor
RFC (Requisito de Relatório de Conformidade) 10031: Endereços de Controle de Acesso de Mídia (MAC) em Certificados X.509
  • R. Housley (Robert Housley),  
  • C. Bonnell (Chris Bonnell),  
  • J. Mandel (Jerry Mandel),  
  • T. Okubo (Takashi Okubo),  
  • M. StJohns (Mark StJohns)
Padrão Proposto

Resumo

Este documento define um novoGeneralNome.outroNomePara inclusão na extensão X.509 de Nome Alternativo do Assunto (SAN) e Nome Alternativo do Emissor (IAN) para carregar um endereço MAC (Media Access Control) da IEEE. A nova forma de nome permite vincular um identificador de interface de Camada 2 a um certificado de chave pública. Além disso, este documento define como as restrições sobre esta forma de nome podem ser codificadas e processadas na extensão de Restrições de Nome X.509 (NCE).

Status deste Memorando

Este é um documento de padrão da Internet.

Este documento é um produto da Internet Engineering Task Force (IETF). Representa o consenso da comunidade IETF. Foi submetido a revisão pública e aprovado para publicação pelo Internet Engineering Steering Group (IESG). Mais informações sobre Padrões da Internet estão disponíveis na Seção 2 do RFC 7841.

Informações sobre o status atual deste documento, quaisquer erratas e como fornecer feedback podem ser obtidas em....

1. Introdução

Implementações que utilizam certificados X.509 para identificar um dispositivo por meio do endereço de Controle de Acesso à Mídia (MAC) precisam de uma maneira padrão de codificá-lo na extensão de Nome Alternativo do Assunto (SAN) definida em[]Este documento define um novo formato de nome.otherNameo formato de nome "MACAddress"Endereço MACO formato de nome carrega um endereço MAC IEEE 802 de 48 bits (EUI-48) ou um identificador estendido de 64 bits (EUI-64) em uma string de octetos.STRING OCTET [X680]Além disso, a forma de nome também pode transmitir restrições aos valores EUI-48 ou EUI-64 quando incluída na extensão de restrições de nome (NCE) definida em.Seção 4.2.1.10Texto: "de [ "]A nova forma de nome permite autenticação baseada em certificado na camada 2 e facilita a configuração segura em redes da Internet das Coisas (IoT) e automotivas, em particular.

Observe que, embora essa estrutura possa ser usada para transportar endereços EUI-48 ou EUI-64 em uma extensão de Nome Alternativo do Emissor (IAN), provavelmente há poucas, se houver, razões para fazê-lo.

2. Convenções e Definições

Palavras-chave:DEVE", "NÃO DEVE", "OBRIGATÓRIO", "DEVE FAZER", "NÃO DEVE FAZER", "DEVE-SE", "NÃO DEVE-SE", "RECOMENDADO", "NÃO RECOMENDADO", "PODE, eOPÇIONAL" neste documento devem ser interpretados como[] []quando, e apenas quando, eles

3. Endereço MAC outros nomes

Neste documento, "outros nomes", "OutroNome, eNomeGeral.outros nomes" se referem a umNomeGeral.outros nomesCampo incluído em um SAN ou IAN. A nova forma de nome é identificada peloIDENTIFICADOR DE OBJETO(OID)id-em-Endereço-MAC (1.3.6.1.5.5.7.8.12) e declarada abaixo utilizando aOUTRO-NOMEsintaxe de declaração de classe. A forma de nome tem variantes para transmitir um EUI-48 como umaSTRING DE OCTETOSConsistindo de 6 octetos, ou um EUI-64 como umSTRING DE OCTETOSConsistindo de 8 octetos. Restrições sobre os valores EUI-48 e EUI-64 são transmitidas comoSTRING DE OCTETOScujos comprimentos são o dobro do comprimento de octeto dos identificadores. O primeiro conjunto de N octetos (onde N é o comprimento dos octetos do endereço) define o padrão de bits da restrição que o endereço deve corresponder, e o segundo conjunto de N octetos define a máscara de bits que define o conjunto de bits significativos no padrão de bits.

As subseções seguintes descrevem como codificar os valores EUI-48 e EUI-64 e suas restrições correspondentes.

3.1. Codificando um Endereço MAC como um Nome Alternativo

Quando a forma de nome é incluída em uma SAN ou IAN extensão como umOutroNomeA sintaxe consiste exatamente em seis ou oito octetos. Os valores são codificados com o octeto mais significativo codificado primeiro ("endian grande" ou "da esquerda para a direita"). Nenhuma representação de texto é permitida no certificado, pois formas legíveis por humanos, como "00-24-98-7B-19-02ou0024.987B.1902" são usadas apenas em interfaces de gerenciamento. Quando um dispositivo possui um identificador MAC de 48 bits, a Autoridade de Certificação (CA)DEVEcodificá-lo usando um 6-octetSTRING OCTETEcomoEndereço MACvalor. Quando o identificador de fábrica do dispositivo é um EUI-64 de 64 bits ou quando não existe uma forma canônica de 48 bits, o CADEVEcodificá-lo usando um OCTETE de 8 bitsSTRING OCTETEcomoEndereço MACvalor.

Exemplo:00-24-98-7B-19-02codifica comoSTRING OCTET '0024987B1902'H.

3.2. Codificando a restrição de Endereço MAC

Quando o nome do formato é incluído no NCE, a sintaxe consiste em umSTRING OCTETEque é o dobro do comprimento doSTRING OCTETErepresentação do tipo de endereço sendo restrito. Dentro doSTRING OCTETE, dois elementos são codificados:

  1. O primeiro conjunto de N octetos (onde N é 6 para uma restrição EUI-48 ou 8 para uma restrição EUI-64) contém o "padrão de bits de valor". Este padrão de bits codifica os bits que o endereço mascarado deve conter para ser considerado uma correspondência.

  2. O segundo conjunto de N octetos codifica o "padrão de bits de máscara" da restrição. Cada bit afirmado no padrão de bits de máscara indica que o bit na mesma posição no endereço é restrito pelo primeiro conjunto de N octetos.

Por exemplo, uma restrição que especifica que os nomes aceitáveis devem estar todos dentro de um Identificador Organizaçãoalmente Único (OUI).00-00-5ePara um endereço EUI-48, a parte do valor seria...Texto: '00005E000000' (em português brasileiro, sem tradução literal, pois parece ser um código ou sequência numérica sem significado contextual claro)Máscara, parte essencialTexto: 'FFFFFFFF000000'H (sem tradução, pois o texto original parece ser uma sequência de caracteres sem significado jornalístico)E seria codificado comoString de octetos '00005E000000FFFFFF000000'H.

Os padrões de bits codificados tanto no padrão de bits de valor quanto no padrão de bits de máscara são codificados com o bit mais significativo codificado primeiro ("big-endian" ou "da esquerda para a direita" codificação).

Se um bit não for afirmado no padrão de bits de máscara, então a CANÃO DEVEafirmar o bit correspondente no padrão de bits de valor. Esta regra garante que uma codificação canônica seja usada para um dado padrão de bits de máscara e padrão de bits de valor.

De acordocom a Seção 4.2.1.10do []As certificações NCE são válidas em eDEVEser utilizada exclusivamente em um certificado CA".

3.3. Regras de Geração e Validação

O CADEVEgarantir queEndereço MAC outro nomeos valores incluídos nos certificados que ele emite são de propriedade (ou são esperados que sejam de propriedade) do dispositivo sujeito ao certificado por toda a sua validade. O mesmo endereço MACNÃO DEVEser incluído em certificados emitidos para dispositivos diferentes, a menos que dispositivos diferentes compartilhem a mesma interface de camada 2.

Uma parte confiante que corresponda um endereço MAC apresentado a um certificadoDEVErealizar uma comparação byte a byte doOCTET STRINGConteúdos.

Wildcards não são suportados.

Certificados autoassinados que carregam umaEndereço MAC outroNome DEVEIncluir o endereço de um dos portos físicos do dispositivo.

3.4. Processamento de caminho para a Extensão de Restrições de Nome

OEndereço MAC outroNomesegue as regras gerais paraoutroNomerestrições em[], Seção 4.2.1.10Um NOVOMAIOIMPORsubárvores PERMITIDASEsubárvores EXCLUÍDASSOBREOutros Nomesdo tipoid-no-Endereço-MAC.

No pseudocódigo abaixo, 'mask' é uma abreviação da string binária formada pela parte da máscara de uma restrição (por exemplo, o segundo conjunto de N octetos na restrição, onde N é 6 para uma restrição EUI-48 ou 8 para uma restrição EUI-64). Da mesma forma, 'valor' se refere à string binária formada pelo primeiro conjunto de N octetos na restrição.

A declaração 'restrição' usada abaixo indica umaOutroNome.Endereço-MACpar de valor/máscara de restrição -- com campos 'máscara', 'valor' e 'comprimento'. O campo '.comprimento' retorna o comprimento em bytes da restrição codificada completa -- 12 ou 16, dependendo do tipo de restrição. A declaração 'nome' usada abaixo representa umOutroNome.Endereço-MACnome com campos 'valor' e 'comprimento'. O comprimento é de 6 ou 8, representando o comprimento da nome codificada.

3.4.1. Regras de Correspondência

Para determinar se um nome corresponde a uma restrição dada, o aplicativo que consome o certificado executa o seguinte algoritmo:

  1. Se o nome tiver 6 octetos (representando um valor EUI-48) e a restrição for de 16 octetos (representando uma restrição EUI-64), então o nome não corresponde à restrição.

  2. Se o nome tiver 8 octetos (representando um valor EUI-64) e a restrição for de 12 octetos (representando uma restrição EUI-48), então o nome não corresponde à restrição.

  3. Extraia o padrão de bits do valor dos N octetos superiores (big-endian) da restrição, onde N é "6" para identificadores EUI-48 e "8" para EUI-64.

  4. Extraia o padrão de bits da máscara dos N octetos inferiores (big-endian) da restrição, onde N é "6" para identificadores EUI-48 e "8" para EUI-64.

  5. Realize uma operação XOR (exclusivo ou) entre a string de bits do valor extraída na etapa 3 e os octetos do valor do nome.

  6. Realize uma operação AND bit a bit entre a string de bits calculada na etapa 5 e o padrão de bits da máscara.

  7. Se o resultado do passo 6 for uma sequência de bits composta exclusivamente por zeros, então o nome atende à restrição. Por outro lado, se o resultado da operação for uma sequência de bits com pelo menos um bit definido, então o nome não atende à restrição.

O algoritmo também pode ser expresso da seguinte forma:

`// Retorna verdadeiro se 'nome n' corresponde a 'restrição c'

Por exemplo, uma restrição de'000000000000 030000000000'Hserá correspondida por qualquer endereço EUI-48 universal/unicast, como00-00-5e-00-50-34. Uma restrição de00005E000000 FFFFFF000000'H - '00005E000000FFFFFF000000' em hexadecimalserá correspondido por qualquer endereço universal/unicast com um OUI de - 'será correspondido por qualquer endereço universal/unicast com um OUI de'00-00-5E - '00-00-5E'-- ou seja, também corresponderá a - '-- ou seja, também corresponderá a'00-00-5e-00-50-34 - '00-00-5e-00-50-34'Observe que - 'Observe que'00-00-5E' - '00-00-5Eé um OUI controlado por IANA - 'é um OUI controlado por IANA'Seção 1.3de []).

As implementações não são obrigadas a implementar este algoritmo, mas elasDEVEcalcular um resultado idêntico a este algoritmo para um conjunto dado de entradas.

3.4.2. Processamento de Validação de Caminho - OtherName.Endereço MAC

Esta seção descreve o Processamento de Validação de Caminho específico paraOutroNome.EndereçoMACRestrições. N.B., é possível construir hierarquias de NCEs paraOutroNome.EndereçoMACs que proíbem todos os nomes, mesmo que isso não tenha sido pretendido. Por exemplo, se o NCE de nível 1 contivesse apenas umsubárvores_permitidas", de apenas (OutroNome.EndereçoMAC) global/unicast EUI-48, e o NCE de nível 2 contivesse apenas um "subárvores_permitidas"de" "qualquer endereço" (ou seja, o conjunto de restrições inicial). Isso resultaria em um conjunto vaziosubárvores_permitidasde restrições, pois uma restrição "qualquer endereço" não está contida dentro de uma restrição "global/unicast". O exemplo prático é deixado ao leitor.

O seguinte é uma função de utilidade usada para determinar se ou não o conjunto de endereços correspondentes para umaEndereçoMACrestrição é um subconjunto dos endereços correspondentes para outra restrição.

Por exemplo, dado o seguinte (usando o DOI atribuído pela IANA), 'filho' é uma restrição totalmente contida em 'pai':

Restrição pai = '000000000000 000000000000'H
Restrição filho = '00005E000000 FCFFFF000000'H

"Criança" é um subconjunto de "pais" porque: 1) Eles têm a mesma extensão (ambos os restrições EUI-48); e 2) A máscara de criança ANDada com a máscara de pai é igual à máscara de pai; e 3) Os bits no valor da criança sob a máscara do pai são definidos para os mesmos valores que os bits no valor do pai sob a máscara do pai.

Observe que a máscara de criança permite qualquer combinação dos bits de endereço local/universal e unicast/multicast dentro do OUI (Organização Única de Identificação).00-00-5e (traduzido para texto, assumindo um contexto jornalístico, poderia ser: "Data: 00/00/5e").

SeRestrição criança2 = '00005E005000 FFFFFFFFFF00'HQuando se compara "criança" e "criança2", "criança2" seria um subconjunto de "criança". "Criança2" utiliza o mesmo OUI de "criança", mas restringe ainda mais o endereçamento correspondente para universal/unicast ao ativar o...'030000000000'HMáscara bits e também restringe o intervalo de endereços válidos de 00-00-5E-00-50-00 a 00-00-5E-00-50-FF.Exemplo de intervalo para o '00-00-5E'.Sim.Ambas as variáveis 'child' e 'parent' são OtherName.MACAddress.Retorna verdadeiro se todos os endereços que correspondem ao child também correspondem ao parent; falso caso contrário.Usado para calcular conjuntos de INTERSECÇÃO para restrições OtherName.MACAddress.boolean childIsSubsetOfParent (constraint c, constraint p) {

Retorna (se as comprimentos forem iguais, e se não houver bits definidos na máscara do parent que não estejam também definidos no child, e se o valor do child tiver pelo menos todos os bits definidos que estavam definidos (e válidos) no valor do parent).
3.4.2.1. Inicialização

Per (h) e (i) emSeção 6.1.1de [], precisamos especificar NCEOtherName.MACEndereçodefinir valores tanto para as subárvores iniciais permitidas quanto para as subárvores iniciais excluídas. Para a subárvore inicial permitida, a primeira restrição é "aceitar todos os MACAddresses EUI-48", e a segunda restrição é "aceitar todos os MACAddresses EUI-64":

{ "subárvores_inicial_permitidas" : [ "000000000000000000000000H",
  "0000000000000000000000000000000
3.4.2.2. Operação Interseção

Veja (g) (1) emSeção 6.1.4Texto: "de [ "]À medida que descemos pela árvore, desde a raiz, o conjunto desubárvores permitidasSó pode permanecer o mesmo ou encolher. Em cada nível, limpamos o conjunto de subárvores permitidas.subárvores_permitidasE para cada NCE, verificamos se há uma restrição de subárvore permitida no certificado.OtherName.MACAddress.subárvore_permitidaSe houver uma restrição de subárvore permitida no nível anterior que seja igual ou contenha esta nova restrição, adicionamos esta nova restrição ao conjunto de subárvores permitidas do nível atual.subárvore_permitidaNo certificado, verificamos se há uma restrição de subárvore permitida no nível anterior que corresponda ou envolva esta nova restrição.subárvores_permitidasRepetimos isso ao descer pela árvore para os certificados CA restantes.

A interseção do conjunto deOtherName.MACAddresso atualpermitted_subtreescom cada certificado no caminho é da seguinte forma:

// Essa lógica pode ser usada tanto para MACAddress quanto para iPAddress
3.4.2.3. Operação de União

Ver (g) (2) emSeção 6.1.4de []. Ao contráriosubárvores permitidas, que é a interseção das NCEs em cada nível,subárvores excluídasÉ a união de todas as restrições. Começando com umsubárvores_excluídasconjunto vazio, em cada nível, adicione ao conjunto qualquer restrição dos certificados CA que não esteja já no conjunto, ou que não seja coberta por uma restrição já existente no conjunto.

A união do conjunto com as subárvores_excluídassubárvores_excluídasconjunto com o OtherName.MACAddresssubárvores_excluídas subárvores_excluídasPara cada certificado no caminho, o cálculo é feito da seguinte forma:

// Inicialização

4. Considerações de Segurança

A ligação de um endereço MAC a um certificado é tão forte quanto o processo de validação da Autoridade de Certificação (CA). As CAsDEVERÃOverificar que o assinante controla ou possui legitimamente o endereço MAC afirmado. O processo de validaçãoDEVERÁlevar em conta a possibilidade de que endereços MAC possam ser falsificados.

Alguns sistemas atribuem ou compartilham endereços MAC dinamicamente. Práticas como essa podem comprometer a unicidade e a responsabilidade que essa forma de nome visa proporcionar.

Diferente dos endereços IP, os endereços MAC geralmente não são roteados além das fronteiras do Layer 3. Partes dependentesNÃO DEVERIAMassumir unicidade além da sua rede local a menos que a parte dependente tenha informação de que os endereços são estáveis além das fronteiras da rede.

A seção Considerações de Segurança do[]também se aplica a esta especificação.

4.1. Considerações de Privacidade

Um endereço MAC pode identificar de forma única um dispositivo físico e, por extensão, seu usuário. Certificados que incorporam endereços MAC imutáveis facilitam o rastreamento de dispositivos de longo prazo. Implementações que utilizam o endereço MAC devem considerar a rotação de endereços, o uso de certificados de curto prazo ou a randomização do endereço MAC sempre que viável.Endereço MACnomeDEVEconsiderar a rotação de endereços, o uso de certificados de curto prazo ou a utilização de randomização de endereços MAC sempre que possível.

5. Considerações IANA

A IANA fez a seguinte atribuição no registro "SMI Security para Módulo de Identificação PKIX" (1.3.6.1.5.5.7.0) :

Tabela 1
Decimal Descrição Referência
126 id-mod-mac-address-outro-nome-2025 RFC 10031

A IANA fez a seguinte atribuição no registro "SMI Segurança para PKIX Formas de Nome Outros":1.3.6.1.5.5.7.8)

Tabela 2
Decimal Descrição Referência
12 id-em-MACAddress RFC 10031

6. Módulo ASN.1

Esta seção contém o módulo ASN.1 para o endereço MAC; segue as convenções estabelecidas por[].

<CÓDIGO INICIA>

7. Exemplos de otherName de Endereço MAC

7.1. Identificador EUI-48

O seguinte é um resumo legível por humanos da extensão de Nome Alternativo do Assunto de um certificado que contém um únicoMACAddress otherNamecom valor00-24-98-7B-19-02:

SEQUÊNCIA {

7.2. Identificador EUI-64

Exemplo de EUI-64 (AC-DE-48-00-11-22-33-44):

[0] STRING OCTET 'ACDE480011223344'H

7.3. Restrição EUI-48 para Endereços Universais, Unicast

O primeiro octe de um endereço MAC contém dois bits de bandeira. Numeração de bits IEEE tem o bit '0' como o bit de menor significância do octe porque é o bit transmitido primeiro.

  • Bit individual (I) ou grupo (G) (bit 0 ou máscara 0x01): 0 = unicast, 1 = multicast. Os prefixos multicast nunca são OUIs.

  • Bit universal (U) ou local (L) (bit 1 ou máscara 0x02): 0 = universal (atribuído pela IEEE), 1 = local.

Esses flags permitem que as implementações excluam endereços multicast e local, mas ainda assim não podem provar que um valor de 24 bits é um OUI registrado pela IEEE. ID's de empresa de 36 bits (CIDs) compartilham os mesmos 24 bits iniciais, e as empresasPODEMimplementar pseudo-OUIs. Autoridades de Certificação (CAs)DEVERÃOincluir apenas endereços controlados legitimamente pelo assinante (OUI registrado ou CID). Antes de emitir um certificado que contenha umMACAddressOu por uma restrição de nome baseada em um conjunto permitido de endereços, a CA deve verificar...DEVEconferir que o controle: por exemplo, consultando o registro IEEE[IEEERA]ou revisando a documentação do fabricante.

A seguinte definição de restrição limita os valores EUI-48 apenas aos universais e unicast; valores localmente atribuídos ou multicast não corresponderão à restrição.

[0] STRING OCTET '000000000000 030000000000'H

8. Referências

8.1. Referências Normativas

[RFC 2119]Bradner, S., Palavras-chave para uso em RFCs para indicar níveis de requisito, BCP 14, RFC 2119, DOI 10.17487/RFC2119, Março de 1997,<>.Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R.e outrosW. Polk, Perfil de Certificado e Lista de Revogação de Certificados (CRL) da Infraestrutura de Chave Pública X.509 da Internet, RFC 5280, DOI 10.17487/RFC5280Maio de 2008<>.Hoffman, P.eJ. Schaad, Novos Módulos ASN.1 para a Infraestrutura de Chave Pública Utilizando X.509 (PKIX), RFC 5912, DOI 10.17487/RFC5912Em junho de 2010,<>.Leiba, B., Ambiguidade entre Maiúsculas e Minúsculas nas Palavras-Chave do RFC 2119, BCP 14, RFC 8174, DOI 10.17487/RFC8174em maio de 2017,<>.ITU-T, Tecnologia da Informação -- Notação Sintática Abstrata Um (ASN.1): Especificação da notação básica, Recomendação ITU-T X.680, ISO/IEC 8824-1:2021, Fevereiro de 2021,<https://www.itu.int/rec/T-REC-X.680>.

8.2. Referências Informativas

[IEEERA]Associação de Padrões IEEE, Diretrizes para o Uso de Identificador Único Estendido (EUI), Identificador Único Organizacional (OUI) e ID de Empresa (CID), 3 de agosto de 2017,<https://standards.ieee.org/wp-content/uploads/import/documents/tutorials/eui.pdf>[RFC 9542]Eastlake 3º, D., Abley, J.e outrosY. Li, Considerações IANA e Uso de Protocolos e Documentação da IETF para Parâmetros IEEE 802, BCP 141, RFC 9542, DOI 10.17487/RFC9542Em abril de 2024,<>.

Agradecimentos

Agradecemos aos participantes da lista de correio do Grupo de Trabalho LAMPS por seus comentários e feedback perspicazes. Em particular, os autores expressam sua sincera gratidão aBob Beck, David von Oheimb, Deb Cooley, François Rousseau, Jacqueline McCall, John Preuß Mattsson, Mahesh Jethanandani, Mohamed Boucadair, Murray Kucherawy, Sean Turnere outros colaboradoresTim HollebeekAgradecemos a eles pelas revisões e sugestões, que melhoraram muito a qualidade deste documento.

Endereços dos Autores

Russ Housley
Vigil Security, LLC
Corey Bonnell
TurboLight Solutions, LLC
Joe Mandel
AKAYLA, Inc.
Tomofumi Okubo
Penguin Securities Pte. Ltd.
Michael StJohns
NthPermutation Security LLC
RFC (em português: RFC - Solicitação de Comentários) 10031Endereços de Controle de Acesso de Mídia (MAC) em Certificados X.509
Padrão Proposto
Fonte
RFC Editor
Abrir original ↗

Conteúdo traduzido automaticamente por máquina.

Esta notícia foi útil?

Debates 0

Seja o primeiro a contribuir com o debate.

Difunda suas informações e promova seu argumento

Não se acanhe de publicar alguma informação ou dado que possa ser positivo ou útil.

Para participar do debate, entre com sua conta ou crie uma gratuita.