hagrid-keyserver--hagrid/templates-translated/ko/about/faq.html.hbs

<div class="about">
    <center><h2>
<a href="/about">서비스 소개</a> | <a href="/about/news">새 소식</a> | <a href="/about/usage">사용 안내</a> | 자주 묻는 질문 | <a href="/about/stats">통계</a> | <a href="/about/privacy">개인 정보 보호</a>
</h2></center>

    <p><strong>사용 방법에 대해선 <a href="/about/usage">사용 안내서</a>를 읽어보세요.</strong></p>

    <h3 id="sks-pool"><a href="#sks-pool">이 서버가 "SKS" 풀에 포함돼 있나요?</a></h3>

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

    <h3 id="federation"><a href="#federation">keys.openpgp.org 서비스는 현재 연합의 일부인가요? 인스턴스 운영 등의 도움은 필요없나요?</a></h3>

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

    <p>몇몇 사람들이 "Hagrid 서버 인스턴스 운영"을 통해 우리를 돕겠다고 연락해오긴 했습니다. 이러한 의사를 밝혀주신 건 고맙지만, SKS처럼 누구나 인스턴스를 운영함으로써 "풀"에 참여할 수 있는 "열린" 연합 모델은 절대 우리가 원하는 게 아니에요. 두 가지 이유가 있습니다:</p>
    <ol>
<li>누구나 참여 가능한 연합 모델은 필연적으로 모든 데이터가 공개되어야 가능합니다. 이렇게 활짝 열려있다면 누구든 전자 메일 주소 데이터에 손쉽게 접근할 수 있고, 당연히 사용자의 개인 정보 보호에 큰 지장을 줄 수밖에 없지요.</li>
        <li>일반적인 지식을 가진 "캐주얼한" 관리자가 취미로 운영하는 서버 수준으로는 우리가 필요로 하는 안정성과 성능 기준을 달성하기 힘듭니다.</li>
    </ol>
<h3 id="non-email-uids"><a href="#non-email-uids">왜 전자 메일 주소 이외의 명의 정보는 지원하지 않나요?</a></h3>

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

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

    <h3 id="verify-multiple"><a href="#verify-multiple">하나의 전자 메일 주소에 대해 키 여러 개를 인증할 수 있나요?</a></h3>

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

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

    <h3 id="email-protection"><a href="#email-protection">이 서비스가 전자 메일을 발신할 때는 어떤 종류의 보호 수단을 적용하고 있나요?</a></h3>

    <p>우리는 <a href="https://www.hardenize.com/blog/mta-sts" target="_blank">MTA-STS</a>라는 최신 표준과 EFF의 <a href="https://starttls-everywhere.org/" target="_blank">STARTTLS Everywhere</a> 프로젝트 둘 다를 이용해 인증 전자 메일이 안전하게 발송될 수 있도록 노력합니다. 이렇게 함으로써 전송 과정에서의 도청이나 개입을 방지할 수 있죠.</p>

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

    <h3 id="third-party-signatures"><a href="#third-party-signatures">혹시 "제삼자 서명"도 배포하나요?</a></h3>

    <p>한 줄 요약: 아뇨.</p>

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

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

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

    <h3 id="no-sign-verified"><a href="#no-sign-verified">왜 인증 후에 키를 서명해주지 않나요?</a></h3>

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

    <h3 id="revoked-uids"><a href="#revoked-uids">왜 폐기된 명의는 배포가 중지되나요?</a></h3>

    <p>어떤 OpenPGP 키에 들어있는 명의 중 하나가 폐기된다면, 그 순간부터 이 명의는 해당 키에 대해 '올바르지 않은 것'으로 간주됩니다. 그리고, 이상적으로는, 기존에 이 명의를 알고 있던 모든 OpenPGP 클라이언트가 폐기 사실에 대해 전달받아야 하고요.</p>
    <p>애석하게도, 폐기된 명의를 공개하지 않으면서 동시에 폐기 사실을 널리 알릴수 있는 그런 방법이 아직까지는 없습니다. 폐기된 명의를 배포하는 건 지양하고 싶기에, 그 명의 자체를 공개할 수는 없는 거죠.</p>
    <p>일단, 폐기된 명의 그 자체를 공개하지는 않으면서 폐기 사실을 배포 가능하게끔 제안된 방법이 몇 가지가 있긴 합니다. 문제는, 아직 확정된 명세서가 존재하는 것도 아니고, 이걸 지원하는 OpenPGP 소프트웨어가 하나도 없다는 거예요. 우리도 이게 근시일 내에 확정되길 원합니다. 확정만 되면 <span class="brand">keys.openpgp.org</span> 서비스에 그 지원을 추가할 거고요.</p>

    <h3 id="search-substring"><a href="#search-substring">왜 도메인 같은 전자 메일 주소의 일부분으로는 키 찾기가 안 되나요?</a></h3>

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

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

    <p>이건 <a href="/about/privacy">개인 정보 보호 정책</a>의 일부이기 때문에, 사용자 동의 없이 우리가 멋대로 이 설계를 고칠 수는 없습니다.</p>

    <h3 id="tor"><a href="#tor">Tor 지원하세요?</a></h3>

    <p>물론이죠! 이미 Tor를 설치했다면 다음 주소로 <span class="brand">keys.openpgp.org</span> <a href="https://support.torproject.org/onionservices/#onionservices-2" target="_blank">onion 서비스</a>에 익명 접속이 가능합니다:<br><a href="http://zkaan2xfbuxia2wpf7ofnkbz6r5zdbbvxbunvp5g2iebopbfc4iqmbad.onion">zkaan2xfbuxia2wpf7ofnkbz6r5zdbbvxbunvp5g2iebopbfc4iqmbad.onion</a></p>

    <h3 id="encrypt-verification-emails"><a href="#encrypt-verification-emails">왜 인증 전자 메일은 암호화하지 않나요?</a></h3>

    이유야 많죠:
    <ol>
<li>사용자 입장에서나 우리 입장에서나 이게 간단한 게 아니에요.</li>
        <li>이런다고 공격을 방지하지는 못합니다. (그런데 사실 공격자는 소유권이 없는 키를 올려서 얻는 게 하나도 없습니다.)</li>
        <li>사용자가 키를 분실하더라도 주소 지우기는 가능해야 합니다.</li>
        <li>오로지 서명만 가능한 키를 올리는 경우에는 별도의 인증 절차가 필요할 테고, 이러면 상황이 복잡해집니다.</li>
    </ol>
<h3 id="older-gnupg"><a href="#older-gnupg">GnuPG를 쓰는데요, 몇몇 키는 갱신이 안 되네요? 버그인가요?</a></h3>

    <p>GnuPG는 명의 정보가 없는 키를 올바르지 않은 키로 취급하여 가져오기 등의 처리를 거부합니다. 그런데, <a href="/about">인증된 전자 메일 주소</a>가 없는 키라 할지라도 아직 유용한 정보는 담고있기 마련이거든요. 예를 들자면, 키가 폐기됐는지 아닌지 여부는 여전히 확인 가능하다 이겁니다.</p>
    <p>2019년 6월에 <span class="brand">keys.openpgp.org</span> 팀은 GnuPG가 명의 정보 없는 키 역시 처리를 제대로 하도록 수정하는 패치를 준비했습니다. 이 패치는 곧바로 Debian, Fedora, NixOS 등의 배포판에 내장된 GnuPG와 macOS용 GPG Suite에 적용됐지요.</p>
    <p>2020년 3월, GnuPG 팀은 이 패치를 승인하길 거부하고, 이 문제를 "고치지 않겠다(wontfix)"고 선언했습니다. 이 말인즉슨, <strong>패치가 적용되지 않은 GnuPG 버전은 앞으로도 <span class="brand">keys.openpgp.org</span> 키서버에서 전자 메일 주소가 포함되지 않은 키를 받아올 수 없다</strong>는 거죠. 이 문제에 대한 지금까지의 논의사항은 GnuPG 버그 트래커의 <a href="https://dev.gnupg.org/T4393#133689">T4393번 티켓</a>에서 볼 수 있습니다.</p>
    <p>내 GnuPG가 이 문제를 겪는지 안 겪는지 아래 방법으로 알아봅시다.</p>
    <blockquote>
<span style="font-size: larger;">테스트 키 가져오기:</span><br><br>
      $ curl https://keys.openpgp.org/assets/uid-test.pub.asc | gpg --import<br>
      gpg: key F231550C4F47E38E: "Alice Lovelace &lt;alice@openpgp.example&gt;" imported<br>
      gpg: Total number processed: 1<br>
      gpg:               imported: 1<br><br>
</blockquote>
    <blockquote>
<span style="font-size: larger;">패치가 적용됐다면, 로컬에서 이미 알고 있는 키에 대해 갱신을 시도합니다:</span><br><br>
      $ gpg --recv-keys EB85BB5FA33A75E15E944E63F231550C4F47E38E<br>
      gpg: key F231550C4F47E38E: "Alice Lovelace &lt;alice@openpgp.example&gt;" not changed<br>
      gpg: Total number processed: 1<br>
      gpg:              unchanged: 1<br><br>
</blockquote>
    <blockquote>
<span style="font-size: larger;">패치가 적용 안 됐다면, 명의 정보 없는 키는 여전히 처리가 거부될 겁니다:</span><br><br>
      $ gpg --recv-keys EB85BB5FA33A75E15E944E63F231550C4F47E38E<br>
      gpg: key EB85BB5FA33A75E15E944E63F231550C4F47E38E: no user ID<br>
</blockquote>
</div>