Share to:

DNS Certification Authority Authorization

Otorisasi Penyelenggara Sertifikat Elektronik DNS
StatusStandar yang diusulkan
Rilis pertama18 Oktober 2010
Versi terakhirRFC 8659
OrganisasiIETF
PenulisPhillip Hallam-Baker & Rob Stradling
SingkatanCAA

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.[1]

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).[2]

Latar belakang

Pada tahun 2001 dan setelahnya, Banyak sertifikat yang diterbitkan secara tidak benar[3][4] hal tersebut telah merusak kepercayaan pada penyelenggara sertifikat elektronik publik.[5] 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[6]

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

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.[7] Hingga bulan Januari 2020, Qualys melaporkan bahwa, hanya 6,8% dari 150.000 situs paling populer yang mendukung TLS yang telah menggunakan CAA.[13]

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:[8]

flag
Sebuah flag byte yang mengimplementasikan sistem sinyal yang dapat diperluas untuk penggunaannya di masa mendatang. Hingga 2018, hanya flag penerbit penting yang telah ditentukan, yang menginstruksikan penyelenggara sertifikat elektronik bahwa mereka harus memahami tag properti terkait sebelum menerbitkan sertifikat.[7] Flag ini memungkinkan protokol untuk diperpanjang di masa mendatang dengan penambahan ekstensi wajib,[6] 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, 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.[14][15]
contactphone
Seperti di atas, ini digunakan untuk nomor telepon.[16]
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.[7][11][17]

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.[7]

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.[18] Draf ini diubah pada tanggal 30 Agustus 2017, untuk memasukkan metode validation-methods yang baru,[19] 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.[20]

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.[7] 

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.[21]

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.[22] 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.[23]

Lihat juga

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. ^ a b c d 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. ^ a b c d e f 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. ^ a b 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. ^ a b 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. 
  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. 
  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
Kembali kehalaman sebelumnya