Hakkında | Haberler | Kullanım | SSS | İstatistikler | Mahremiyet

Yönergeler için, kullanma kılavuzumuza bakabilirsiniz.

Bu sunucu "SKS" havuzunun bir parçası mı?

Hayır. SKS havuzunun federasyon modeli güvenilirlik, istismar direnci, mahremiyet ve kullanışlık bağlamında bazı sorunlar içeriyor. Ona benzer bir şey yapabiliriz ama keys.openpgp.org hiç bir zaman SKS havuzunun bir parçası olmayacaktır.

keys.openpgp.org federe mi? Bir örneğini çalıştırarak yardımcı olabilir miyim?

Şu an değil. Bir noktadakeys.openpgp.org'u ademi merkeziyetçi yapmak istiyoruz. Bağımsız işleticiler tarafından çalıştırılan bir çok sunucuyla, umuyoruz ki hizmetin güvenilirliğini daha da geliştirmeyi yapabiliriz.

Bir çok insan "Hagrid sunucu örneği çalıştırma" konusunda yardımcı olmayı önerdi. Öneriyi takdirle karşılıyoruz ancak hiç bir zaman SKS gibi, insanların bir örnek çalıştırdığı ve bir "havuzun" parçası olduğu "açık" bir federasyon modeline sahip olacağımızı düşünmüyoruz. Bunun iki nedeni var:

  1. Açık katılımla federasyon bütün verinin kamuya açık olmasını gerektirir. Bu kaydadeğer bir şekilde kullanıcıların mahremiyetini etkileyecektir, çünkü her isteyen kişinin e-posta adreslerini elde etmesini sağlar.
  2. Sunucular, güvenilirlik ve başarım standartlarımızı karşılamayan plansız yöneticiler tarafından bir hobi olarak çalıştırılırlar.

E-posta adresi olmayan kimlikler neden desteklenmiyor?

Kimlik bilgisinin dağıtımı için açık bir rızaya ihtiyacımız var. E-posta adresi olmayan kimlik bilgisi, örneğin resim veya website URL'leri, bu rızayı talep etme konusunda zorluklar çıkarır.

Not: Bazı OpenPGP yazılımları anahtarları doğru bir şekilde biçimlenmemiş e-posta adresleriyle yaratıyor. Bu adresler keys.openpgp.org üzerinde doğru bir şekilde tanımlanamayabilir.

Aynı e-posta adresi için birden fazla anahtarı doğrulayabilir miyim?

Bir e-posta adresi ancak tek bir anahtarla eşlenebilir. Eğer bir adres yeni bii ranahtar için doğrulandığında, daha önce doğrulandığı hiç bir anahtarla birlikte listelenmez. Kimlik bilgisi olmayan kısımlarbütün anahtarlar için dağıtılmaya devam edecektir.

Bunun anlamı, e-posta adesiyle yapılan aramanın, bir çok seçenek değil, sadece bir anahtar döndüreceğidir. Bu kullanıcı için mümkün olmayan ("Acaba hangi anahtar doğrusuydu?") seçimi ortadan kaldırır ve e-posta ile anahtar keşfini oldukça elverişli kılar.

Dışa giden doğrulama e-postalarını korumak için ne yapıyorsunuz?

Doğrulama e-postalarının güvenli bir şekilde gönderildiğinden emin olmak için EFF'nin STARTTLS Everywhere ile birlikte MTA-STS adı verilen modern bir standart kullanıyoruz. Böylece teslimat sırasında gizli dinleme ve önlemeye karşı koruma sağlanıyor.

MTA-STS yöntemi ancak alıcının e-posta hizmeti sağlayıcısı destekliyorsa çalışır. Desteklenmiyorsa e-postalar olağan şekilde iletilecektir. Bu testi çalıştırıp e-posta hizmeti sağlayıcınızın destekleyip desteklemediğine bakabilirsiniz. Eğer "MTA-STS" girdisinin solunda yeşil onay imi yoksa, lütfen sağlayıcınızdan yapılandırmalarını güncellemelerini isteyin.

"Üçüncü parti imzaları" dağıtıyor musunuz?

Kısaca: hayır.

"Üçüncü parti imza" bir anahtardaki başka   bir anahtar tarafından yapılan bir imzadır.   Çoğunlukla,   bu imzalar "başkasının anahtarını imzalarken" üretilmiştir, bu işlem "Güven Ağı"nın temelidir.   Çeşitli nedenlerden dolayı,   bu imzalar şimdilik keys.openpgp.org   üzerinden dağıtılmıyor.

En önemli neden spam. Üçüncü parti imzaları herhangi bir kimsenin anahtarına keyfi veri eklenmesine olanak sağlar. Böylece kötü niyetli bir kimsenin megabaytlarca yığını bir anahtara eklemesini ve böylece onu kullanışsızlaştırmasını engelleyecek hiç bir imkan yoktur. Daha da kötüsü, saldırgan veya yasadışı içerik de ekleyebilirler.

Bu sorunu çözmeye yönelik fikirler var. Örneğin, imzalar, imza sahibi yerine sahibi onaylayan imzacıyla birlikte dağıtılabilir. Alternatif olarak, dağıtımdan önce imza sahibinden caff türü iş akışını desteklemek için çapraz imzalama istenebilir. Eğer yeterli bir ilgi varsa, OpenPGP projeleriyle birlikte bir çözüm üzerinde çalışmaya açığız.

Neden anahtarlar doğrulama sonrası imzalanmıyor?

keys.openpgp.org hizmeti anahtar dağımı ve keşfi içindir, fiili bir onay kurumu değildir. Doğrulanmış iletişim sağlamak isteyen istemci gerçekleştirimleri kendi güven modeline dayanmalıdır.

İptal edilen kimilkler neden bu şekilde dağıtılmıyor?

Bir OpenPGP anahtarı kimliklerinden birini iptal edilmiş olarak işaretlediğinde, bu kimlik artık anahtar için geçerli olarak kabul edilmemeli ve bu bilgi, halihazırda bu yeni iptal edilmiş kimliğe ilişkin bilgiye sahip tüm OpenPGP istemcilerine dağıtılmalıdır.

Maalesef, iptalleri dağıtmaya ilişkin, iptal edilen kimliğin kendisini de açığa vurmayan iyi bir yöntem yok. İptal edilmiş kimlikleri dağıtmak istemiyoruz, dolayısıyla kimliğin kendisini hiç dağıtamayız.

Kimliğin kendisini açığa vurmadan iptallerin dağıtımına olanak sağlayacak bazı yöntemler öneriliyor. Ancak henüz bitmiş bir belirtim veya OpenPGP yazılımında destek yok. Yakın gelecekte bir çözümün ortaya konulacağını düşünüyoruz ve öyle bir durumda keys.openpgp.orgtarafından da mümkün olduğunca çabuk destek eklenecektir.

Neden alan adında yapabildiğimiz gibi e-posta adresinin bir kısmıyla arama yapamıyoruz?

Bazı anahtar sunucuları e-posta adresinin bir kısmıyla anahtar aramasına izin veriyor. Bu sadece anahtarların değil, ayrıca "adres at gmail nokta com anahtarları" gibi bir sorguyla, adreslerin de bulunmasına yol açar. Bu etkin olarak bu anahtar sunucusundaki tüm anahtarların adreslerini bir bakıma herkese açık hale getirir.

keys.openpgp.org üzerinde e-posta adresiyle aramalar ancak tam eşleştiği e-posta adresinin anahtarını geri döndürür. Böylece, normal bir kullanıcı halihazırda bildiği herhangi bir adresle ilişkili anahtarı keşfedebilirken, yeni e-posta adreslerini keşfedemez. Bu, kötü niyetli kullanıcıların veya spamcıların sunucu üzerindeki tüm e-posta adreslerinin bir listesini edinmesini önler.

Bu kısıtlamayı gizlilik politikamızın bir parçası yaptık, böylece kullanıcıların rızasını almadan bu kısıtlamayı değiştiremeyiz.

Tor destekliyor musunuz?

Elbette! Eğer Tor kuruluysa, keys.openpgp.org adresine anonim olarak bir onion hizmeti şeklinde erişebilirsiniz:
zkaan2xfbuxia2wpf7ofnkbz6r5zdbbvxbunvp5g2iebopbfc4iqmbad.onion

Neden doğrulama e-postalarını şifrelemiyorsunuz?

Çeşitli nedenler:
  1. Çok daha karmaşıktır, hem kullanıcılar hem de bizim için.
  2. Saldırıları engellemiyor, bir saldırganın, erişimi olmadığı bir anahtarı yüklemekten bir kazancı olmuyor.
  3. Silme anahtar kaybolduğunda bile mümkün olacaktır.
  4. Sadece imzalamaya yarayan anahtarları yüklemek, farklı (ve çok daha karışık) bir yöntem gerektirecektir.

GnuPG ile bazı anahtarları güncellemekte sorun yaşıyorum, bu bir hata mıdır?

GnuPG kimlik bilgisi içermeyen anahtarları geçersiz olarak kabul eder ve onları içe aktarmayı reddeder. Ancak, doğrulanmış e-posta adresleri içermeyen bir anahtar da yararlı bir bilgi içerebilir. Özellikle anahtarın hükümsüz olup olmadığını denetlemek mümkündür.

2019 yılı Haziran ayında, keys.openpgp.org ekibi GnuPG'nin kimlik bilgisi içermeyen anahtarlardan güncelleme almasını sağlayan bir yama oluşturdu. Bu yama GnuPG'nin bir çok alt sürümünde (Debian, Fedora, NixOS ve macOS için GPG Suite) çabucak kullanılmaya başlandı.

2020 yılı Mart ayında GnuPG ekibi yamayı reddetti ve hata kaydının durumunu "Düzeltilmeyecek" olarak güncelledi. Bunun anlamı yamalanmamış GnuPG sürümlerinin, doğrulanmış herhangi bir e-posta adresi içermeyen anahtarlar için keys.openpgp.org sitesinden güncelleme alamayacağıdır. Bu karar hakkında daha fazla bilgiyi, GnuPG hata takip sistemindeki T4393 hata kaydında okuyabilirsiniz.

GnuPG sürümünüzün etkilenip etkilenmediğini aşağıdaki yönergelerle denetleyebilirsiniz:

Deneme anahtarını içe aktarın:

$ curl https://keys.openpgp.org/assets/uid-test.pub.asc | gpg --import
gpg: key F231550C4F47E38E: "Alice Lovelace <alice@openpgp.example>" imported
gpg: Total number processed: 1
gpg: imported: 1

Yamayla, yerel olarak biliniyorsa anahtar güncellenmektedir:

$ gpg --recv-keys EB85BB5FA33A75E15E944E63F231550C4F47E38E
gpg: key F231550C4F47E38E: "Alice Lovelace <alice@openpgp.example>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1

Yama olmadan, kimlik bilgisine sahip olmayan bir anahtar her zaman reddedilmektedir:

$ gpg --recv-keys EB85BB5FA33A75E15E944E63F231550C4F47E38E
gpg: key EB85BB5FA33A75E15E944E63F231550C4F47E38E: no user ID