Ayer estuve una hora tratando de que la herramienta keytool de java 1.4 importe un certificado. Sí, ya sé que esa versión es obsoleta, pero en este caso no hay otra opción. El tema es que luego de miles de pruebas no había forma de que reconociera el certificado como X.509 (aunque realmente fuera así).

Pues bien, importé el certificado en Java 1.5 y ningún drama, entonces armé un nuevo certificado de prueba con una clave de menor longitud y… bingo! la versión 1.4.2 no acepta longitudes de clave mayores a 2048, como era de esperarse debido a restricciones de exportación.

Pero yo quiero mi certificado con clave de 4096 bits! Googleando un poco encontré un hermoso documento donde unos buenos muchachos rusos explican cómo habilitar la utilización de claves de mayor longitud.

Para ello:

1. Suponiendo que el JRE se encuentra en /usr/lib/j2se/1.4/jre/
2. Descargar e instalar el jar de BouncyCastle CryptoProvider en $JRE/lib/ext
3. Descargar e instalar los archivos de la Unlimited Strength Jurisdiction Policy 1.4.2 en $JRE/lib/security
4. Modificar el archivo $JRE/lib/security/java.securityestableciendo los proveedores de seguridad como sigue:

   security.provider.1=sun.security.provider.Sun
   security.provider.2=org.bouncycastle.jce.provider.BouncyCastleProvider
   security.provider.3=com.sun.net.ssl.internal.ssl.Provider
   security.provider.4=com.sun.rsajca.Provider
   security.provider.5=com.sun.crypto.provider.SunJCE
   security.provider.6=sun.security.jgss.SunProvider

   El de BouncyCastle debe ser el segundo.

Y con eso debería alcanzar para poder utilizar certificados con clave de 4096 bits. O eso espero…
Bueno los dejo por ahora así como algo. Saludos!

Trevor Turton publicó recientemente en su blog un artículo titulado Use Cases on Steroids en el cual discurre sobre un posible método para encarar el desarrollo de software y no salir herido en el intento. Me tomo el atrevimiento de traducir informalmente una parte del texto de su autoría que resume el procedimiento:

• Durante la fase de elicitación de requerimientos, los desarrolladores trabajan junto al cliente (como organización) para identificar los elementos debajo enumerados. Los desarrolladores representarán estos elementos en una herramienta de modelado acordada y consultarán al cliente para verificar que esto se ha realizado con precisión (esta parte del modelo es simple de controlar por no-especialistas) :
  • Los actores que juegan un rol en el sistema.
  • Una lista jerárquica de las acciones principales que estos actores ejecutarán.
  • Modelos de cada panel requerido para soportar las acciones identificadas; en HTML, si fuera un sistema basado en el navegador.
  • Casos de uso que describen en palabras las diversas acciones identificadas; en HTML si es un sistema basado en web, con enlaces a los paneles modelo.
  • Un modelo de datos que contiene todos los elementos de datos identificados en las acciones y paneles.
• Durante la fase de diseño:
  • Los usuarios pueden manejarse a través de los casos de uso, viendo los paneles modelo en cada paso del proceso, pudiendo validarlos o corregirlos.
  • Los desarrolladores refinan el modelo de datos según las formas normales, produciendo un diseño de base de datos.
  • Los diseñadores incorporan al modelo las clases, atributos y métodos que serán necesarios para implementar el sistema.
• Durante la fase de programación:
  • Los desarrolladores engrosan el modelo con el código requerido para implementar el sistema.
  • Los desarrolladores crean la base de datos y las clases requeridas para administrar los datos en ellas.
  • Puede añadirse lógica estándar sencilla a los paneles para propagar los datos ingresadas por los usuarios a los paneles subsecuentes.
  • Otros miembros del equipo de desarrollo refinan el estilo visual de los paneles modelos a fin de que los usuarios los sientan adecuados.
  • Se toman capturas de los paneles clave, que serán firmadas por los propietarios del sistema quienes acordarán que es el estilo visual que requieren.
  • El equipo de desarrollo debe asegurarse que el estilo acordado sea aplicado uniformemente a todos los paneles, preferentemente mediante hojas de estilo.
  • Los propietarios del sistema prueban y firman (o critican) los paneles modificados para asegurar que poseen la funcionalidad y apariencia requerida.
• Durante la fase de prueba:
  • A medida que se implementan las distintas partes del sistema, se incorpora a los paneles modelo correspondientes la lógica embebida, según sea necesario.
  • Los casos de uso se convierten ahora en scripts de prueba. Los usuarios los utilizarán como guía para evaluar metódicamente el sistema, sólo que ahora la navegación entre paneles se realizará a través de lógica del software en el sistema de prueba, en vez de hacer clics en los enlaces en el caso de uso (aunque los enlaces de los casos de uso pueden utilizarse para navegar los paneles de software apropiados donde ésto tenga sentido, p.ej. donde no se requiere entrada desde un panel anterior).
  • La navegación entre secciones del sistema que no han sido desarrolladas aún puede realizarse a través de los casos de uso, de forma que los usuarios pueden evaluar los componentes en un contexto plausible, en vez ser en forma aislada.
  • Podría implementarse a través de hojas de estilo un esquema de colores convenido para distinguir los paneles en funcionamiento de los paneles en desarrollo.

En realidad no es nada nuevo, muchos de nosotros hemos optado por una metodología similar al desarrollar un sistema web. Lo bueno es que el muchacho se tomó el tiempo de documentarlo y darnos unos muy buenos consejos. So… Thank you very much, Trevor!