서비스 소개 | 새 소식 | 사용 안내 | 자주 묻는 질문 | 통계 | 개인 정보 보호

사용 방법에 대해선 사용 안내서를 읽어보세요.

이 서버가 "SKS" 풀에 포함돼 있나요?

아니요. SKS 풀이 채택한 연합 모델은 안정성, 악용 방지, 개인 정보 보호, 사용성 등의 부분에서 많은 문제를 안고 있습니다. keys.openpgp.org 서비스도 언젠가는 그 비슷한 걸 할 지도 모르지만, 직접적으로 SKS 풀의 일부가 되는 일은 절대 없을 겁니다.

keys.openpgp.org 서비스는 현재 연합의 일부인가요? 인스턴스 운영 등의 도움은 필요없나요?

지금 당장은 아닙니다. 물론 미래에는 keys.openpgp.org 서비스를 완전히 분산화할 계획이긴 합니다. 이를 통해 독립적인 운영 주체들이 다수의 서버를 각각 운영함으로써 서비스의 안정성을 더 끌어올릴 수 있길 기대하고 있습니다.

몇몇 사람들이 "Hagrid 서버 인스턴스 운영"을 통해 우리를 돕겠다고 연락해오긴 했습니다. 이러한 의사를 밝혀주신 건 고맙지만, SKS처럼 누구나 인스턴스를 운영함으로써 "풀"에 참여할 수 있는 "열린" 연합 모델은 절대 우리가 원하는 게 아니에요. 두 가지 이유가 있습니다:

  1. 누구나 참여 가능한 연합 모델은 필연적으로 모든 데이터가 공개되어야 가능합니다. 이렇게 활짝 열려있다면 누구든 전자 메일 주소 데이터에 손쉽게 접근할 수 있고, 당연히 사용자의 개인 정보 보호에 큰 지장을 줄 수밖에 없지요.
  2. 일반적인 지식을 가진 "캐주얼한" 관리자가 취미로 운영하는 서버 수준으로는 우리가 필요로 하는 안정성과 성능 기준을 달성하기 힘듭니다.

왜 전자 메일 주소 이외의 명의 정보는 지원하지 않나요?

우리는 명의 정보의 배포에 앞서 명시적인 동의를 받고 있습니다. 사진이나 웹 사이트 URL 같은, 전자 메일 주소가 아닌 명의 정보로는 이러한 동의를 받는 것 자체가 매우 힘듭니다.

참고하세요: 어떤 OpenPGP 소프트웨어는 올바르지 않은 형식의 전자 메일 주소를 담은 키를 생성하기도 합니다. keys.openpgp.org 서비스는 이러한 주소를 인식하지 못할 수도 있습니다.

하나의 전자 메일 주소에 대해 키 여러 개를 인증할 수 있나요?

하나의 전자 메일 주소는 오로지 하나의 키에 대해서만 엮을 수 있습니다. 만약 어떤 전자 메일 주소가 새 키에 대해 인증된다면, 과거에 이 주소로 인증됐던 모든 키와의 연계가 해제될 거예요. 물론 비-명의 정보는 모든 키에 대해 여전히 공개됩니다.

이게 무슨 얘기냐 하면, 어떤 전자 메일 주소로 키를 찾으면 무조건 단 하나의 키만 나온다는 거예요. 이렇게 함으로써, 사용자가 스스로는 절대 답변 불가능한 "도대체 어떤 키가 맞는 걸까?"와 같은 의문점을 아예 원천 차단하고, 전자 메일 주소로 키를 찾는 과정이 훨씬 편해지는 거죠.

이 서비스가 전자 메일을 발신할 때는 어떤 종류의 보호 수단을 적용하고 있나요?

우리는 MTA-STS라는 최신 표준과 EFF의 STARTTLS Everywhere 프로젝트 둘 다를 이용해 인증 전자 메일이 안전하게 발송될 수 있도록 노력합니다. 이렇게 함으로써 전송 과정에서의 도청이나 개입을 방지할 수 있죠.

MTA-STS 방식은 수신자의 전자 메일 서비스 제공자가 이 방식을 지원할 때만 제대로 동작합니다. 수신자의 전자 메일 서비스 제공자가 MTA-STS 방식을 지원하지 않으면, 전자 메일은 그냥 기존처럼 별다른 추가 보호 없이 전송돼요. 내 전자 메일 서비스 제공자가 이 방식을 제대로 지원하고 있는지 여부는 여기서 테스트해볼 수 있습니다. 만약 왼쪽 목록에서 "MTA-STS" 항목에 녹색 체크 마크가 없다면, 내 전자 메일 서비스 제공자에게 연락해서 설정을 바꿔 달라고 요청해보세요.

혹시 "제삼자 서명"도 배포하나요?

한 줄 요약: 아뇨.

"제삼자 서명"이라 함은 다른 누군가의 키가 내 키에 남긴 서명을 뜻합니다. 대개의 경우 "제삼자 서명"이란 누군가가 "다른 사람의 키를 서명"하면 만들어지는 것으로, 원래 이를 통해서 "신뢰 그물망"을 구성하곤 했습니다. 하지만 몇몇 문제점으로 인해서 keys.openpgp.org 서비스는 현재 제삼자 서명을 배포하지 않습니다.

제일 큰 문제는 스팸입니다. 제삼자 서명은 어떤 키에 대해 임의의 데이터를 갖다붙일 수 있게 하는데, 이를 통해서 악의적인 누군가가 키에 수 메가바이트 이상의 쓰레기 정보를 이어붙여서 키 자체를 못쓸 것으로 만들어버릴 수가 있습니다. 한 술 더 떠서, 키에 모욕적이거나 법에 저촉되는 내용을 달아버리는 것도 가능하죠.

이 문제를 해결하고자 여러 대안이 제시됐습니다. 개중 하나를 예로 들자면, 기존에는 서명된 키의 주인이 배포하던 제삼자 서명을 서명한 본인이 배포하도록 하는 게 있겠네요. 또는, caff식 서명 절차처럼 서명자와 서명되는 키 주인 서로가 서로의 키를 상호 서명한 경우에 한해 배포를 허용하는 것도 한 방법이고요. 추후 이 주제에 대해 충분한 관심이 생긴다면, 다른 OpenPGP 프로젝트와 연계하여 해결 방안을 강구할 용의도 있습니다.

왜 인증 후에 키를 서명해주지 않나요?

keys.openpgp.org 서비스는 키 배포와 발견에 중점을 두고 있지, 사실상의 인증 기관으로 행세하려는 게 아니에요. 상호 검증된 참여자끼리의 통신을 필요로 하는 클라이언트 구현체는 스스로의 신뢰 모델을 만들어 쓰기를 권장합니다.

왜 폐기된 명의는 배포가 중지되나요?

어떤 OpenPGP 키에 들어있는 명의 중 하나가 폐기된다면, 그 순간부터 이 명의는 해당 키에 대해 '올바르지 않은 것'으로 간주됩니다. 그리고, 이상적으로는, 기존에 이 명의를 알고 있던 모든 OpenPGP 클라이언트가 폐기 사실에 대해 전달받아야 하고요.

애석하게도, 폐기된 명의를 공개하지 않으면서 동시에 폐기 사실을 널리 알릴수 있는 그런 방법이 아직까지는 없습니다. 폐기된 명의를 배포하는 건 지양하고 싶기에, 그 명의 자체를 공개할 수는 없는 거죠.

일단, 폐기된 명의 그 자체를 공개하지는 않으면서 폐기 사실을 배포 가능하게끔 제안된 방법이 몇 가지가 있긴 합니다. 문제는, 아직 확정된 명세서가 존재하는 것도 아니고, 이걸 지원하는 OpenPGP 소프트웨어가 하나도 없다는 거예요. 우리도 이게 근시일 내에 확정되길 원합니다. 확정만 되면 keys.openpgp.org 서비스에 그 지원을 추가할 거고요.

왜 도메인 같은 전자 메일 주소의 일부분으로는 키 찾기가 안 되나요?

일부 키서버는 전자 메일 주소의 일부분만으로도 키를 찾을 수 있게 허용합니다. 그런데 말이죠, 이게 허용되면 키만 찾을 수 있는 게 아니라, "gmail 닷 com으로 끝나는 전자 메일 주소를 가진 키를 찾기"와 같이 임의의 전자 메일 주소를 대량으로 찾을 수 있게 하는 거거든요. 아예 모든 전자 메일 주소를 대놓고 공개하는 것과 진배없는 겁니다.

keys.openpgp.org 서비스는 완전한 전자 메일 주소에 해당하는 키 단 하나만을 반환하게 만들어졌습니다. 이렇게 하면 사용자는 이미 알고 있는 전자 메일 주소에 대한 키를 손쉽게 찾을 수는 있지만, 완전히 새로운 전자 메일 주소를 찾아내는 건 할 수 없지요. 이를 통해 스패머나 악의적인 사용자가 서버에 담긴 모든 전자 메일 주소의 목록을 뽑아내는 걸 방지합니다.

이건 개인 정보 보호 정책의 일부이기 때문에, 사용자 동의 없이 우리가 멋대로 이 설계를 고칠 수는 없습니다.

Tor 지원하세요?

물론이죠! 이미 Tor를 설치했다면 다음 주소로 keys.openpgp.org onion 서비스에 익명 접속이 가능합니다:
zkaan2xfbuxia2wpf7ofnkbz6r5zdbbvxbunvp5g2iebopbfc4iqmbad.onion

왜 인증 전자 메일은 암호화하지 않나요?

이유야 많죠:
  1. 사용자 입장에서나 우리 입장에서나 이게 간단한 게 아니에요.
  2. 이런다고 공격을 방지하지는 못합니다. (그런데 사실 공격자는 소유권이 없는 키를 올려서 얻는 게 하나도 없습니다.)
  3. 사용자가 키를 분실하더라도 주소 지우기는 가능해야 합니다.
  4. 오로지 서명만 가능한 키를 올리는 경우에는 별도의 인증 절차가 필요할 테고, 이러면 상황이 복잡해집니다.

GnuPG를 쓰는데요, 몇몇 키는 갱신이 안 되네요? 버그인가요?

GnuPG는 명의 정보가 없는 키를 올바르지 않은 키로 취급하여 가져오기 등의 처리를 거부합니다. 그런데, 인증된 전자 메일 주소가 없는 키라 할지라도 아직 유용한 정보는 담고있기 마련이거든요. 예를 들자면, 키가 폐기됐는지 아닌지 여부는 여전히 확인 가능하다 이겁니다.

2019년 6월에 keys.openpgp.org 팀은 GnuPG가 명의 정보 없는 키 역시 처리를 제대로 하도록 수정하는 패치를 준비했습니다. 이 패치는 곧바로 Debian, Fedora, NixOS 등의 배포판에 내장된 GnuPG와 macOS용 GPG Suite에 적용됐지요.

2020년 3월, GnuPG 팀은 이 패치를 승인하길 거부하고, 이 문제를 "고치지 않겠다(wontfix)"고 선언했습니다. 이 말인즉슨, 패치가 적용되지 않은 GnuPG 버전은 앞으로도 keys.openpgp.org 키서버에서 전자 메일 주소가 포함되지 않은 키를 받아올 수 없다는 거죠. 이 문제에 대한 지금까지의 논의사항은 GnuPG 버그 트래커의 T4393번 티켓에서 볼 수 있습니다.

내 GnuPG가 이 문제를 겪는지 안 겪는지 아래 방법으로 알아봅시다.

테스트 키 가져오기:

$ 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

패치가 적용됐다면, 로컬에서 이미 알고 있는 키에 대해 갱신을 시도합니다:

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

패치가 적용 안 됐다면, 명의 정보 없는 키는 여전히 처리가 거부될 겁니다:

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