¿Qué sucede con las confirmaciones de git firmadas por OpenPGP después de la caducidad de la key?

Si firmo un commit de git con una key OpenPGP que tiene una date de vencimiento, ¿qué significa eso para las personas que buscan esa confirmación después de la date de vencimiento? ¿Deberían todas las keys utilizadas para confirmar la firma como esta ser permanentes?

¿Qué pasa si la parte verificadora tiene una nueva key de mi parte? ¿O solo mi viejo? ¿O ambos?

Soy nuevo en OpenPGP en general, especialmente en relación con la firma de commit de git.

La date de caducidad de OpenPGP solo indica que "esta key no debe usarse después de una date determinada", pero no hace que una key sea inútil: las matemáticas aún funcionan bien.

Si firmo una confirmación de Git con una key de PGP que tiene una date de vencimiento, ¿qué significa eso para las personas que miran esa confirmación después de la date de vencimiento?

Al verificar las firmas, las implementaciones de OpenPGP compararán la date de caducidad con la date en que se emitió la firma. Si la firma se emitió dentro del período de vencimiento, está bien. Si no, emitirá una advertencia (algo así como "la firma estuvo bien, pero se emitió después de la caducidad).

¿Qué pasa si la parte verificadora tiene una nueva key de mi parte? ¿O solo mi viejo? ¿O ambos?

Si tienen su key anterior, pueden verificar las firmas emitidas por su key anterior. Para su nueva key, pueden verificar los emitidos por su nueva key. Si tienen ambos, pueden verificar ambos.

¿Deberían todas las keys utilizadas para confirmar la firma como esta ser permanentes?

Tenga en count que la date de vencimiento realmente no agrega ninguna security, ya que se puede cambiar arbitrariamente siempre que tenga control sobre la key primaria secreta. Además, la date de la firma puede establecerse arbitrariamente, está escrita por la implementación de OpenPGP utilizada para crear la firma; un atacante podría simplemente establecer una hora del sistema simulada. Discutí la security de la date de vencimiento en detalle en el sitio hermano de Information Security en la pregunta "¿La expiración de la key OpenPGP se agrega a la security?" .

Usar una date de caducidad está bien si desea indicar que la key no se usará después de un time determinado, pero no la considere una característica de security. Muchas personas con el uso avanzado de la key OpenPGP tienen una key principal sin date de caducidad y regularmente subkeys de plica, que emiten con un período de validez limitado.

Crear nuevas keys principales significa que los demás deben validar su nueva key nuevamente. La key principal es el ancla de confianza común en OpenPGP, y crear una nueva significa perder todas las confianzas / certificaciones.

Puede y debe seguir utilizando las teclas que caducan.

La idea de este sistema es que las keys expiren y generes nuevas. Pero en el mundo de PGP, cargas tus llaves a los serveres de llaves. Básicamente funcionan como una guía telefónica (*), por lo que todos los que deseen recuperar su key pública para enviarle un post encryption podrán acceder a ella. Y esa también es la solución a tu problema. El server de llaves aún recordará las keys expiradas, por lo que su firma se mantendrá válida aunque expirada (la validation solo depende de una firma correctamente aplicada con una key válida una vez). Sus usuarios verán eso al validar su firma para la cual recuperaron la key que usó para esta firma en particular. Pero a medida que avance desarrollando y lanzando versiones firmadas, siempre firmará con keys válidas y la gente simplemente seguirá recuperando las nuevas.

(*) La comparación de un server de keys con un directory telefónico simplifica la situación, pero carece de una porción importante de información: si utiliza un server de keys para recuperar una key de una persona que le es desconocida, tenga en count que esta key puede verse comprometida. Por ejemplo, Alice quiere comunicarse con Bob utilizando encriptación (o simplemente verificar un commit de git de Bob) pero ella no lo conoce. Ella toma la key pública de Bobs desde un server remoto, pero no está al tanto del hecho de que Mallory la falsificó y la colocó allí. Entonces el process de verificación se ve comprometido y ella no se dará count. La salida: Bob puede publicar las huellas dactilares de su key pública (o la key, también) junto con el software que firmó en su website. Ahora, Alice puede tomar una llave, comparar su huella dactilar con la que proporcionó Bob para verificar que tenga la llave pública genuina de Bob. Con eso ella ahora puede verificar su compromiso firmado en git. Esto también funciona si la key está vencida.

Lea aquí , aquí y especialmente aquí para get más información.

git show-signature / verify considera que las keys revocadas no son válidas, incluso si se firmaron antes de que se revocara la key; consulte este ejemplo desde una firma y yubea revocada: https://www.flickr.com/photos/steve_l/37493124630/in/datetaken/

Dado este resultado, creo que puede ser less traumático no revocar una key en tales situaciones, sino cambiar la date de caducidad y hacer una actualización de los serveres de keys diciendo "La key ha expirado". De esta forma, los commits existentes todavía están validados.