Nuestros productos de autenticación y firma digital
Lector de tarjetas Zhen
Sitios internacionales
Name: chemalogo
Email:
Posts by chemalogo:
PortaSigma como plataforma de factura electrónica
enero 24th, 2012Recientemente, y siguiendo las demandas de nuestros usuarios, hemos incorporado en PortaSigma una funcionalidad que expande sus usos todavía más, convirtiéndola en una sencilla y asequible plataforma de factura electrónica.
La funcionalidad
Ahora, además de todas las funciones de PortaSigma, podemos enviar el documento a una lista de direcciones de correo electrónico, una vez se cierra el ciclo de firmas.
¿Y cómo lo uso para factura electrónica? ¡Al fin y al cabo es de lo que va el tema!
Preparamos la plataforma
Primero de todo, nos creamos una cuenta en PortaSigma, que es gratis y podemos firmar hasta cinco (5) veces.
Debemos tener nuestro certificado electrónico y su clave privada en un archivo. En esta web de la Universidad de Sevilla te explican cómo, cosa que agradecemos públicamente desde aquí.
Subimos nuestro certificado a la plataforma. Para ello, una vez hemos entrado en PortaSigma, vamos a (1)”Mi cuenta” y en el menú de la derecha escogemos (2) “Certificados y claves”. Nos aparecerá una pantalla más o menos como ésta:
En ella, (3) seleccionamos el fichero que contiene nuestro certificado y clave privada.
Luego (4) le ponemos un nombre que nos sea fácil de recordar.
A continuación (5) indicamos que es para usar como firma automática e introducimos (6) la contraseña que protege el archivo, la que pusimos al exportar el certificado y la clave privada.
Finalmente (7), indicamos que la firma automática debe realizarse al inicio del proceso y le damos a guardar.
Con esto ya tenemos preparada nuestra cuenta de PortaSigma para emitir facturas electrónicas.
Emitimos nuestra primera factura
Entramos de nuevo en la plataforma, vamos a (1) Mis documentos y en el botón de arriba a la derecha hacemos clic en (2) Añadir documento, como se indica en la imagen de más abajo.
A continuación seleccionamos el fichero que contiene nuestra factura.
Nos aparece una ventana como la siguiente, que analizaremos brevemente. En ella vemos una (1) miniatura de la factura; si hacemos clic sobre ella, la miniatura se ampliará.
También vemos (2) que la factura ya está firmada. ¡Claro!, ¡para eso configuramos la firma automática al inicio del proceso!
También puedes modificar el título, la referencia y los comentarios a tu discreción. Es una buena idea, usar el Título para poner el producto y el cliente al que hace referencia la factura, usar la Referencia para poner el número de la factura y el campo Comentarios para poner el literal “Factura”. De esta forma, si usamos PortaSigma para más cosas que facturación electrónica, nos será más sencillo identificar los diferentes documentos.
Y ya sólo nos queda enviar la factura al o a los destinatarios. Para ello pulsamos sobre (3) Solicitar firmas y nos aparecerá la siguiente pantalla …
… pero como ya no tenemos nada que firmar y sólo queremos enviar la factura, dejamos la (1) parrilla de firmantes vacía y sólo rellenamos la (2) parrilla de destinatarios. ¡Ponte tú también, además de tu cliente, como uno de los destinatarios, al menos las primeras veces para ir viendo lo que les llega a tus clientes! Pulsamos (3) Guardar y enviar et voilà, factura firma, enviada y almacenada en PortaSigma para futuras consultas!
Si has tratado de hacer esto y te surge alguna duda, no dudes en ponerte en contacto con nosotros en info@isigma.es o en el 93.519.13.75
¿Y si emito muchas facturas?
Este procedimiento, si emito muchas factura podría ser engorroso. Pero no te preocupes, porque la funcionalidad de PortaSigma es accesible vía webservices y se puede integrar con tu software de gestión de facturas.
Además, contamos con una sencilla pero muy práctica aplicación que llamamos Uploader que permite realizar la integración de forma muy rápida.
¡Llámanos si deseas más información!
Y, ya que lo contrato para facturación electrónica, ¿la misma cuenta me sirve para algo más?
La nueva funcionalidad no es exclusiva para facturación electrónica, sino que tiene un carácter más general marca de la casa. No obstante es ideal para poder realizar facturación electrónica.
Por otro lado, con PortaSigma se pueden realizar muchos más trámites sin por ello incrementar el costo.
Algunos ejemplos son la firma de contratos laborales y mercantiles, firma de recetas veterinarias, de ensayos clínicos, de procesos corporativos, de actas de reunión, contratos de arrendamiento, para la realización del visado electrónico.
¿Qué tienes que firmar en papel? ¡Pásalo a PortaSigma!
Como siempre (a ver si esta vez funciona 
, si te ha gustado esta entrada, o crees que puede resultar útil a otras personas, no dudes en compartirla a través de los botones que encontrarás debajo.
Breve repaso a la Ley de Firma Electrónica Avanzada, México
enero 18th, 2012Primero de todo, y para que a lo largo de la lectura de la citada Ley (en adelante FIEL) me gustaría remarcar la diferencia de nomenclatura para mi más relevante respecto a la legislación española, y es que en la FIEL, la
Firma Electrónica Avanzada: [es] el conjunto de datos y caracteres que permite la identificación del firmante, que ha sido creada por medios electrónicos bajo su exclusivo control, de manera que está vinculada únicamente al mismo y a los datos a los que se refiere, lo que permite que sea detectable cualquier modificación ulterior de éstos, la cual produce los mismos efectos jurídicos que la firma autógrafa;
Lo que en la ley española sería la firma electrónica reconocida. En su día ya hablamos sobre el lío existente entre firma electrónica y firma digital.
El artículo 8 viene a describir los servicios de seguridad como todos ya los conocemos (autenticidad, confidencialidad, integridad, no repudio), y un contradictorio principio de neutralidad tecnológica. Contradictorio porque en el artículo 2, de definiciones ya se da a entender que toda la ley se sustentará sobre criptografía de clave pública.
El anterior punto de equivalencia funcional aparece citado hasta tres veces en la ley (art.2.XII, art.7, art.8.I, lo que denota la relevancia que se le quiere otorgar.
En al artículo 11, se mete parte de la Ley 11/2007 (LAECSP) española. No basta con dejar clara la equivalencia funcional, sino que además se dice explícitamente a las AA.PP. que deben admitirla si así lo desea el ciudadano.
En el artículo 16 se regula la creación de copias electrónicas de originales en papel, otro de los puntos que trata la LAECSP.
El artículo 18 detalla el procedimiento de solicitud! Fuera incertidumbres!
Vigencia máxima de cuatro años, como en España con los certificados reconocidos.
Se da pie, tanto en las deficiones (enlazando las deficiones XIX. Prestador de Servicios de Certificación y IV. Autoridad Certificadora del artículo 2) como en el capítulo III (art. 24) dedicado a las Autoridades de Certificación, a que se establezcan ACs o PSC privados, aunque falta (o yo no doy con) “las disposiciones generales que se emitan en los términos de esta Ley“, lo que puede representar una gran oportunidad para los ya experimentados prestadores de servicios de certificación españoles.
Las obligaciones de las ACs (Art. 25) en algún caso me parecen fuera de su alcance, por lo que no entiendo cómo se les piden tales cosas. Por ejemplo:
V. Garantizar la autenticidad, integridad, conservación, confidencialidad y confiabilidad de la firma electrónica avanzada, así como de los servicios relacionados con la misma;
Las ACs no distribuyen ni son responsables de las aplicaciones de generación de firma, o al menos, no se cita en la ley. ¿Cómo pueden ser responsables de la autenticidad, integridad, conservación, confidencialidad y confiabilidad de la mismas? En todo caso, del certificado digital, pero no de la firma electrónica avanzada.
Finalmente, si yo fuera un PSC español y leyera el artículo 30…
Artículo 30. Los certificados digitales expedidos fuera de la República Mexicana tendrán la misma validez y producirán los mismos efectos jurídicos reconocidos en la presente Ley, siempre y cuando tales certificados sean reconocidos por las autoridades certificadoras a que se refiere el artículo 23 de la propia Ley y se garanticen, en la misma forma que lo hacen con sus propios certificados, el cumplimiento de los requisitos, el procedimiento, así como la validez y vigencia del certificado.
… ya estaría haciendo las llamadas oportunas para que mis certificados se admitieran en México.
Consideraciones legales más sofisticadas al margen, que juristas ya se encargarán de desvelar, me parece una ley con un enfoque práctico muy interesante!
Ya sabes, si te ha gustado esta entrada, o crees que puede resultar útil a otras personas, no dudes en compartirla a través de los botones que encontrarás debajo.
No sólo de pan vive el hombre, ni de DNI electrónico los avales
octubre 12th, 2011
El DNI electrónico es un excelente instrumento para muchos trámites electrónicos, evitándonos desplazamientos, colas y aportando una seguridad extra a lo firmado, incluyendo la firma de avales de candidaturas a unas elecciones.
No obstante y a pesar de haber más de 25 millones de DNI electrónicos en circulación, su uso es marginal. Además, no todos estos DNI electrónicos tienen activos sus certificados digitales y muchos de sus poseedores ni recuerdan ni saben dónde han guardado el “sencillo” de activación de las claves asociadas a los certificados.
Por otro lado, además del DNI electrónico, y mucho antes que éste, existen en circulación otros certificados electrónicos que permiten hacer prácticamente las mismas cosas que el DNI electrónico.
Certificados como los de Firmaprofesional, Camerfirma, la Agència Catalana de Certificació (CATCert), la Autoritat de Certificació de la Comunitat Valenciana (ACCV), IZENPE, la propia FNMT (los de “Hacienda de toda la vida”) y otros que ahora olvido pero no por ello menos importantes, en determinadas circunstacias, permiten realizar firmas electrónicas con la misma validez que el DNI electrónico y que la firma autógrafa.
Además, con una particularidad, y es que los usuarios de estos certificados, en general, los utilizan de forma intensiva. Al tratarse de certificados que uno obtiene voluntariamente, sólo los obtiene si va a hacer uso de ellos, a diferencia del DNIe, que, lo quieras o no, lo tienes, como ciudadano español.
Entonces, si tenemos un colectivo de usuarios que, aunque menor en número que los poseesores de DNIe, es manifiestamente mucho más activo, y si estos usuarios generan firmas electrónicas de la misma calidad que el DNIe, ¿por qué no permitir el acceso de estos usuarios a las mismas aplicaciones habilitadas para el DNI electrónico?, ¿por qué no permitirles la firma de avales de candidaturas a unas elecciones como las del 20N?
En isigma creemos en la igualdad de oportunidades, en la democracia real y directa, en la eliminación de barreras artificiales con fines proteccionistas y por ello, en nuestros productos, como por ejemplo nuestra plataforma de recogida de avales, se pueden utilizar los certificados de todos estos prestadores de servicios de certificación y muchos más. En la variedad está el gusto.
Tienes una lista completa aquí.
¿Vas a seguir recogiendo avales sólo de forma manuscrita o sólo con el DNI electrónico? Entonces estás renunciando a los usuarios más activos de firma electrónica.
El partido Pirates de Catalunya y la Coalició Compromís no han renunciado a estos votantes y recogen avales electrónicos con todos estos certificados aquí y aquí respectivamente.
Si te ha gustado este artículo, no dudes en compartirlo “clicando” sobre cualquiera de los botones de debajo.
Usos del DNI electrónico – Firma electrónica de avales para presentar candidaturas
octubre 10th, 2011Aportar valor
¿Queremos que se use el DNI electrónico? Démosle usos que realmente aporten valor a la sociedad. Por ejemplo, la firma de avales para poder presentar candidaturas a las elecciones del Congreso y el Senado, más concretamente las próximas del 20N.
Me parece uno de los ejercicios más sanos de democracia pseudo-directa, poder avalar a partidos, sobre todo a partidos inicialmente minoritarios, pero que podrían dejar de serlo.
Para mi en particular, este uso del DNI electrónico (y de otros certificados electrónicos) aporta valor a la sociedad. Poder expresar la opinión y que tenga unas consecuencias legales, poder dar acceso a los mecanismos electorales a partidos con pocos menos para propaganda, para recoger firmas, para montar stands, mítines y eventos varios. Eso da valor a una sociedad, poder elegir representantes que me representen en un 80 o 90% mis creencias, y no tener que elegir entre los de siempre, que no pueden modificar la constitución para satisfacer las demandas del pueblo al que “representan” pero sí las de los mercados.
La solución
Como expertos en firma electrónica que somos, recibimos la solicitud del partido Pirates de Catalunya para poder recoger avales en formato electrónico, tal y como “permitió” a última hora la Junta Electotal Central (JEC.)
Nos pusimos manos a la obra y utilizando nuestra tecnología de firma electrónica presente en productos como PortaSigma o ClickSign, desarrollamos en tiempo récord (y madrugadas) una plataforma sencilla pero eficaz para la recogida de avales EN EL FORMATO DEFINIDO POR LA JEC. Esto último es muy importante, porque si no te aseguras de que la plataforma de recogida cumple con el formato, tu aval puede no servir para nada.
Nuestros productos llevan años utilizando nuestra tecnología. Su fiabilidad viene avalada (qué bien traído) por miles de usuarios y miles de transacciones diarias de firma electrónica.
Las dificultades
El tiempo (la falta de ~) no era sino la primera dificultad. Un malpensado podría sospechar que a los grandes partidos no les interesa este mecanismo de recogida de avales, rápido, directo, barato (luego nos quejamos de que el DNI electrónico no se usa.)
La otra gran dificultad ha sido el formato de los avales (las ESPECIFICACIONES TÉCNICAS PARA LA RECOGIDA DE AVALES DE CANDIDATURAS CON FIRMA ELECTRÓNICA). Las consignas eran contradictorias, indicando un formato (estándar y bastante extendido) y poniendo un ejemplo de otro muy diferente (no tan estándar y mucho menos difundido.) No vale un PDF firmado, no valen firmas detached, no valen CMS o PKCS#7 (siglas raras de formatos de firma electrónica) tenía que ser un XML especialito.
Al final lo hemos logrado. Esperamos llegar a tiempo para que los ciudadanos puedan elegir a los partidos que en mayor grado les satisfagan y no y no tengan que seguir escogiendo sólo entre garbanzos o lentejas.
La gente puede tener su modelo T en cualquier color. Siempre que ese color sea negro. Henry Ford
Gracias a la recogida de avales con firma electrónica, ahora está en nuestra mano (la de los ciudadanos) que tengamos más colores entre los que escoger.
Las candidaturas actuales
En nuestra plataforma actualmente se pueden recoger firmas del patido Pirates de Catalunya. ¿Y de otros? ¡Por supuesto! Cualquier partido que lo desee puede utilizar la plataforma para la recogida de avales. Si algo nos gusta son los colores y darle usos al DNI electrónico. Ponte en contacto con info@isigma.es y adelante. Todavía estamos a tiempo.
Si te ha gustado este artículo, no dudes en compartirlo “clicando” sobre cualquiera de los botones de debajo.
Firma electrónica, firma digital, certificado electrónico y … tal.
julio 22nd, 2011¿A que nunca habías visto un post que explicara las diferencias entre firma electrónica y firma digital?
Al igual que con el paso del tiempo se nos olvida cómo calcular la raíz cuadrada (algo tan útil en nuestra vida cotidiana como conocer los quinientos primeros decimales del número pi -π- ), también podemos empezar a olvidar las sutiles diferencias entre la firma electrónica y la digital.
Las definiciones, lamentablemente no son universales y, en su vertiente jurídica, depende de la legislación de cada país.
A continuación glosaremos algunas definiciones y que cada cuál utilice las que se avengan mejor a su contexto concreto.
Firma digital
Según el RFC4949, “Internet Security Glossary”, Version 2, la firma digital es:
A value computed with a cryptographic algorithm and associated with a data object in such a way that any recipient of the data can use the signature to verify the data's origin and integrity.
(Traducción con Google translate y remiendos propios: Un valor calculado con un algoritmo criptográfico y asociado con un objeto de datos de tal forma que cualquier destinatario de los datos puede usar la firma para verificar el origen y la integridad de los datos)
Según la ISO “Information Processing Systems — Open Systems Interconnection Reference Model, Part 2: Security Architecture“, ISO/IEC 7499-2
Data appended to, or a cryptographic transformation of, a data unit that allows a recipient of the data unit to prove the source and integrity of the data unit and protect against forgery, e.g. by the recipient
(Traducción con Google translate y remiendos propios: datos adjuntos o una transformación criptográfica de un conjunto de datos que permite a un receptor de este conjunto probar el origen y la integridad del conjunto y protegerlo contra falsificación (modificación), por ejemplo, por el receptor)
Según la Ley 8454, de 30-8-2005, de Certificados, Firmas Digitales y documentos electrónicos, de Costa Rica:
cualquier conjunto de datos adjunto o lógicamente asociado a un documento electrónico, que permita verificar su integridad, así como identificar en forma unívoca y vincular jurídicamente al autor con el documento electrónico.
En la legislación de otros países como Nicaragua o Perú también se hace referencia a la firma digital.
Firma electrónica
Según la Ley 59/2003, de 19 de diciembre, de Firma Electrónica (LFEE), en su artículo 3.1, define la firma electrónica como:
el conjunto de datos en forma electrónica, consignados junto a otros o asociados con ellos, que pueden ser utilizados como medio de identificación del firmante
Según la Directiva 1999/93/CE del Parlamento Europeo y del Consejo, de 13 de diciembre de 1999, por la que se establece un marco comunitario para la firma electrónica, en su artículo 2º la define como:
los datos en forma electrónica anejos a otros datos electrónicos o asociados de manera lógica con ellos, utilizados como medio de autenticación
Según la Ley Nº 729, de 30/08/10, de Firma Electrónica, de Nicaragua, la firma electrónica es:
datos electrónicos integrados en un mensaje de datos o lógicamente asociados a otros datos electrónicos, que puedan ser utilizados para identificar al titular en relación con el mensaje de datos e indicar que el titular aprueba la información contenida en el mensaje de datos
La ESIGN Act, en su sección 106 (Definitions), reza:
The term 'electronic signature' means an electronic sound, symbol, or process, attached to or logically associated with a contract or other record and executed or adopted by a person with the intent to sign the record
(Traducción con Google translate y remiendos propios: el término «Firma electrónica» significa es un sonido, símbolo o proceso, vinculados o asociados de manera lógica con un contrato u otro documento y ejecutado o adoptado por una persona con la intención de firmar el documento)
Definición bastante curiosa, todo sea dicho.
En el contexto español
Si comparamos la definición de firma digital del RFC4949 (1ª) y la de firma electrónica de la ley española (LFEE) encontramos estas diferencias:
- La 1ª habla de criptografía, mientras que la LFEE no, como es normal en una ley que trata de ser independiente de la tecnología.
- La primera habla de “integridad” mientras que la 2ª no hace referencia alguna. La LFEE no entra en el terreno de la “integridad” hasta su definición de “firma electrónica avanzada” (de la que hablaremos en futuros posts)
- Finalmente, la 1ª hace referencia a verificar el origen de los datos, mientras que la LFEE se refiere a la identificación del firmante, mostrando claramente el enfoque técnico de la 1ª y el jurídica y vinculado a actos de personas de la LFFE.
Total, que si alguien, en un contexto español os comenta que “la ley dice que la firma digital bla, bla, bla”, es que toca de oído.
¿Qué países tienen regulada de la firma electrónica o digital?
Tiempo atrás encontré esta página que puede ser de utilidad para identificar las distintas leyes sobre firma electrónica/digital de diversos países, con indicación de si la ley recoge necesidad de sello de tiempo o tarjeta/token criptográfico.
Espero que os sea de utilidad.
Por cierto si te ha gustado esta entrada, no dudes en compartirla usando los botones de debajo
Importar certificados electrónicos en Microsoft Internet Explorer
julio 15th, 2011NOTA: Si eres usuario de la Firma Electrónica Avanzada (FEA o FIEL) del Servicio de Administración Tributaria (SAT) mexicano, quizá te interesa mirar primero cómo migrar los certificados y claves privadas a un formato estándar por dos razones:
- al pasarlo a formato estándar podrás usarlos en muchas más aplicaciones (por ejemplo, importarlos en Microsoft Internet Explorer)
- al pasar de dos ficheros a uno, te será más fácil manejarlos y hacer y controlar copias de seguridad (por lo que se ve e twitter esto es una las principales fuentes de problemas)
Requisitos
Tener un fichero con extensión .pfx o .p12, conocer la contraseña que lo protege (ya que estos ficheros siempre están protegidos por una contraseña o PIN) y tener un sistema operativo Microsoft (un Windows, vamos).
Este tutorial se ha realizaco con Microsoft Windows XP SP3.
Manos a la obra
Primero de todo, localizamos el fichero.pfx o .p12
. Tenemos que hacer doble click sobre el fichero.
En la siguiente ventana, que nos informa de que comenzamos a usar el asistente para importar certificados, debemos pulsar “Siguiente”:
Nos aparece una nueva venta en la que el nomben y ubicación del fichero ya están informados. Debemos pulsar “Siguiente”:
ATENCIÓN: Este paso es muy importante pues empezamos a tomar decisiones sobre la seguridad con la que protegeremos el certificado y clave privada importados.
En el primer campo, debemos poner la contraseña que protege el fichero .pfx (ver Requisitos)
Un par de decisiones y sus consecuencias:
¿Habilito protección segura de claves privadas o no?
Rotundamente sí. Si no lo habilitamos cualquier persona que se siente frente a nuestro ordenador y, lo que es peor, cualquier aplicación de nuestro ordenador (por ejemplo, un virus) podrían usar nuestra clave privada SIN QUE NOS ESTEREMOS O SE NOS MUESTRE MENSAJE ALGUNO.
¿Marco la clave privada como exportable?
Es recomendable NO marcarla como exportable, pero tener una copia de seguridad del fichero .pfx que estamos importando. Si tenemos esta copia de seguridad adecuadamente custodiada, tú y sólo tú podrás repetir este proceso. En cambio, si marcas la clave privada como exportable, una persona que se siente frente a tu ordenador, podría copiársela y luego utilizar tu clave privada en su casa, firmando cosas en tu nombre.
Y seguimos para bingo! Ahora nos da a elegir en qué almacén de certificados importarlo.
Dejamos seleccionado que lo elija automáticamente y pulsamos “Siguiente”.
Finalmente nos aparece una pantalla para confirmar las selecciones que hemos realizado hasta el momento. Debemos pulsar “Finalizar”.
¿Finalmente? … ¡pues claro que no!
Si hemos elegido (tal y como recomiendo encarecidamente) “Habilitar protección segura de claves privadas …”, ahora configuraremos esa seguridad.
La penúltima decisión (o la última)
Por defecto, Microsoft nos asigna un nivel de seguridad “Medio” (ver ventana en segundo plano).
En este momento podemos pulsar “Aceptar” y ya habremos acabado con la importación y tendremos protegida nuestra clave privada con un nivel de seguridad “Medio”.
¿Qué implica el nivel de seguridad “Medio”?
El nivel de seguridad “Medio” implica que cuando una aplicación quiere hacer uso de nuestra clave privada, Windows nos muestra una ventana indicándonos este hecho y pidiendo que aceptemos o cancelemos.
Esto nos protege frente a aplicaciones maliciosas que quieran usar nuestra clave privada sin nuestro consentimiento, pero no nos protege si alguien se sienta frente a nuestro ordenados y quiere usar nuestra clave privada para firmar algo en nuestro nombre.
Yo soy una persona que valora la seguridad y quiero configurar el nivel “Alto”
Más arriba, en “La penúltima decisión (o la última)“, si en vez de pulsar “Aceptar”, pulsamos “Nivel de seguridad” aparece la ventana que en la imagen de más abajo se ve en primer plano, donde podemos escoger entre el nivel “Alto” y el “Medio”.
Si escogemos “Alto” (seleccionar “Alto” y pulsar “Siguiente”), se abrirá una nueva ventana. En esta ventana podemos darle un nombre al certificado para identificarlo fácilmente (nombre que se mostrará cuando alguna aplicación quiera utilizarlo) y debemos escoger una contraseña (la que queramos.)
Cada vez que queramos firmar, o cada vez que una aplicación quiera acceder a nuestra clave privada, se nos pedirá esta contraseña, mediante una ventana como la siguiente:
¡Y ya tenemos perfectamente importado nuestro certificado y clave privada en el almacén de certificados de nuestro Windows!
Perfiles de certificado digital de la Ley 11/2007
junio 3rd, 2011
Los dolores de cabeza que ha traido a los Prestadores de Servicios de Certificación (PSC) adecuarse a los perfiles de los tipos de certificados definidos en la Ley 11/2007, de 22 de junio, de Acceso Electrónico de los Ciudadanos a los Servicios Públicos (L11/2007) han acabado con las existencias de analgésicos de los botiquines de las empresas.
En concreto me refiero a los perfiles definidos en el Esquema de identificación y firma electrónica de las Administraciones públicas Bloque I: Perfiles de certificados electrónicos, que define los perfiles de los certificados anteriores, documento cuyas modificaciones respecto a su versión anterior ya hablamos en el pasado.
Vaya por delante que este documento seguro que se ha desarrollado con la mejor voluntad, buscando el máximo consenso y el mínimo impacto entre los diferentes actores del mercado, y también que cada decisión tiene detrás horas de diseño y una clara justificación. No obstante, por no haber participado en la definición de estos perfiles, se me escapa qué razonamiento hay detrás de determinadas decisiones.
Uso de las extensiones qcStatements
Los tipos de certificados identificados en la L11/2007 son:
- Sede electrónica
- Sello electrónica
- Personal al servicio de la administración pública
Sólo el tercero es claramente de persona física, el primero no contiene ningún dato de carácter personal y en el segundo es opcional. Entonces, ¿cómo puede ser que sean obligatorias las extensiones qcStatments, reservadas para certificados reconocidos, si un certificado reconocido debe contener, según interpretación del Ministerio de Indústria, Turimos y Comercio (MITyC) de la LFE, SIEMPRE, la identificación de la persona física con su nombre, apellidos y NIF?
Para mi se trata de una incongruencia y se le da mal uso a unas extensiones cuyo uso era bastante claro hasta el momento.
Identidad Administrativa
Duplicación de información
Son una serie de OIDs privados, que en el caso de los certificados de personal al servicio de la administración pública (de empleado público) son la friolera de once (11), a saber:
- OID: 2.16.724.1.3.5.3.2.1 = “certificado electrónico de empleado público”
- OID: 2.16.724.1.3.5.3.2.2 = <O del DN>
- OID: 2.16.724.1.3.5.3.2.3 = <CIF de la entidad suscriptora>
- OID: 2.16.724.1.3.5.3.2.4 = <serialNumber del DN>
- OID: 2.16.724.1.3.5.3.2.5 = Número de identificación del suscriptor del certificado (supuestamente unívoco). Se corresponde con el NRP o NIP. (tercera entrada <OU del DN>)
- OID: 2.16.724.1.3.5.3.2.6 = <Given name>
- OID: 2.16.724.1.3.5.3.2.7 = <Primer apellido del empleado público>
- OID: 2.16.724.1.3.5.3.2.8 = <Segundo apellido del empleado público>
- OID: 2.16.724.1.3.5.3.2.9 = <correo electrónico del empleado público>
- OID: 2.16.724.1.3.5.3.2.10 = Unidad, dentro de la Administración, en la que está incluida el suscriptor del certificado (segunda entrada <OU del DN>)
- OID: 2.16.724.1.3.5.3.2.11 = <T del DN>
Como puede verse en la lista comparativa anterior, toda la información que contienen estos campos ya se encuentran en otros campos del certificado. Es verdad que, por ejemplo, poner el NRP o NIP como una tercera entrada de OU del DN es, si no pervertir, retorcer el propósito inicial del campo OU, pero en general, el resto de información está bien colocada en campos estándares, sin necesidad de duplicarla
Numeración de los OIDs
Otra cosa que me llama la atención es la numeración de estos OIDs. Los seis (6) primeros campos son comunes (2.16.724.1.3.5.), y luego se usan tres posiciones más (m.n.o), que indican lo siguiente:
- m: 1 – sede electrónica, 2 – sello electrónico, 3 – empleado público
- n: 1 – nivel alto, 2 – nivel medio (cuando sólo hay dos niveles, ¿porqué se le llama a uno alto y a otro medio?, ¿no es “medio” un eufemismo en esta situación?
- o: 1..5 para sede electrónica, 1..9 en el caso de certificados de sello electrónico, 1..11 para los certificados de empleado público. Estos campos contienen la información redundante de la que hablábamos más arriba.
Esto nos lleva a manejar 5 (campos privados de sede)x2 (niveles) + 9×2 +11×2 = 50 OIDs privados. Esta es la realidad.
El otro extremo
Si nos ponemos ahorradores, manteniendo la interoperabilidad y sin pervertir campos estándares, sólo serían necesarios dos (2) campos adicionales, por ejemplo:
- OID: 2.16.724.1.3.5.3.1, con valores: 1 – sede nivel alto, 2 – sede nivel “medio”, 3 – sello nivel alto, 4 – sello nivel “medio”, 5 – empleado público nivel alto, 6 – empleado público nivel “medio”
- OID: 2.16.724.1.3.5.3.2, conteniendo el el NRP o NIP
Una alternativa menos ahorradora y que facilita más la interoperabilidad sería añadir un par de campos más:
- OID: 2.16.724.1.3.5.3.3, CIF de la entidad
- OID: 2.16.724.1.3.5.3.4, NIF de la persona física cuando proceda
En resumen, pienso que estos perfiles podían haber sido más sencillos y adherirse mejor a los estándares de uso de los campos de un certificado X.509v3.
Comments are welcome.
Certificados digitales en los navegadores, @firma y PSIS. ¿Ya funciona todo?
mayo 20th, 2011Apiadémonos de los Prestadores de Servicios de Certificación porque nunca son suficientemente valorados sus esfuerzos. Son los típicos esfuerzos que, si los haces, pasan desapercibidos y si no los haces, te llueven las … críticas.
En su día, comentamos lo que cuesta que los grandes desarrolladores de navegadores “precargasen” los certificados de los Prestadores de Servicios de Certificación.
Esto resuelve parte de los problemas.
Además, los prestadores tienen que realizar todas las gestiones para que sus diferentes políticas de certificados (tipos o clases de certificado) sean aceptadas (cargadas) por las plataformas de validación de las diferentes administraciones públicas (básicamente @firma y PSIS), que no son pocas.
Total, que se hacen los esfuerzos para cargar los certificados en los principales navegadores y las políticas en la principales plataformas de validación y uno (el prestador) se espera que ya todo funcione.
Pero no es así
Y no es así porque existe un protocolo llamado TLS (anteriormente SSL versión 3), que permite autenticación de cliente basada en certificados digitales.
¿Y con qué certificados me puedo autenticar en una determinada web?
¿Con los que emiten los prestadores cuyos certificados tiene precargados el navegador? No es condición suficiente. ¿Con las políticas aceptadas en @firma o PSIS (suponiendo que sea la web de una Administración Pública)? En absoluto, en esta autenticación todavía no se ha consultado a la plataforma de validación. Entonces, ¿con qué certificados se puede uno autenticar? Simplificando, con aquéllos emitidos por los prestadores cuyos certificados tenga cargados como Autoridades de Certificación de Confianza EL SERVIDOR WEB que presenta la página a la que estamos accediendo.
¿Qué implica esto?
Que los prestadores tienen que ir web por web de las distintas administraciones públicas identificado al responsable del servidor web y enviándole los certificados para que los “precargue” en el servidor web.
Si hay una renovación de un certificado de la jerarquía, empieza de nuevo (bueno, al responsable del servidor web ya lo tienes identificado en el 80% de los casos) para que en TODOS los servidores web de las distintas administraciones públicas se precargue el nuevo certificado.
¿Alguna alternativa?
Lo bueno de este tipo de autenticación (TLS o SSLv3) es que es sencilla de implantar (para el responsable del servidor web.) Los principales servidores web tienen herramientas que hacen que aceptar a un determinado prestador sea sencillo. Pero, como hemos visto, esto vuelve locos a los prestadores de servicios de certificación.
Aprovechando que existen unas plataformas de validación disponibles para las Administraciones públicas, quizá se podría cambiar el mecanismo de autenticación de la siguiente manera (de nuevo simplificando):
- Un usuario accede a la web que requiere autenticación.
- La web, consulta a la plataforma de validación pertinente…
- … que le devuelve una lista con las políticas de certificado admitidas para autenticarse (considérese el caching para evitar sobrecargar la red).
- La web, basándose en esta lista, muestra al usuario cuáles de sus certificados (del usuario) concuerdan con la lista.
- El usuario escoge un certificado y se autentica.
Esto implica algo más de trabajo para los responsables del servidor web de la administración (¡¡pero sólo una vez!!, ¡¡no cada vez que el prestador renueva o emite un certificado de la jerarquía!); sin embargo, da mucho más valor a las plataformas de validación, ahorra muchísimo trabajo a los prestadores de servicios de certificación (en la actualidad y en el futuro)
Esta “alternativa conceptual” de mecanismo de autenticación podría formar parte del Esquema Nacional de Interoperabilidad – ENI (o quizá del ENS – Esquema Nacional de Seguridad) , con lo que sería de obligado cumplimiento para las Administraciones Públicas, los prestadores no tendrían que preguntarse administración por administración qué hacer para que los ciudadanos nos podamos autenticar con sus certificados y la e-Administración sería más cercana y sencilla de usar para los ciudadanos, que es uno de los fines últimos de todo esto.
Y si aún se quiere un mecanismo más sencillo, se puede utilizar la pasarela de autenticación de isigma. Si quieres saber si podrías autenticarte con tu certificado, puedes ver los prestadores de servicios de certificación admitidos hasta el momento. Si no encuentras el tuyo, no dudes en hacérnoslo saber.
Si te ha gustado mi entrada, hazme un favor y compártela con más gente en tus redes sociales habituales usando los controles de más abajo.
¿Administración electrónica con la que está cayendo?
abril 11th, 2011La Ley 2/2011, de 4 de marzo, de Economía Sostenible, más conocida por la Ley Sinde gracias a su DISPOSICIÓN FINAL CUADRAGÉSIMO TERCERA, trae consigo otras lindeces.
En concreto me refiero a la DISPOSICIÓN ADICIONAL SÉPTIMA, que reproduzco 
íntegramente a continuación:
Uno. Se adiciona un nuevo apartado 5 a la disposición final tercera de la Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos, que queda redactado en los siguientes términos:
«5. Las Comunidades Autónomas y las Entidades integradas en la Administración Local en las que no puedan ser ejercidos a partir del 31 de diciembre de 2009 los derechos reconocidos en el artículo 6 de la presente Ley, en relación con la totalidad de los procedimientos y actuaciones de su competencia, deberán aprobar y hacer públicos los programas y calendarios de trabajo precisos para ello, atendiendo a las respectivas previsiones presupuestarias, con mención particularizada de las fases en las que los diversos derechos serán exigibles por los ciudadanos.
Los anteriores programas podrán referirse a una pluralidad de municipios cuando se deban ejecutar en aplicación de los supuestos de colaboración previstos en el apartado anterior.»
Dos. Los programas mencionados en el apartado anterior deberán ser objeto de aprobación y publicación en el plazo de seis meses desde la entrada en vigor de la presente Ley.
Desde mi humilde punto de vista, esta modificación me parece tan inoportuna como indefinida, y por lo tanto, ineficaz.
Inoportuna
Aunque la intención es buena y trata de subsanar la indefinición inicial de la Ley 11/2007, que no establecía ni plazos ni otras obligaciones a las AA. PP. diferentes de la del Estado en cuando a implantación de la Administración Electrónica, no lo logra pues es de nuevo indefinida y llega en un momento en el que todas las AA.PP. tienen que recortar sus presupuestos.
En 2007, la ley 11/2007 en su disposición final tercera, puntos 3 . (gobiernos autonómicos) y 4. (locales) indica el siguiente plazo:
[...] a partir del 31 de diciembre de 2009 siempre que lo permitan sus disponibilidades presupuestarias
La Ley 11/2007 se aprueba en el 2007 (evidente), exige que la AE esté lista para el 2009 y, ahora, dos años más tarde, en plena crisis, ¿quiere que las Administraciones se mojen?
Desde luego, una AE bien implantada y siguiendo los principios de la L11/2007 es una fuente de ahorro clara, pero primero hay que hacer la inversión y cuando las AA.PP. no tienen dinero para pagar a sus trabajadores y los ciudadanos no pueden soportar más carga fiscal, ¿de dónde sale?
Por cierto, haciendo números me sale que ese calendario tiene que publicarse el 6 de septiembre, lo que a efectos prácticos implica que hay que tenerlo listo antes del 30 de junio!!
Ineficaz
Con el nuevo redactado:
[...] deberán aprobar y hacer públicos los programas y calendarios de trabajo precisos para ello, atendiendo a las respectivas previsiones presupuestarias, con mención particularizada de las fases en las que los diversos derechos serán exigibles por los ciudadanos
seguimos teniendo ambigüedades (“precisos” se refiere a “necesarios”, no a precisión en alguna magnitud, por ejemplo, el tiempo, ¿no?). Entonces, ese calendario podría ser que el ayuntamiento de Villa Arriba se compromete a tener en el 2015 el trámite de empadronamiento electrónico, en el 2020 el de solicitud electrónica de volante de empadronamiento y en el 2025 el de pago de impuesto de recogida de basuras totalmente electrónicos y estaría cumplimiento.
Transparencia
La parte buena es que ahora (a partir del 6 de septiembre del 2011) los ciudadanos deberíamos saber cuando nuestros respectivos ayuntamientos, diputaciones y gobiernos autonómicos nos permitirán ejercer los derechos reconocidos en el artículo 6 de la L11/2007…y llegado el momento poder exigirlos.
De todas formas, aunque no en el grado deseado, ¡esperamos que la medida estimule en cierto modo el desarrollo de la administración electrónica!
Nueva política de Mozilla para incluir certificados de CA
marzo 22nd, 2011
Hace más de mes y medio Mozilla publicó la Mozilla CA Certificate Policy (Version 2.0)
¿Qués es esto?
Todo Prestador de Servicios de Certificación (PSC) lo sabe, pero no los internautas de a pie.
Es el conjunto de requisitos técnicos, organizacionales y de procedimientos que un PSC debe cumplir para que Mozilla considere distribuir su certificado de Autoridad (o entidad) de Certificación raíz en los productos de Mozilla (p.e. Thunderbird o Firefox)
¿Cómo me afecta?
Para los PSC, mucho. Para empezar porque deben cumplir esta nueva política antes del 8 de agosto de este año. Además, la nueva política añade dos secciones.
Para los usuarios de los productos de Mozilla, en principio debe añadir confianza. Es decir, se toma aún más en serio el hecho de confiar en los certificados emitidos por un determinado PSC. Esto tiene un daño colateral y es que quizá nos aparezca más a menudo el mensaje de no confirar en el certificado del sitio web. Sobre ello ya hablamos en Dificultades expandiendo la firma electrónica.
Para isigma, al principio nos hará más difícil “popularizar el uso de la firma electrónica”, pero a la larga, con productos que se toman más en serio esta tecnología, las personas confiaremos más en ella y tendrá usos que realmente aporten valor. Además, quizá nos da más trabajo en PSC que quieran que sus certificados estén precargados en los productos de Mozilla
¿En qué se diferencia de la anterior?
Como adelanto más arriba hay dos secciones totalmente nuevas, a saber:
- Mozilla CA Certificate Maintenance Policy: ya no basta con conseguir que se cargue el certificado raíz (recordemos que hace mucho tiempo que los certificados intermedios no se cargan) en los productos de Mozilla, ahora hay que seguir haciendo las cosas bien para que se mantengan!
- Mozilla CA Certificate Enforcement Policy: ahora Mozilla explicita lo que hará para que esta nueva versión de la política se cumpla
La primera parte de la política, Mozilla CA Certificate Inclusion Policy (Version 2.0), es prácticamente igual a toda la política anterior. Quien desee bucear por el detalle de los cambios puede hacerlo en el bug #609945 de Mozilla.
¿Es mejor o peor?
Como diría el amigo de los internautas, en este caso tengo el “corasón partío”.
Sin ninguna duda, la nueva política es más exigente, lo que implica que los certificados admitidos han sido emitidos por PSC con prácticas y políticas seguras, transparentes y con suites criptográficas adecuadas, además de pasar ciertas auditorías y aporta más confianza al usuario final.
Pero también puede provocar que aparezca con más frecuencia el mensaje de “No se confía en el certificado”, pues ciertos PSC pueden quedar fuera y algunos ni intentarlo.
Para los PSCs va a ser más difícil que Mozilla acepte sus certificados y puede implicar inversiones y, desde luego más tiempo desde que se inicia el procedimiento hasta que finalmente se logra. Obligará a anticipar.
Y para isigma, pues más trabajo
Definitivamente aumenta la confianza en la red. Definitivamente, es mejor.
info@isigma.es
+34 93 519 13 75
Blog internacional de firma electrónica
Nuestras aplicaciones para el DNI electrónico
ClickSign, la solución DESKTOP de firma electrónica
PortaSigma, tu PORTAFIRMAS en la nube
Pasarela de autenticación para Certificado Digital
