Exibindo 13 de 13
O primeiro campo de um registro TLSA.
| Valor | Sigla | Descrição | Referências |
|---|---|---|---|
0Nota | PKIX-TA | PKIX-TA (0) é o uso de certificado TLSA “CA constraint”. | RFC 6698 |
1 | PKIX-EE | PKIX-EE (1) é o uso de certificado TLSA “Service certificate constraint”. | RFC 6698 |
2Nota | DANE-TA | DANE-TA (2) é o uso de certificado TLSA “Trust anchor assertion”. | RFC 6698 |
3Nota | DANE-EE | DANE-EE (3) é o uso de certificado TLSA “Domain-issued certificate”. | RFC 6698 |
255 | PrivCert | PrivCert (255) é o uso de certificado TLSA “Reserved for Private Use”. | RFC 6698 |
| Intervalo | Status | Descrição |
|---|---|---|
| 4–254 | unassigned | Unassigned |
Fonte: DNS-Based Authentication of Named Entities (DANE) Parameters (IANA), consultada em 2026-10-20. Licença dos dados: CC0-1.0. TLSA Certificate Usages
PKIX-TA (0) exige uma cadeia até uma CA pública e que essa CA corresponda ao registro TLSA; a RFC 7672 o desaconselha para SMTP.
Os usos 0 e 1 acrescentam uma restrição de DNS à validação comum da Web PKI. Para SMTP entre servidores de e-mail, a RFC 7672 §3.1.3 diz que os registros TLSA NÃO DEVERIAM usá-los: um atacante capaz de falsificar o DNS consegue substituí-los de qualquer forma, e os servidores de e-mail não compartilham uma lista comum de CAs confiáveis.
DANE-TA (2) fixa no DNS uma âncora de confiança — normalmente a CA emissora.
Com o uso 2, a cadeia do servidor precisa levar ao certificado ou à chave do registro TLSA, que não precisa ser de uma CA pública. A RFC 7672 §3.1.2 exige que o servidor envie a âncora de confiança na cadeia quando o registro corresponde a uma chave, e não a um certificado completo.
DANE-EE (3) fixa no DNS o próprio certificado ou a chave do servidor; os nomes e a expiração do certificado não são verificados.
Com o uso 3, o registro TLSA sozinho vincula a chave ao nome: a RFC 7672 §3.1.1 diz que o servidor é autenticado mesmo que nenhum nome do certificado corresponda e que a data de expiração do certificado DEVE ser ignorada. O registro comum “3 1 1” (DANE-EE, SPKI, SHA-256) sobrevive às renovações do certificado enquanto a chave continuar a mesma.
O segundo campo de um registro TLSA.
| Valor | Sigla | Descrição | Referências |
|---|---|---|---|
0 | Cert | Cert (0) é o seletor TLSA “Full certificate”. | RFC 6698 |
1 | SPKI | SPKI (1) é o seletor TLSA “SubjectPublicKeyInfo”. | RFC 6698 |
2 | C509 | C509 (2) é o seletor TLSA “C509Certificate”. | RFC-ietf-cose-cbor-encoded-cert-21 |
255 | PrivSel | PrivSel (255) é o seletor TLSA “Reserved for Private Use”. | RFC 6698 |
| Intervalo | Status | Descrição |
|---|---|---|
| 3–254 | unassigned | Unassigned |
Fonte: DNS-Based Authentication of Named Entities (DANE) Parameters (IANA), consultada em 2026-10-20. Licença dos dados: CC0-1.0. TLSA Selectors
O terceiro campo de um registro TLSA.
| Valor | Sigla | Descrição | Referências |
|---|---|---|---|
0 | Full | Full (0) é o tipo de correspondência TLSA “No hash used”. | RFC 6698 |
1 | SHA2-256 | SHA2-256 (1) é o tipo de correspondência TLSA “256 bit hash by SHA2”. | RFC 6234 |
2 | SHA2-512 | SHA2-512 (2) é o tipo de correspondência TLSA “512 bit hash by SHA2”. | RFC 6234 |
255 | PrivMatch | PrivMatch (255) é o tipo de correspondência TLSA “Reserved for Private Use”. | RFC 6698 |
| Intervalo | Status | Descrição |
|---|---|---|
| 3–254 | unassigned | Unassigned |
Fonte: DNS-Based Authentication of Named Entities (DANE) Parameters (IANA), consultada em 2026-10-20. Licença dos dados: CC0-1.0. TLSA Matching Types