Английская Википедия:DNS Certification Authority Authorization

Материал из Онлайн справочника
Перейти к навигацииПерейти к поиску

Шаблон:Short description Шаблон:Good article Шаблон:Use American English Шаблон:Use mdy dates Шаблон:Infobox technology standard DNS Certification Authority Authorization (CAA) is an Internet security policy mechanism that allows domain name holders to indicate to certificate authorities whether they are authorized to issue digital certificates for a particular domain name. It does this by means of a "CAA" Domain Name System (DNS) resource record.

It was drafted by computer scientists Phillip Hallam-Baker and Rob Stradling in response to increasing concerns about the security of publicly trusted certificate authorities. It is an Internet Engineering Task Force (IETF) proposed standard.

Background

A series of incorrectly issued certificates from 2001 onwards[1][2] damaged trust in publicly trusted certificate authorities,[3] and accelerated work on various security mechanisms, including Certificate Transparency to track mis-issuance, HTTP Public Key Pinning and DANE to block mis-issued certificates on the client-side, and CAA to block mis-issuance on the certificate authority side.[4]

The first draft of CAA was written by Phillip Hallam-Baker and Rob Stradling, and submitted as an IETF Internet Draft in October 2010.[5] This was progressively improved by the PKIX Working Group,[6] and approved by the IESG as Шаблон:IETF RFC, a Proposed Standard, in January 2013.[7] CA/Browser Forum discussion began shortly afterward,[4] and in March 2017 they voted in favor of making CAA implementation mandatory for all certificate authorities by September 2017.[8][9] At least one certificate authority, Comodo, failed to implement CAA before the deadline.[10] A 2017 study by the Technical University of Munich found many instances where certificate authorities failed to correctly implement some part of the standard.[4]

In September 2017, Jacob Hoffman-Andrews submitted an Internet Draft intended to simplify the CAA standard. This was improved by the LAMPS Working Group, and approved as Шаблон:IETF RFC, a Proposed Standard, in November 2019.[11]

Шаблон:As of, Qualys reports that still, only 6.8% of the 150,000 most popular TLS-supporting websites use CAA records.[12]

Record

Certificate authorities implementing CAA perform a DNS lookup for CAA resource records, and if any are found, ensure that they are listed as an authorized party before issuing a digital certificate. Each CAA resource record consists of the following components:[11]

flag
A flags byte which implements an extensible signaling system for future use. Шаблон:As of, only the issuer critical flag has been defined, which instructs certificate authorities that they must understand the corresponding property tag before issuing a certificate.[11] This flag allows the protocol to be extended in the future with mandatory extensions,[4] similar to critical extensions in X.509 certificates.
tag
One of the following property:
issue
This property authorizes the holder of the domain specified in associated property value to issue certificates for the domain for which the property is published.
issuewild
This property acts like issue but only authorizes the issuance of wildcard certificates, and takes precedence over the issue property for wildcard certificate requests.
iodef
This property specifies a method for certificate authorities to report invalid certificate requests to the domain name holder using the Incident Object Description Exchange Format. Шаблон:As of, not all certificate authorities support this tag, so there is no guarantee that all certificate issuances will be reported.
contactemail
Increasingly, contact information is not available in WHOIS due to concerns about potential GDPR violations. This property allows domain holders to publish contact information in DNS.[13][14]
contactphone
As above, for phone numbers.[15]
value
The value associated with the chosen property tag.

The lack of any CAA records authorizes normal unrestricted issuance, and the presence of a single blank issue tag disallows all issuance.[11][9][16]

Third parties monitoring certificate authority behavior might check newly issued certificates against the domain's CAA records. Шаблон:IETF RFC states; CAA records MAY be used by Certificate Evaluators as a possible indicator of a security policy violation. Such use SHOULD take into account the possibility that published CAA records changed between the time a certificate was issued and the time at which the certificate was observed by the Certificate Evaluator.[11]

Extensions

Шаблон:IETF RFC specifies "accounturi" and "validationmethods" parameters which allow users to specify desired methods of domain control validation as defined in ACME protocol. For example, website administrator can bind a domain they control to particular account registered with their desired Certification Authority.

History

A draft of the first extension to the CAA standard was published on October 26, 2016, proposing a new account-uri token to the end of the issue property, which ties a domain to a specific Automated Certificate Management Environment account.[17] This was amended on August 30, 2017, to also include a new validation-methods token, which ties a domain to a specific validation method,[18] and then further amended on June 21, 2018, to remove the hyphen in account-uri and validation-methods making them instead accounturi and validationmethods.[19]

Examples

To indicate that only the certificate authority identified by ca.example.net is authorized to issue certificates for example.com and all subdomains, one may use this CAA record:[11] Шаблон:Sxhl To disallow any certificate issuance, one may allow issuance only to an empty issuer list: Шаблон:Sxhl To indicate that certificate authorities should report invalid certificate requests to an email address and a Real-time Inter-network Defense endpoint:

Шаблон:Sxhl

To use a future extension of the protocol, for example, one which defines a new future property, which needs to be understood by the certificate authority before they can safely proceed, one may set the issuer critical flag: Шаблон:Sxhl

Incidents

In 2017, Camerfirma was found to improperly validate CAA records. Camerfirma claimed to have misunderstood the CA/Browser Forum Baseline Requirements describing CAA validation.[20][4]

In early 2020, Let's Encrypt disclosed that their software improperly queried and validated CAA records potentially affecting over 3 million certificates.[21] Let's Encrypt worked with customers and site operators to replace over 1.7 million certificates, but decided not to revoke the rest to avoid client downtime and since the affected certificates would all expire in less than 90 days.[22]

See also

References

Шаблон:Reflist

External links

Шаблон:SSL/TLS

Партнерские ресурсы
Криптовалюты
Магазины
Хостинг
Разное

  1. ↑ Шаблон:Cite web
  2. ↑ Шаблон:Cite news
  3. ↑ Шаблон:Cite journal
  4. ↑ 4,0 4,1 4,2 4,3 4,4 Шаблон:Cite journal
  5. ↑ Шаблон:Cite IETF
  6. ↑ Шаблон:Cite IETF
  7. ↑ Шаблон:Cite IETF
  8. ↑ Шаблон:Cite web
  9. ↑ 9,0 9,1 Шаблон:Cite web
  10. ↑ Шаблон:Cite news
  11. ↑ 11,0 11,1 11,2 11,3 11,4 11,5 Шаблон:Cite IETF
  12. ↑ Шаблон:Cite web
  13. ↑ Шаблон:Cite web
  14. ↑ https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.3.pdf Шаблон:Bare URL PDF
  15. ↑ Шаблон:Cite mailing list
  16. ↑ Шаблон:Cite web
  17. ↑ Шаблон:Cite IETF
  18. ↑ Шаблон:Cite IETF
  19. ↑ Шаблон:Cite IETF
  20. ↑ Шаблон:Cite web
  21. ↑ Шаблон:Cite web
  22. ↑ Шаблон:Cite magazine
Источник — http://wikihandbk.com/ruwiki/index.php?title=Английская_Википедия:DNS_Certification_Authority_Authorization&oldid=14151609