DNS Certification Authority Authorization

**Otorisasi Penyelenggara Sertifikat Elektronik DNS** (**:** ***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 , 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. , 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). , 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 memublikasikan 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 masalah waktu henti pada klien dan karena semua sertifikat yang terpengaruh akan kedaluwarsa dalam waktu kurang dari 90 hari.

## Lihat juga

* Penyelenggara Sertifikat Elektronik

## Referensi

## Pranala luar

* RFC 8659