Keeping the work in progress after the new 0.6.0 version, I’m pleased to announce the 0.5.4 version of gnoMint: a graphical X.509 Certification Authority management tool.
This version adds adds some features:
- Now it is possible to generate CRLs for all the CAs in the hierarchy, not only the first root CA.
- Now, the dependences between certificate uses and certificate purposes are enforced.
- Now, the CA used for inheriting fields while creating a CSR is remembered, so it is the default selected CA while signing it.
- Just created files now in 0600 mode, so only owner car read them.
- gnoMint now can compile with much stricter compiler parameters (not enabled by default).
- A lot of autotools cleaning, thanks to Stanek Lubos <lubek@users.sourceforge.net>
- Now, certificates (CA and non-CA) can be imported from external files.
- Added Swedish translation, thanks to Launchpad.net collaborators.
There are also several fixes:
- Expired certificates appear only in the first CRL released after the expiration date, according to RFC 5280 (page 13).
- Subject and issuer key id are properly set, according to RFC 5280
- Fixing segmentation fault when the CSR or the CA certificates have NULL fields.
- Fixing problem: only the first certificate in database could sign CSRs in password-protected databases.
- Fixing problem: now expiration time is properly set (there was a problem related with the difference between UTC and localtime).
- Some other segmentation faults are fixed too.
You can get the tarball from sourceforge mirrors: http://prdownloads.sourceforge.net/gnomint/gnomint-0.5.4.tar.gz?download
Octubre 1st, 2008
Como muchos sabéis, como proyecto fin de carrera estoy desarrollando gnoMint, un sistema de gestión de jerarquía de autoridades de certificación X.509.
Desenmarañando el RFC-5280 (que es el que actualmente rige para todo lo relacionado con la parte más técnica de los PKI (Public Key Infraestructure) me he encontrado con la parte de los Usos posibles de los certificados (concretamente, de las claves).
Para aclararme definitivamente sobre el tema, he traducido la sección 2.1.3 del RFC “Key Usage”. Aquí la dejo, para quien pueda servir.
2.1.3 Usos de la clave
La extensión de usos de clave (key usage) define el propósito (esto es, cifrado, firma, firma de certificados…) de la clave contenida en el certificado. La restricción de uso podría emplearse cuando una clave que podría usarse para más de una operación vaya a ser restringida (no entiendo demasiado bien esta frase en inglés tampoco). Por ejemplo, cuando una clave RSA debiera ser empleada sólo para verificar firmas en objetos que no sean claves públicas de certificados y CRLs, los bits de firmaDigital y/o noRepudio debieran estar activos. Así mismo, cuando una clave RSA debiera emplearse exclusivamente para la gestión de claves, el bit cifradoDeClaves debiera estar activo.
Las ACs conformes a esta norma DEBEN incluir esta extensión en los certificados que contengan claves publicas que vayan sean usadas para validar firmas digitales sobre otros certificados de clave pública o CRLs. Cuando esté presente, las ACs conformes a esta norma DEBERÍAN marcar esta extensión como crítica.
id-ce-usoDeClave OBJECT IDENTIFIER ::= { id-ce 15 }
UsoDeClave ::= BIT STRING {
firmaDigital (0),
noRepudio (1)), -- ediciones recientes de X.509 han renombrado
-- este bit como confirmaciónDeContenido
cifradoDeClave (2),
cifradoDeDatos (3),
acuerdoDeClaves (4),
firmaDeClaveDeCert (5),
firmaDeCRL (6),
soloCifrado (7),
soloDescifrado (8) }
Los bits de UsoDeClave se usan como sigue:
El bit de firmaDigital se activa cuando la clave pública del titular se emplea para verificar firmas digitales, distintas de las de los certificados (bit 5) o CRLs (bit 6), como aquellas empleadas en un servicio de autenticación de entidades, un servicio de autenticación de orígenes de datos y/o un servicio de integridad.
El bit de noRepudio se activa cuando la clave pública del titular se usa para verificar firmas digitales, distintas de las de los certificados (bit 5) y CRLs (bit 6), empleadas para proporcionar un servicio de no repudio que proteja contra el hecho de que la entidad firmante intente rehusar, falsamente, haber realizado alguna acción. En el caso de conflicto ulterior, una tercera parte confiable puede determinar la autenticidad de los datos firmados. (Debe destacarse que ediciones recientes de X.509 han renombrado este bit como confirmaciónDeContenido)
El bit de cifradoDeClave debe activarse cuando la clave pública del titular vaya a usarse para cifrar claves privadas o secretas, por ejemplo, para transporte de claves. Por ejemplo, este bit debe establecerse cuando una clave pública RSA vaya a ser empleada para cifrar una clave simétrica para el descifrado de datos, o una clave privada asimétrica.
El bit de cifradoDeDatos debe activarse cuando la clave pública del titular vaya a usarse para cifrar, directamente, datos de usuario sin emplear un cifrado simétrico intermedio. Debe destacarse que el empleo de este bit es extraordinariamente raro; casi todas las aplicaciones emplean el tranporte de claves o el acuerdo de claves para establecer una clave simétrica.
El bit de acuerdoDeClaves se activa cuando la clave pública del titular vaya a ser empleada para la negociación de claves. Por ejemplo, cuando una clave Diffie-Hellman vaya a emplearse para la gestión de claves, se deberá activar este bit.
El bit de firmaDeClaveDeCert se activa cuando la clave pública del titular se emplee para verificar firmas en certificados de clave pública. Si el bit firmaDeClaveDeCert está activo, el bit cA de la extensión de restricciones básicas (sección 4.2.1.9) DEBE también estar activo.
El bit firmaDeCRL se activa cuando la clave pública del titular se emplea para verificar firmas de listas de revocación de certificados (como CRLs, delta CRLs, o ARLs).
El significado del bit soloCifrado no está definido si el bit acuerdoDeClaves no está activo. Cuando los bits soloCifrado y acuerdoDeClaves están activos, la clave pública del titular sólo puede emplearse para cifrar datos al realizar una negociación de claves.
El significado del bit soloDescifrado no está definido si el bit acuerdoDeClaves no está activo. Cuando los bits soloDescifrado y acuerdoDeClaves están activos, la clave pública del titular sólo puede emplearse para descifrar datos al realizar una negociación de claves.
Si la extensión de usoDeClave está presente, la clave púlbica del titular NO DEBE emplearse para verificar firmas de certificados o CRLs a menos que los bits correspondientes de firmaDeClaveDeCert o firmaDeCRL estén activos. Si la clave pública del titular sólo debe emplearse para verificar firmas en certificados y/o CRLs, los bits de firmaDigital y noRepudio NO DEBERÍAN estar activos. Sin embargo, los bits firmaDigital y/o noRepudio PODRÍAN estar activos junto con los bits firmaDeClaveDeCert y/o firmaDeCRL si la clave pública del titular se fuera a emplear para verificar firmas en certificados y/o CRLs además de en otros objetos.
Combinar el bit de noRepudio en la extensión de usoDeClave con otros bits puede tener implicaciones de seguridad dependiendo del contexto en el que se vaya a emplear el certificado. Otras distinciones entre los bits de firmaDigital y noRepudio podrán ser indicadas en políticas específicas de certificados.
Este perfil no restringe las combinaciones de bits que pueden establecerse en una instacia de la extensión usoDeClave. Sin embargo, en los RFC3279, RFC4055 y RFC4491 pueden encontrarse los valores apropiados para la extensión usoDeClave en distintos algoritmos. Cuando la extensión usoDeClave aparezca en un certificado, al menos uno de sus bits DEBE estar establecido a 1.
Septiembre 10th, 2008
I’m pleased to announce gnoMint 0.1.0: the first public release of thenew Certification Authority managing tool for GTK/Gnome.
gnoMint is a tool for an easy creation and management of Certification Authorities. It allows a fancy visualization of all the pieces that conform a CA: x509 certificates, CSRs, CRLs… Currently, this first v0.1.0 allows the creation of CAs, CSRs and Certificates. It can export both public and private parts of them into PEM formatted files.
This is the first public release. It has known bugs, and it is not feature-completed yet. However, gnoMint is now perfectly usable for managing a CA that emits certificates able to:
- Authenticate people or machines in VPNs (IPSec or other protocols);
- Secure HTTP communications with SSL/TLS secured web servers;
- Authenticate and cipher HTTP communications through web-client certificates;
- Sign and/or crypt e-mails
For compiling it, its dependencies are:
- GTK+
- Gnome
- SQLite 2 or better
- libGnuTLS 1.0.14
You can get the tarball from sourceforge mirrors: http://prdownloads.sourceforge.net/gnomint/gnomint-0.1.0.tar.gz?download
Please send bugs, comments and/or questions to our mailing list: gnomint-users@lists.sourceforge.net
Septiembre 15th, 2006
