**Otorisasi Penyelenggara Sertifikat Elektronik DNS** ((Inggris)**:** ***Certification Authority Authorization*** disingkat menjadi CAA) merupakan sebuah mekanisme kebijakan keamanan internet yang memungkinkan pemilik nama domain untuk memastikan penerbit sertifikat digital melalui penyelenggara sertifikat elektronik apakah penerbit tersebut berwenang untuk menerbitkan sertifikat digital untuk nama domain tersebut. Hal ini dilakukan dengan mencatat sumber daya dari "CAA" Domain Name System (DNS) yang baru.

CAA dirancang oleh seorang Ilmuwan komputer Phillip Hallam-Baker dan Rob Stradling sebagai respons dari meningkatnya kekhawatiran tentang keamanan dari penyelenggara sertifikat elektronik terpercaya. Hal ini juga termasuk ke dalam Usulan Standar oleh Internet Engineering Task Force (IETF).

Latar belakang
--------------

Pada tahun 2001 dan setelahnya, Banyak sertifikat yang diterbitkan secara tidak benar hal tersebut telah merusak kepercayaan pada penyelenggara sertifikat elektronik publik. CAA hadir untuk mempercepat kinerja pada berbagai mekanisme keamanan, termasuk *Certificate Transparency* (CT). *HTTP Public Key Pinning* (HPKP) dan *DNS-based Authentication of Named Entities* (DANE) yang bertugas memblokir sertifikat yang bermasalah penerbitan nya dari sisi klien, sedangkan CAA bertugas memblokir penerbitan yang salah dari sisi penyelenggara sertifikat elektronik

Draf pertama dari CAA ditulis oleh Phillip Hallam-Baker dan Rob Stradling, kemudian diajukan sebagai *Internet draf* IETF pada bulan Oktober 2010. Rancangan tersebut kemudian dikembangkan lebih lanjut oleh Kelompok Kerja PKIX dengan penambahan infrastruktur kunci publik X.509, dan disetujui oleh IESG sebagai Usulan Standar dengan kode RFC 6844, pada bulan Januari 2013. Diskusi *CA/Browser Forum* dimulai setelah masuk sebagai Usulan Standar, Baru ketika Maret 2017, mereka memutuskan untuk mewajibkan implementasi CAA untuk seluruh penyelenggara sertifikat elektronik pada bulan September 2017. Setidaknya ada satu penyelenggara sertifikat elektronik, Comodo, yang gagal mengimplementasikan CAA setelah batas waktu berakhir. Pada tahun 2017, Universitas Teknik München menemukan banyak penyelenggara sertifikat elktronik yang gagal mengimplementasikan standar CAA dengan benar.

Pada bulan September 2017, Jacob Hoffman-Andrews mengajukan draf internet yang dimaksudkan untuk menyederhanakan standar dari CAA, Standar tersebut kemudian dikembangkan kembali oleh LAMPS Working Group, dan disetujui sebagai RFC 8659, sebagai Usulan Standar, pada bulan November 2019. Hingga bulan Januari 2020, Qualys melaporkan bahwa, hanya 6,8% dari 150.000 situs paling populer yang mendukung TLS yang telah menggunakan CAA.

Catatan
-------

Penyelenggara sertifikat elektronik yang menerapkan CAA dapat melakukan pencarian DNS pada catatan sumber daya CAA. Jika penyelenggara sertifikat elektronik ditemukan, CAA memastikan bahwa Penyelenggara sertifikat elektronik tersebut terdaftar sebagai pihak yang berwenang sebelum diterbitkan sebagai sertifikat digital. setiap catatan sumber daya CAA terdiri dari komponen berikut:

flag
Sebuah flag byte yang mengimplementasikan sistem sinyal yang dapat diperluas untuk penggunaannya di masa mendatang. Hingga 2018[update], hanya *flag* penerbit penting yang telah ditentukan, yang menginstruksikan penyelenggara sertifikat elektronik bahwa mereka harus memahami tag properti terkait sebelum menerbitkan sertifikat. Flag ini memungkinkan protokol untuk diperpanjang di masa mendatang dengan penambahan ekstensi wajib, mirip dengan ekstensi penting dalam sertifikat X.509 .
tag
Berikut salah satu propertinya:
issue
Properti ini memberikan wewenang kepada pemegang domain yang ditentukan dalam nilai properti terkait untuk menerbitkan sertifikat domain yang propertinya telah diterbitkan.
issuewild
Properti ini memiliki fungsi yang sama seperti *issue* tetapi hanya mengizinkan penerbitan sertifikat sebagai *wildcard DNS*, dan *issuewild* lebih diutamakan daripada properti *issue* untuk permintaan sertifikat wildcard DNS.
iodef
Properti ini menetapkan metode penyelenggara sertifikat elektronik untuk melaporkan permintaan sertifikat yang tidak valid kepada pemegang nama domain menggunakan *Incident Object Description Exchange Format* (IODEF). Hingga 2018[update], tidak semua penyelenggara sertifikat elektronik mendukung tag ini, jadi tidak ada jaminan bahwa semua penerbitan sertifikat akan dilaporkan.
contactemail
Informasi kontak semakin tidak tersedia di WHOIS karena adanya kekhawatiran mengenai pelanggaran GDPR. Properti ini memungkinkan pemegang domain untuk mempublikasikan informasi kontak di DNS.
contactphone
Seperti di atas, ini digunakan untuk nomor telepon.
value
Value terkait dengan tag properti yang dipilih.
Kurangnya catatan dari CAA yang mengizinkan penerbitan normal yang tidak dibatasi, dan keberadaan tag kosong yang melarang semua penerbitan.

Pemantau penyelenggara sertifikat elektronik dari pihak ketiga memungkinkan melakukan pemeriksaan pada sertifikat yang baru diterbitkan terhadap catatan domain CAA, tetapi harus memperhatikan catatan domain dari CAA, bisa saja terjadi perubahan di antara waktu sertifikat tersebut di rilis dengan waktu pihak ketiga melakukan pengecekan. Pelanggan tidak boleh menggunakan CAA sebagai bagian dari proses validasi sertifikat.

Ekstensi
--------

RFC 8657 menentukan parameter `"accounturi"` and `"validationmethods"` yang memungkinkan pengguna menentukan metode validasi kontrol domain yang diinginkan seperti yang ditentukan dalam protokol ACME. Misalnya, administrator situs web dapat melakukan *binding* pada domain yang mereka kontrol ke akun tertentu yang terdaftar di otoritas sertifikasi yang diinginkan.

### Sejarah

Draf dari ekstensi pertama untuk standar CAA diterbitkan pada tanggal 26 Oktober 2016, mengusulkan token *account-uri* baru ke akhir *issue property*, yang melakukan *binding* pada domain ke akun spesifik *Automated Certificate Management Environment.* Draf ini diubah pada tanggal 30 Agustus 2017, untuk memasukkan metode *validation-methods* yang baru, dan kemudian diubah lebih lanjut pada tanggal 21 Juni 2018 untuk menghapus tanda pada *account-uri dan validation-methods* dan diubah menjadi *accounturi* dan *validationmethods.*

Contoh
------

Untuk menunjukkan bahwa hanya penyelenggara sertifikat elektronik yang diidentifikasi oleh *ca.example.net* yang berwenang untuk mengeluarkan sertifikat seperti example.com dan semua subdomain, salah satunya bisa menggunakan catatan CAA di bawah ini.

```
example.com.  IN  CAA 0 issue "ca.example.net"
```

Untuk melarang penerbitan sertifikat apa pun, *issue* bisa di isi dengan data kosong seperti:

```
example.com.  IN  CAA  0 issue ";"
```

Untuk menunjukkan bahwa penyelenggara sertifikat elektronik harus melaporkan permintaan sertifikat yang tidak valid ke alamat email dan *endpoint* dari Real-time Inter-network Defense.

```
example.com.  IN  CAA 0 iodef "mailto:security@example.com"
example.com.  IN  CAA 0 iodef "http://iodef.example.com/"

```
Untuk menggunakan perpanjangan protokol di masa mendatang, sebagai contoh, yang mendefinisikan properti *future* yang baru, perlu dipahami oleh penyelenggara sertifikat elektronik sebelum hal tersebut dapat dilanjutkan dengan aman, dapat di atur dengan tanda *issuer critical* :

```
example.com.  IN  CAA  0 issue "ca.example.net"
example.com.  IN  CAA  128 future "value"
```

Insiden kepatuhan yang diketahui
--------------------------------

Pada tahun 2017, Camerfirma ditemukan melakukan validasi catatan CAA secara tidak benar. Camerfirma diklaim telah salah memahami persyaratan dasar dari CA/Browser Forum yang menjelaskan validasi CAA.

Pada awal tahun 2020, Let's Encrypt mengungkapkan bahwa perangkat lunak mereka secara tidak benar melakukan memvalidasi catatan CAA yang berpotensi memengaruhi lebih dari 3 juta sertifikat. Let's Encrypt bekerja dengan pelanggan dan operator situs untuk mengganti lebih dari 1,7 juta sertifikat, tetapi memutuskan untuk tidak mencabut sisanya untuk menghindari permasalahan waktu henti pada klien dan karena semua sertifikat yang terpengaruh akan kedaluwarsa dalam waktu kurang dari 90 hari.

Lihat juga
----------

* Penyelenggara Sertifikat Elektronik

Referensi
---------

1. ↑  "What's new | Release Notes". *docs.fortinet.com* (dalam bahasa Inggris). Diakses tanggal 29 November 2021.
2. ↑  Hallam-Baker, Phillip; Stradling, Rob (2013). "RFC - Proposed Standard". *Internet Engineering Task Force (IETF)* (dalam bahasa Inggris).
3. ↑  Ristić, Ivan. "SSL/TLS and PKI History". *Feisty Duck*. Diakses tanggal 29 November 2021.
4. ↑  Bright, Peter (30 Agustus 2011). "Another fraudulent certificate raises the same old questions about certificate authorities". *Ars Technica* (dalam bahasa Inggris). Diakses tanggal 29 November 2021.
5. ↑  Ruohonen, Jukka (2019). "An Empirical Survey on the Early Adoption of DNS Certification Authority Authorization". *Journal of Cyber Security Technology* (dalam bahasa Inggris). **3** (4): 205 sampai 2018. doi:10.1080/23742917.2019.1632249.
6. 1 2 3 4  Scheitle, Quirin; Chung, Taejoong (April 2018). "A First Look at Certification Authority Authorization (CAA)" (PDF). *ACM SIGCOMM Computer Communication Review*. **48** (2): 10 sampai 23. doi:10.1145/3213232.3213235.
7. 1 2 3 4 5 6  Hallam-Baker, Phillip; Stradling, Rob (18 Oktober 2010). "DNS Certification Authority Authorization (CAA) Resource Record". *IETF. I-D draft-hallambaker-donotissue-00* (dalam bahasa Inggris).
8. 1 2  Hallam-Baker, Phillip; Stradling, Rob; Ben, Laurie (2 Juni 2011). "DNS Certification Authority Authorization (CAA) Resource Record". *IETF. I-D draft-ietf-pkix-caa-00* (dalam bahasa Inggris).
9. ↑  Hallam-Baker, Phillip; Stradling, Rob (Januari 2013). "DNS Certification Authority Authorization (CAA) Resource Record. IETF". *IETF* (dalam bahasa Inggris). doi:10.17487/RFC6844. ISSN 2070-1721.
10. ↑  Hall, Kirk (8 Maret 2017). "[cabfpub] Results on Ballot 187 - Make CAA Checking Mandatory" (dalam bahasa Inggris). Diakses tanggal 29 November 2021.
11. 1 2  Beattie, Doug (4 Juni 2021). "What is CAA (Certificate Authority Authorization)?". *GlobalSign GMO Internet, Inc.* (dalam bahasa Inggris). Diakses tanggal 29 November 2021.
12. ↑  Cimpanu, Catalin (11 September 2017). "Comodo Caught Breaking New CAA Standard One Day After It Went Into Effect". *BleepingComputer* (dalam bahasa Inggris). Diakses tanggal 29 November 2021.
13. ↑  "Qualys SSL Labs - SSL Pulse". *SSLLABS*. Diakses tanggal 29 November 2021.  Parameter `|first1=` tanpa `|last1=` di Authors list (bantuan)
14. ↑  "Public Key Infrastructure using X.509 (PKIX) Parameters". *www.iana.org* (dalam bahasa Inggris). Diakses tanggal 29 November 2021.
15. ↑  *Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates* (PDF). CA/Browser Forum. 2019.  Parameter `|url-status=` yang tidak diketahui akan diabaikan (bantuan); Parameter `|first1=` tanpa `|last1=` di Authors list (bantuan)
16. ↑  Beattie, Doug (7 Januari 2019). "[cabfpub] Ballot SC14: CAA Contact Property and Associated Phone Validation Methods". Diakses tanggal 29 November 2021.
17. ↑  "What is Certificate Authority Authorization (CAA)?". *Digicert*. Diakses tanggal 29 November 2021.
18. ↑  Landau, Hugo (26 Oktober 2016). "CAA Record Extensions for Account URI and ACME Method Binding". *IETF. I-D draft-ietf-acme-caa-00*.
19. ↑  Landau, Hugo (30 Agustus 2017). "CAA Record Extensions for Account URI and ACME Method Binding". *IETF. I-D draft-ietf-acme-caa-04*.
20. ↑  Landau, Hugo (21 Juni 2018). "CAA Record Extensions for Account URI and ACME Method Binding". *IETF. I-D draft-ietf-acme-caa-05*.
21. ↑  "CA:Camerfirma Issues - MozillaWiki". *wiki.mozilla.org*. Diakses tanggal 29 November 2021.
22. ↑  Francisco, Thomas Claburn in San. "Let's Encrypt? Let's revoke 3 million HTTPS certificates on Wednesday, more like: Check code loop blunder strikes". *www.theregister.com* (dalam bahasa Inggris). Diakses tanggal 29 November 2021.
23. ↑  Barrett, Brian. "The Internet Avoided a Minor Disaster Last Week". *Wired* (dalam bahasa Inggris). ISSN 1059-1028. Diakses tanggal 29 November 2021.

Pranala luar
------------

* RFC 8659