Чем, если вообще, SSH-ключи отличаются от асимметричных ключей, используемых для других целей?

Чем, если вообще, SSH-ключи отличаются от асимметричных ключей, используемых для других целей, например для подписи по электронной почте?

Мне предлагается спросить об этом, частично потому, что в OS X есть приложения, доступные для управления ключами SSH (ssh-agent, SSHKeychain и т. Д.), А также приложения, предназначенные для управления ключами GPG (доступ к GPG Keychain и т. Д.), и, видимо, они не встречались. Однако я не верю, что это проблема OS X.

Это разделение интересов, потому что ключи имеют совершенно разные виды, или потому что они хранятся в разных местах, или это по какой-то другой причине или комбинации причин, например исторических причин?

• Ключи SSH - это просто пары асимметричных ключей RSA, DSA или ECDSA. Такая пара ключей, сгенерированная OpenSSH, уже может использоваться OpenSSL и большинством других программ.

  ( .pubФайл выводится ssh-keygenв формате, специфичном для OpenSSH, но это не имеет значения, поскольку «закрытый» файл уже содержит как закрытые, так и открытые ключи.)

  Другое программное обеспечение SSH может иметь свои собственные форматы хранения, такие как RFC 4716 или PPK PuTTY , но они хранят ту же информацию RSA / DSA / ECDSA.

• X.509 (используется SSL, S / MIME) немного сложнее: «закрытый» ключ остается тем же, но вместо чистого файла открытого ключа у вас есть «сертификат» - структура ASN.1, содержащая открытый ключ, имя субъекта и эмитента, сроки действия. В сертификатах X.509 v3 будут присутствовать такие расширения, как «использование ключа» и «альтернативное имя субъекта». Весь сертификат подписывается ключом эмитента (или самозаверяющим, если отдельного эмитента нет).

  Вы можете легко использовать файл «закрытого ключа» X.509 для SSH - OpenSSH даже использует тот же формат.

  Вы можете создать сертификат X.509 из простой пары ключей, а затем самостоятельно подписать его, или вы можете создать «запрос сертификата» и отправить его для подписи в ЦС (центр сертификации).

  Чтобы отобразить информацию в сертификате X.509, используйте:

  certtool -i < foo.pem
  certtool -i --inder < foo.crt
  
  openssl x509 -noout -text < foo.pem
  openssl x509 -noout -text -inform der < foo.crt
  

  ( certtoolявляется частью GnuTLS.)

• Ключи OpenPGP (используемые GPG) являются наиболее сложными. То, что вы называете «ключом PGP» или «парой ключей PGP», представляет собой сложную структуру, называемую «сертификат OpenPGP», содержащую:

  • один «первичный ключ» - пара асимметричных ключей, обычно используемая для подписи
  • один или несколько «идентификаторов пользователя» - текстовые метки, обычно в форме «Имя <адрес электронной почты @»>
    • по крайней мере один из них помечен как «основной идентификатор пользователя»
    • для каждого идентификатора пользователя «самоподпись» - подпись под собственным первичным ключом
    • для каждого идентификатора пользователя ноль или более «подписей» других пользователей
    • пакеты самоподписи также содержат ваши предпочтительные алгоритмы (SHA-1, AES и т. д.)
  • один или несколько «подразделов» - дополнительные пары ключей, первый обычно для шифрования
    • для каждого подключа подпись по первичному ключу
  • ноль или более «идентификаторов фотографий» - вложения в формате JPEG или PNG, содержащие ваше лицо
    • подписан так же, как идентификаторы пользователей
  • ноль или более сертификатов X.509

  Все пары ключей имеют даты истечения срока действия и биты использования: подписывать данные, сертифицировать (подписывать) ключи, шифровать, аутентифицировать сервисы. Первичный ключ по умолчанию имеет биты "sign" и "certify", а первый подраздел должен "шифровать". Если вы добавите подраздел «аутентификация», вы можете использовать его gpg-agentдля аутентификации SSH.

  Чтобы увидеть, что содержит ваш сертификат:

  gpg --export joe@example.com | gpg -vv
  
  gpg --export joe@example.com | certtool --pgp-certificate-info
  

  ( certtoolявляется частью GnuTLS.)

Сертификаты X.509 и связанные с ними закрытые ключи представлены в нескольких форматах:

• DER - это двоичное кодирование структуры сертификата ASN.1. Такие файлы обычно имеют .crtили .cerрасширения имени файла ( .derменее распространено, но невидимо).

• Файлы формата «PEM» содержат те же данные в кодировке DER, но дополнительно кодируются с использованием Base64 и между заголовками «BEGIN THIS» и «END THAT». Распространенным расширением имени файла является .pem, хотя оба .crtи .cerиногда используются и здесь (но никогда .der).

• Для закрытых ключей, принадлежащих сертификатам, обычно используется формат «PEM» - Base64, окруженный заголовками «BEGIN PRIVATE KEY» (ключ в структуре PKCS # 7) или «BEGIN RSA (или DSA) PRIVATE KEY» (голый ключ, OpenSSL формат). Иногда ключ находится в отдельном .keyфайле, иногда он связан с сертификатом.

• PKCS # 12 и несколько более старый PFX - это зашифрованные контейнеры, в которых хранятся как сертификат, так и закрытый ключ (часто также сертификат эмитента). Этот формат используется большинством программного обеспечения при экспорте или «резервном копировании» сертификатов с закрытыми ключами.

Менее запутанная ситуация в OpenPGP: все данные следуют одному и тому же двоичному формату и могут быть «защищены» (закодированы с помощью Radix64 и между PEM-подобными заголовками).

Хранятся в разных местах и ​​в разных форматах (форматы, используемые PGP, GnuPG sshи несколькими различными форматами X.509, среди прочих, совершенно разные). Можно перекодировать между ними до некоторой степени смешивания и сопоставлений правильных вариантов ssh-keygen, pgp, gpg/ gpg2, opensslи т.д .; но в целом это не стоит усилий. Кроме того, различные ключевые форматы поддерживают разные объемы информации, сsshнесут наименьшую дополнительную информацию, а форматы X.509 PEM и DER несут больше всего. Кроме того, цепочка для ключей OSX является просто зашифрованным хранилищем ключ / значение, поэтому каждому приложению обычно нужен свой механизм для преобразования между собственным ключом программы + форматом метаданных и чем-то, что может храниться в цепочке для ключей. (Аналогичные проблемы касаются кошелька KDE и цепочки для ключей GNOME.)