Archivo de la categoría: Interoperabilidad

Seminario sobre Factura Electrónica Obligatoria – 16 diciembre 2014


La Factura Electrónica se ha instaurado como un modelo de factura eficiente y segura que cada vez tiene una mayor aceptación y que es de uso obligatorio a partir del 15 de enero de 2015 para las empresas que facturan a las administraciones públicas y para las de especial relevancia económica.

Considerando que pueden aplicarse sanciones de hasta 10.000 euros, es vital  conocer las implicaciones de la nueva normativa de facturación, el desarrollo en curso de la facturación electrónica en las administraciones públicas, y el marco internacional directamente relacionado con este tipo de facturas.

La temática descrita es de interés para ayuntamientos, diputaciones y organismos públicos y para sus empresas proveedoras de productos y servicios.

Por ello, el próximo 16 de diciembre, Bartolomé Borrego, y yo explicaremos en Madrid todos los aspectos esenciales para que los organismos públicos y las empresas puedan prepararse para cumplir su parte en esa fecha. Entre los aspectos que tratamos, se encuentran las herramientas que ya están disponibles para cada entidad y que permitirían cumplir los plazos, incluso a las entidaes públicas y privadas rezagadas.

Lo organiza Atenea Interactiva, y tiene un coste de 199 €

Lugar de realización

Hotel NH Príncipe de Vergara

Calle del Príncipe de Vergara, 92

28006 Madrid

Programa

09.00h Acreditación y Entrega de Documentación.
09.30h Aspectos técnicos.

  • La firma electrónica. Tipos de firma electrónica.
  • Certificados. Tipos de certificados.
  • Prestadores de Servicios de certificación. Como conseguir las claves y los certificados.
  • Formatos posibles para las facturas electrónicas: EDI, UBL, CII, facturae.
  • Intercambio de facturas. Sistemas de comunicación y de notificaciones electrónicas.
  • Envío de facturas electrónicas a las administraciones públicas a través de la Plataforma FACE.
  • Recomendaciones para integración de sistemas y automatización de procesos.

15:30 Aspectos legales y fiscales.

  • Implicaciones fiscales de la factura y los medios electrónicos. Efectos, Principios y Ámbito. Contenido de las factura, marco normativo de la factura electrónica y modalidades de facturas.
  • Tipología de sistemas de facturación electrónica, Gestión de las facturas (expedición, envío, recepción y conservación). Sistemas admitidos fiscalmente en la facturación electrónica.
  • Aplicaciones comerciales y gratuitas de generación de facturas electrónicas.
  • Plataformas de facturación. Subfacturación y Conservación por terceros de las factura. Otros formatos de facturas electrónicas. Digitalización y Digitalización certificada de facturas.
  • La Inspección tributaria y las facturas y obligaciones de los usuarios.
  • Direcciones y publicaciones de interés sobre la factura electrónica.

 

 

Let’s Encrypt – Cifremos


The Internet Security Research Group (ISRG), en español, Grupo de Investigación de Seguridad de Internet (GISI), se ha constituido recientemente como entidad sin ánimo con el objetivo de impulsar la seguridad de Internet, especialmente a través de su iniciativa  ”Let’s Encrypt“Cifremos” que pretende distribuir gratuita y automáticamente certificados de servidor web basados en el protocolo “Secure Sockets Layer/Transport Layer Security” (SSL/TLS)ca todos los servidores del mundo.

En el Consejo del ISRG estarán representadas las entidades MozillaAkamai,Cisco, la Universidad de Michigan, la  Stanford Law School, CoreOS, IndenTrust, y la Fundación EFF (Electronic Frontier Foundation).

Estos son los miembros:

  • Josh Aas (Mozilla) — ISRG Executive Director
  • Stephen Ludin (Akamai)
  • Dave Ward (Cisco)
  • J. Alex Halderman (University of Michigan)
  • Andreas Gal (Mozilla)
  • Jennifer Granick (Stanford Law School)
  • Alex Polvi (CoreOS)
  • Peter Eckersley (EFF) — Observer

La iniciativa Let’s Encrypt, en español  “Cifremos” tiene entre sus destinatarios a los webmasters de las empresas, que instalan y mantienen servidores web. Si en la actualidad  conseguir los certificados de servidor es un engorro, por ser relativamente costosos y difíciles de instalar, con Let’s Encrypt se pretende resolver estos problemas creando una nueva Autoridad de Certificación (CA) que prepare e instale los certificados gratuita y automáticamente cuando se instalan los servidores o se reconfigura el software de un proyecto.

La gran ventaja de una internet en la que todos los servidores web usan SSL/TLS es que las comunicaciones se cifran siempre, y por tanto sus contenidos no son accesibles ni para atacantes maliciosos ni para gobiernos con pretensiones de espiar o censurar a sus ciudadanos (o a ciudadanos de otros países).

Let’s Encrypt ya ha comenzado a desarrollar los protocolos y el software necesario.

La Autoridad de Certificación (CA) de Let’s Encrypt dialoga con un software de gestión específico instalado en los servidores mediante el protocolo ACME (“Automated Certificate Management Environment”). Ya existe un borrador de la especificación ACME. Se pretende promover esta especificación para que sea parte del cuerpo normativo de la Internet Engineering Task Force (IETF) en el plazo más breve posible, y de esta forma garantizar su evolución como estándar abierto.

Tanto el software utilizado por la CA (Certification Authority) como el de las aplicaciones que acceden a ella y que facilitan a los administradores de sistemas la configuración de certificados SSL/TLS en servidores web como Apache, Nginx y Microsoft IIS, serán de fuentes abiertas. La CA pretende operar de forma transparente de modo que el repositorio de certificados emitidos y revocados estará a disposición de quien quiera inspeccionarlos.

Let’s Encrypt se someterá a los procesos de auditoría habituales de todas las CA y cumplirá los requerimientos básicos (baseline requirements) establecidos por la organización de cooperación entre desarrolladores de navegadores y autoridades de certificación  CA/Browser Forum en cuanto a la emisión y gestión de certificados digitales.

El Internet Security Research Group (ISRG) solicitará que sus certificados raíz se incluyan en los programas definidos por los desarrolladores de navegadores como Mozilla y Microsoft, para que estos navegadores confíen en los certificados emitidos por la CA de ISRG por defecto (sin requerir una aprobación expresa por los usuarios). Dado que este proceso puede ser largo y laborioso y que puede llegar a necesitar hasta 3 años por cada navegador, inicialmente ISRG solicitará a IdenTrust  (cuyas CA raíz ya están integradas en los navegadores) que firme sus certificados.   IdenTrust es uno de los impulsores del proyecto.

Para colaborar en España con esta iniciativa, contactar con Julian (@) inza.net

¿En qué se diferencian SAML, OpenID y OAuth?


Aunque entrar en detalle llevará unos cuantos párrafos, la respuesta breve sería que son sistemas que facilitan el acceso unificado (single sign on) con los siguientes matices:

  • OpenID – Es un «single sign on» para usuarios finales, tales como consumidores.
  • SAML – Es un «single sign-on» orientado a usuarios empresariales.
  • OAuth – Es una API (Application Programming Interface) de autorización entre aplicaciones.

OpenID es relativamente sencillo de utilizar y muy prometedor.  EADTrut desarrolló hace unos años un piloto de servidor de autenticación OpenID, que utilizaba el DNI electrónico como base de la autenticación SSL/TLS y que luego podía heredarse de forma muy sencilla en otros servidores (páginas web) que implementaran OpenID.  Se publicaron varias referencias  sobre el piloto, que resultó un éxito.

SAML

El Lenguaje de Marcado para Confirmaciones de Seguridad, conocido como SAML, (pronunciado como «sam-el») es un estándar abierto que define un esquema XML para el intercambio de datos de autenticación y autorización. Usualmente las partes que intervienen en el intercambio son un proveedor de identidad (IdP – Identity Provider) y un proveedor de servicio. SAML es una especificación publicada por el comité OASIS (Security Services Technical Committee).

SAML inició su especificación en el año 2001, siendo su versión estable liberada en el año 2005, y es utilizado como elemento clave en sistemas centralizados de autenticación y autorización (Single Sign-On).

La especificación SAML define tres roles:

  • Principal
  • Proveedor de identidad
  • Proveedor de servicio.

En un escenario típico, el rol principal solicita un servicio al proveedor de servicios, quien a su vez solicita y obtiene en caso de éxito, una confirmación de identidad desde el proveedor de identidad. Teniendo como base la confirmación recibida, el proveedor de servicio puede tomar decisiones acerca del acceso autorizado a un usuario.

OpenID

OpenID es un estándar de identificación digital descentralizado, con el que un usuario puede identificarse en una página web a través de una URL (o un XRI en la versión actual) y puede ser verificado por cualquier servidor que soporte el protocolo.

En los sitios que soporten OpenID, los usuarios no tienen que crearse una nueva cuenta de usuario para obtener acceso. En su lugar, solo necesitan disponer de un identificador creado en un servidor que verifique OpenID, llamado proveedor de identidad o IdP (Identity Provider).

El proveedor de identidad puede confirmar la identificación OpenID del usuario al sitio que soporte este sistema y que confíe en el.

A diferencia de otras arquitecturas Single Sign-On, OpenId no especifica el mecanismo de autenticación. Por lo tanto, la seguridad de una conexión OpenId depende de la confianza que tenga el cliente OpenID en el proveedor de identidad. Si no existe confianza en el proveedor, la autenticación no será adecuada para servicios bancarios o transacciones de comercio electrónico, sin embargo el proveedor de identidad puede usar autenticación fuerte pudiendo ser usada para dichos fines.

OAuth

OAuth (Open Authorization) es un protocolo abierto, propuesto por Blaine Cook y Chris Messina, que permite autorización segura de una API de modo estándar y simple para aplicaciones de escritorio, móviles y web.

Para desarrolladores de consumidores, OAuth es un método para interactuar con datos protegidos y publicarlos. Para desarrolladores de proveedores de servicio, OAuth proporciona a los usuarios un acceso a sus datos al mismo tiempo que protege las credenciales de su cuenta. En otras palabras, OAuth permite a un usuario del sitio A compartir su información en el sitio A (proveedor de servicio) con el sitio B (llamado consumidor) sin compartir toda su identidad.

En relación con la gestión de identidad, hay, además otras tecnologías y organizaciones que merece la pena tomar en consideración, como OATH, Liberty Alliance, Kantara, Passport, o CardSpace

OATH

OATH (Initiative for Open Authentication) es una arquitectura abierta de autenticación robusta (Open Strong Authentication) basada en tokens efímeros de autenticación, en posesión del usuario y gestionados por hardware o por software. Agrupa a más de 30 fabricantes y sus especificaciones  están basadas en diversos estándares.

Liberty Alliance

El proyecto Liberty Alliance fue una organización que operó entre 2001 y 2009 para establecer estándares y buenas prácticas para la gestión de identidad en sistemas informáticos. Llegó a agrupar más de 150 organizaciones.

Definió marcos de interoperabilidad para la federación de identidades.

La iniciativa desembocó, junto con otras en la organización Kantara.

Kantara

Kantara es una asociación profesional sin fines de lucro orientada a impulsar los avances en aspectos técnicos y legales relacionados con la gestión digital de identidad, ubicada en Delaware.

Kantara unifica inciativas anteriores como Liberty Alliance, el proyecto DataPortability, el proyecto Concordia, la Internet Society, la Information Card Foundation, OpenLiberty.orgXDI.org.  Se anunció en junio de 2009.

Kantara no es un organismo de estandarización, pero envía propuestas y recomendaciones a este tipo de organismos, tales como  OASIS (Organization for the Advancement of Structured Information Standards), IETF (Internet Engineering Task Force),   ISO (International Organization for Standardization), o  ITU-T (ITU Telecommunication Standardization Sector, uno de los sectores de la International Telecommunication Union).

Microsoft Passport

Microsoft Passport está formado por dos servicios: un servicio de inicio de sesión único que permite que los miembros utilicen un único nombre y contraseña para iniciar sesión en un número creciente de sitios Web participantes y un servicio de cartera que los miembros pueden utilizar para realizar compras en línea rápidas y cómodas.

Con el tiempo ha evolucionado a Windows Live ID.

CardSpace

Windows CardSpace (cuyo código de proyecto interno era InfoCard), es un cliente de software destinado a su uso en el metasistema de gestión de identidad (Identity Metasystem) y como iniciativa de gestión de identidades ha sido cancelado.   Su punto fuerte era la interfaz de usuario, basada en tarjetas de información que permitían gestionar de forma sencilla y segura la identidad dependiendo de la aplicación y de los sitios web a los que se acede. Además, en su diseño se tuvieron en cuenta la resistencia a los ataques de «phishing» y las denominadas «7  leyes de la Identidad» de Kim Cameron.

100 entradas gratis para el Exchange Summit el 6 y 7 de octubre de 2014 en Barcelona


El organizador de la Cumbre de las Interconexiones Empresariales (Exchange Summit) ofrece un centenar de entradas gratuitas para el evento que tendrá lugar  el 6 y 7 de octubre de 2014 en Barcelona.

Podrán optar a estas entradas los asistentes que cumplan los siguientes criterios:

  • Que procedan de organizaciones con más de 250 empleados 
  • Que dichas organizadciones sean remitentes o destinatarias de facturas electrónicas, o puedan llegar a serlo.
  • Que tengan un papel de cierta influencia en la toma de decisiones sobre selección de prestadores
  • No hayan asistido con anterioridad a un evento de los precedentes (EXPP Summit)

Nota:: No podrán optar a este tipo de entradas gratuitas  los consultores, y los prestadores de aplicaciones o de servicios de facturación electrónica. Su asignación será decidida por el organizador de 

 La distribución de las entradas gratuitas se está determinando y llevó a cabo-por el organizador de la Cumbre  de las Interconexiones Empresariales.

Más información en la Web del evento

Transmisión de titularidad de documentos electrónicos


Los documentos en papel quedan singularizados por su soporte y la mera transmisión de la propiedad del soporte puede implicar el ejercicio del derecho de lo que en ellos se haga constar.

Esto es así en los denominados «títulos valores» que reflejan la propiedad de una fracción de una empresa y un derecho de cobro de dividendos y en los denominados «títulos cambiarios» en los que se reseña el derecho de cobro de una determinada cantidad al librado.

Pero hay muchos otros documentos cuya mera posesión representa algún derecho o algún valor: un billete de banco, un billete de lotería, un sello, una entrada a un espectáculo, un billete de un medio de transporte («título de transporte»),…

¿Qué sucede cuando se desmaterializa el documento pero es preciso llevar a cabo la misma función electrónicamente?

Es necesario concebir un tipo de documento electrónico en el que se aplique el concepto de «unidad de fin». Un tipo de documento electrónico que permita diferenciar el original de la copia, de una forma que llegue más lejos que la de aplicar un convencionalismo (por ejemplo, en el caso de la factura electrónica, el originador custodia la «copia» y el destinatario el «original» porque, aun siendo ambos documentos exactamente iguales, el requisito formal de posesión del original atribuye al destinatario el derecho a la deducción del impuesto de valor añadido).

La práctica empresarial y mercantil ha desarrollado al cabo de los años soluciones ad-hoc, que han resuelto el problema en varios supuestos: los sistemas de anotaciones en cuenta vinculados a la compensación y liquidación de valores, los sistemas de transferencias electrónicas de dinero, los sistemas de reserva de vuelos o viajes por otros medios,…

También se han desarrollado experimentos y proyectos piloto para la gestión de títulos cambiarios, como el que yo mismo promoví a mi paso por FESTE en 1999 (proyecto Pista-Títulos Cambiarios Electrónicos que se desarrollaría los años siguientes con la contribución de varias entidades: Tecsidel, Bufete Roca Junyent Advocats, FESTE, Banco Sabadell, Grupo Adepa,  Safelayer, Transeca y EsCERT-UPC)

Sin embargo, hasta la fecha no se contaba con una solución genérica capaz de hacer frente a todos los retos que el mundo digital presenta para los documentos electrónicos en los que se deba diferenciar el original de la copia y respecto a los que se pueda establecer la propiedad de ser necesario, gestionando la transmisión o endoso de documentos electrónicos.

La herramienta se denomina Cartulario, que ahora incluye la funcionalidad de gestión de aceptación y endoso con firma electrónica, y gestiona vencimientos gestión de incidencias (impagos, protestos y soporte a gestión litigiosa). Para más información contactar con EADTrust en el +34 91 7160555

 

Certificado de sello de empresa para firmar facturas electrónicas que se envían a FACE


La Ley 25/2013, de 27 de diciembre, de impulso de la factura electrónica y creación del registro contable de facturas en el Sector Público contiene varios aspectos muy interesantes.

En su artículo 5 se refiere al Formato de las facturas electrónicas y su firma electrónica, y en su apartado 2 dice lo siguiente:

2. También se admitirá el sello electrónico avanzado basado en un certificado reconocido que reúna los siguientes requisitos:

a) El certificado deberá identificar a la persona jurídica o entidad sin personalidad jurídica que selle la factura electrónica, a través de su denominación o razón social y su número de identificación fiscal.

b) La solicitud del sello electrónico avanzado podrá formularse bien mediante comparecencia presencial de una persona física que acredite su representación, bien por medios electrónicos mediante el DNI electrónico y la remisión de los documentos que acrediten su poder de representación en formato papel o electrónico.

El sello electrónico es el conjunto de datos en forma electrónica, consignados o asociados con facturas electrónicas, que pueden ser utilizados por personas jurídicas y entidades sin personalidad jurídica para garantizar el origen y la integridad de su contenido.

Esta norma ha sido una adaptación anticipada al Reglamento europeo – Identificación electrónica y servicios de confianza para las transacciones electrónicas en el mercado interior que se ha aprobado hace pocos meses en el Parlamento Europeo.

Las definiciones de su artículo 3, recogen, entre otras, las siguientes:

(24) «creador de un sello», una persona jurídica que crea un sello electrónico;
(25) «sello electrónico», datos en formato electrónico anejos a otros datos electrónicos, o asociados de manera lógica con ellos, para garantizar el origen y la integridad de los datos asociados;
(26) «sello electrónico avanzado», un sello electrónico que cumple los requisitos siguientes:

a) estar vinculado al creador del sello de manera única;
b) permitir la identificación del creador del sello;
c) haber sido creado utilizando datos de creación del sello electrónico que el creador del sello puede utilizar para la creación de un sello electrónico, con un alto nivel de confianza, bajo su control exclusivo, y
d) estar vinculado con los datos a que se refiere de modo tal que cualquier modificación ulterior de los mismos sea detectable;
(27) «sello electrónico cualificado», un sello electrónico avanzado que se crea mediante un dispositivo cualificado de creación de sellos electrónicos y que se basa en un certificado cualificado de sello electrónico;
(28) «datos de creación del sello electrónico», los datos únicos que utiliza el creador del sello electrónico para crearlo;
(29 ) « ▌certificado de sello electrónico», una declaración electrónica que vincula los datos de validación de un sello con una persona jurídica y confirma el nombre de esa persona ;
(30) «certificado cualificado de sello electrónico», un certificado de sellos electrónicos que ha sido expedido por un prestador cualificado de servicios de confianza y que ▌ cumple los requisitos establecidos en el anexo III;
(31) «dispositivo de creación de sellos electrónicos», un equipo o programa informático configurado que se utiliza para crear un sello electrónico;
(32) «dispositivo cualificado de creación de sellos electrónicos », un dispositivo de creación de sellos electrónicos que cumple mutatis mutandis los requisitos enumerados en el anexo II;

Y la sección sobre sellos electrónicos (a partir del artículo 34 señala:)

Artículo 34

Efectos jurídicos del sello electrónico

1.  No se denegarán los efectos jurídicos y la admisibilidad como prueba en procedimientos judiciales de un sello electrónico por el mero hecho de ser un sello electrónico o de no cumplir los requisitos del sello electrónico cualificado .

2.  Un sello electrónico cualificado disfrutará de ▌la presunción de ▌integridad de los datos y de la corrección del origen de los datos a los que el sello electrónico cualificado esté vinculado.

3.  Un sello electrónico cualificado basado en un certificado cualificado emitido en un Estado miembro será reconocido como un sello electrónico cualificado en todos los demás Estados miembros.

Artículo 35

Sellos electrónicos en servicios públicos

1.  Si un Estado miembro impone un sello electrónico avanzado con el fin de utilizar un servicio en línea ofrecido por un organismo del sector público, o en nombre del mismo, dicho Estado miembro reconocerá los sellos electrónicos avanzados, los sellos electrónicas avanzados basados en un certificado reconocido para los sellos electrónicos y los sellos electrónicos cualificados por lo menos en los formatos o con los métodos contemplados en el apartado 5.

2.  Si un Estado miembro impone un sello electrónico avanzado basado en un certificado cualificado con el fin de utilizar un servicio en línea ofrecido por un organismo del sector público, o en nombre del mismo, dicho Estado miembro reconocerá los sellos electrónicos avanzados basados en un certificado y los sellos electrónicos cualificados por lo menos en los formatos o con los métodos contemplados en el apartado 5.

3.  Los Estados miembros no exigirán, para el uso transfronterizo en un servicio en línea ofrecido por un organismo del sector público, un sello electrónico cuyo nivel de seguridad sea superior al de un sello electrónico cualificado.

4.  ▌La Comisión podrá, mediante actos de ejecución, establecer números de referencia de normas relativas a los sellos electrónicos avanzados . Se presumirá el cumplimiento de los requisitos de los sellos electrónicos avanzados mencionados en los apartados 1 y 2 del presente artículo y en el punto 26 del artículo 3 cuando un sello electrónico avanzado se ajuste a dichas normas. Estos actos de ejecución se adoptarán con arreglo al procedimiento de examen contemplado en el artículo 46, apartado 2. La Comisión publicará estos actos en el Diario Oficial de la Unión Europea.

5.  A más tardar el … (21) , y teniendo en cuenta las prácticas existentes, las normas y actos jurídicos de la Unión, la Comisión adoptará actos de ejecución que definan los formatos de referencia de los sellos electrónicos avanzados o métodos de referencia cuando se utilicen formatos alternativos. Estos actos de ejecución se adoptarán con arreglo al procedimiento de examen contemplado en el artículo 46, apartado 2.

Artículo 36

Certificados cualificados de sello electrónico

1.  Los certificados cualificados de sello electrónico cumplirán los requisitos establecidos en el anexo III.

2.  Los certificados cualificados de sello electrónico no estarán sometidos a ningún requisito obligatorio que exceda de los requisitos establecidos en el anexo III.

3.  Los certificados cualificados de sellos electrónicos podrán incluir atributos específicos adicionales no obligatorios. Esos atributos no afectarán a la interoperabilidad y reconocimiento de los sellos electrónicos cualificados.

4.  Si un certificado cualificado de sello electrónico ha sido revocado después de su activación inicial, perderá su validez desde el momento de su revocación y no podrá en ninguna circunstancia recuperar su estado ▌.

5.  Según las condiciones expuestas a continuación, los Estados miembros podrán fijar normas nacionales sobre la suspensión temporal de certificados cualificados de sello electrónico:

a) Si un certificado cualificado de sello electrónico ha sido suspendido temporalmente, ese certificado perderá su validez durante el periodo de suspensión.
b) El periodo de suspensión se indicará claramente en la base de datos certificada y el estatuto de suspensión será visible, durante el período de suspensión, a partir del servicio que proporcione la información sobre el estatuto del certificado.

6.  La Comisión podrá, mediante actos de ejecución, establecer números de referencia de normas relativas a los certificados cualificados de sello electrónico. Se presumirá el cumplimiento de los requisitos establecidos en el anexo III cuando un certificado cualificado de sello electrónico se ajuste a dichas normas. Estos actos de ejecución se adoptarán con arreglo al procedimiento de examen contemplado en el artículo 46, apartado 2. ▌

Artículo 37

Dispositivos de creación de sellos electrónicos cualificados

1.  El artículo 28 se aplicará mutatis mutandis a los requisitos de los dispositivos de creación de sellos electrónicos cualificados.

2.  El artículo 29 se aplicará mutatis mutandis a la certificación de los dispositivos de creación de sellos electrónicos cualificados.

3.  El artículo 30 se aplicará mutatis mutandis a la publicación de una lista de dispositivos de creación de sellos electrónicos cualificados certificados.

Artículo 38

Validación y conservación de los sellos electrónicos cualificados

Los artículos 31, 32 y 33 se aplicarán mutatis mutandis a la validación y conservación de los sellos electrónicos cualificados.

Con esta normativa, parece claro que los certificados idóneos para firmar facturas, en el momento actual, son los de sello electrónico de empresa.

Sin embargo, pese a lo indicado en el artículo 6. Punto general de entrada de facturas electrónicas, en su apartado 3:

3. El punto general de entrada de facturas electrónicas permitirá el envío de facturas electrónicas en el formato que se determina en esta Ley. El proveedor o quien haya presentado la factura podrá consultar el estado de la tramitación de la factura.

Lo cierto es que por algún ignorado motivo, el FACE (Punto General de Entrada de Facturas Electrónicas de la Administración General del Estado) no admite facturas firmadas haciendo uso de certificados de sello de empresa.

Si alguien lo sabe, se agradece que lo indique en los comentarios del artículo.

Mientras, continuaré estudiando la interesante información publicada en el portal de la administración electrónica, sobre el FACE. Si encuentro la razón actualizaré el artículo.

Las «Barreras Giovannini»


El Grupo Giovannini fue un grupo de expertos del mercado financiero, creado en 1996 para asesorar a la Comisión Europea sobre cuestiones del mercado financiero. En particular, el trabajo del grupo Giovannini se centró en la identificación de ineficiencias en los mercados financieros de la UE y en la propuesta de soluciones prácticas para mejorar la integración de los mercados.

Dos informes del Grupo identificaron un total de 15 barreras  específicas (conocidas desde ese momento como Barreras Giovannini) que impiden la eficaz actividad financiera transfroneriza en la Unión Europea relativa a compensación y liquidación.

  1. Diferencias nacionales en tecnología de la información e interfaces
  2. Restricciones nacionales de compensación y liquidación que requieren el uso de múltiples sistemas
  3. Diferencias en las normas nacionales relativas a los recursos corporativos, la propiedad beneficiosa y custodia
  4. Falta de firmeza de la liquidación intradía
  5. Impedimentos prácticos para el acceso remoto a los sistemas de liquidación y compensación
  6. Diferencias nacionales en períodos de liquidación
  7. Diferencias nacionales en las horas de servicio y cierres de la liquidación
  8. Diferencias nacionales en la práctica la emisión de valores
  9. Restricciones nacionales sobre la ubicación de los valores
  10. Restricciones nacionales sobre la actividad de los operadores primarios y de los creadores de mercado
  11. Regulaciones de retención de impuestos nacionales que  perjudican a los intermediarios extranjeros
  12. Impuestos sobre transacciones recogidos a través de cierta funcionalidad integrada en los sistemas de liquidación nacionales
  13. Ausencia de un marco comunitario para el tratamiento de los intereses en los valores
  14. Diferencias nacionales en el tratamiento legal de la compensación bilateral para las transacciones financieras
  15. Aplicación desigual de los conflictos derivados del marco legal y regulatorio

Este es el enlace para acdeder al informe (en inglés): The Giovannini Group – Second Report on EU Clearing and Settlement Arrangements

Desde entonces diferentes actividades de la Unión Europea van encaminadas a la eliminación de las Barreras Giovannini, entre ellas, la puesta en marcha del sistema TARGET2 Securities (T2S).

Periodo de vigencia del CSV (Código Seguro de Verificación)


En relación con la implementación de la Ley 11/2007 por parte de las administraciones públicas surgen preguntas como ¿Durante cuanto tiempo se pueden ver en la sede electrónica los documentos electrónicos a través del Código Seguro de Verificación?

La normativa desarrollada no contempla todas las opciones y los organismos tienen que tomar decisiones. Para fijar criterio a la hora de trabajar en las implantaciones de la administración electrónica conviene tener en cuenta los conceptos de la diplomática digital.

En relación con la pregunta indicada, hay que decir que el CSV debe conservarse para siempre. El acceso al documento se limita por la política de gestión documental de la entidad, y debe poder hacerse siempre, bien en la sede electrónica original, bien en el organismo a cargo del archivo.

Hay que hacerse a la idea de que el CSV equivale al número de protocolo de los notarios.

En el ámbito notarial, se puede solicitar copia simple o auténtica de un documento a partir de su matriz en el propio notario que lo protocolizó (cuya identidad equivale a la de la sede electrónica del organsmo) o bien en su sucesor en el protocolo, o bien en el sistema de archivo a largo plazo de protocolos.

En el caso de las administraciones públicas, siempre debe quedar definido en la política de gestión documental el órgano ante el que se puede solicitar el documento una vez superada la fase administrativa en la que el procedimiento esta «vivo» o dentro de los plazos de prescripción.

Y para el «handout» de documentos electrónicos auténticos, cuando deban hacerse cargo de ello los archivos a largo plazo, debe firmarse entre el organismo cedente y el cesionario un documento que refleje las técnicas de preservación documental electrónica previas y futuras y los controles de integridad (hashes y timestampings) de los documentos (o colecciones) transferidos.

Atenea Interactiva organiza cursos de Diplomática Digital. Se puede contactar con el 902 365 612 o el 917160555 para solicitar un curso in-company o para inscribirse en el próximo seminario abierto sobre este tema.

Firma electrónica en zEnterprise EC12


Recientemente IBM ha lanzado el nuevo sistema «mainframe» zEnterprise EC12, con clara orientacion hacia entornos de private cloud, con disponibilidad de muchísima potencia de cómputo en entornos de múltiples tipos de procesadores, sistemas operativos y cargas de trabajo.

El zEnterprise EC12 ofrece nuevos niveles de rendimiento y capacidad para consolidación de múltiples sistemas  y crecimiento a gran escala, compatibilidad con la nueva generación de equipamiento de  seguridad para firma digital, el nuevo HSM (Hardware Security Module) Crypto Express 4S, análisis avanzado de reconocimiento de patrones para el control inteligente de la funcionalidad de los componentes del sistema, nueva opción para instalaciones en  suelo no técnico y despliegue de tecnologías híbridas de procesamiento para diferentes sistemas operativos y todo tipo de cargas de trabajo distribuidas, incluyendo las específicas de mainframe (z/OS , z/VM , z/VSE , z/TPF, y Linux on System z).

En el Mainframe se equipa la cabina de entrada salida compatible con interfaz PCIe Gen2 (Peripheral Component Interconnect Express Generation 2) al que se conecta cada adaptador Crypto Express4S que da soporte a todas las funciones del modelo de adaptador criptográfico anterior Crypto Express3.

Este adaptador se puede configurar a través de la consola HMC (Hardware Management Console) de tres formas distintas:

  1. Como coprocesador CCA: IBM Common Cryptographic Architecture (CCA) coprocessor
  2. Como coprocesador PKCS#11: IBM Enterprise PKCS #11 (EP11) coprocessor
  3. Como Acelerador (Accelerator)

El adaptador se ha certificado de acuerdo con los estándares  FIPS 140-2 Security Level 4 y Common Criteria EAL 4+.

A través de CPACF (Central Processor Assist for Cryptographic Function) función que no implica coste al habilitarla en el sistema, puede gestionar los siguientes algoritmos criptográficos:

  • Algoritmos de hash (Secure hash algorithms) SHA-1, SHA-224, SHA-256, SHA-384, y SHA-512 habilitado en todos los servidores con unidades de proceso  (PUs – processor units) definidas como  CPs, IFLs, zIIPs, or zAAPs.
  • Cifrado Simétrico
    • Data Encryption Standard (DES)
    • Triple Data Encryption Standard (TDES)
    • Advanced Encryption Standard (AES) con claves de 128-bits, 192-bits, y 256-bits
  • Control de Integridad (Secure Hash Algorithms)
    • SHA-1: 160 bit
    • SHA-2: 224, 256, 384, and 512 bit
  • Control de Integridad (MAC)
    • Single-length key MAC
    • Double-length key MAC

El soporte  IBM Enterprise PKCS #11 (EP11) IBM Enterprise Public-Key Cryptography Standards (PKCS) #11 está basado en la especificatión v2.20 de PKCS #11 y se incluye enlos sistemas operativos  z/OS y z/VM medianteICSF (Integrated Cryptographic Service Facility).

El soporte criptográfico es de especial interés en banca, ya que permite, por ejemplo gestionar las funciones de seguridad de las tarjetas EMV, o cifrar la información relevante sobre tarjetas y titulares que exige el cumplimiento de la normativa PCI DSS.

Gracias al soporte PKCS#11 permite utilizar el sistema de firmas electrónicas zBackTrust de Albalia (con soporte para CAdES, XAdES y PAdES) en z/OS además de en Linux on System z.

La solución zBackTrust es la única disponible a nivel mundial con soporte nativo para mainframe en equipos z9, z10 z196, z114 y  zEC12 y capacidad de gestionar las citadas formas de firma, aunque IBM ofrece un tipo de unidad integrable en los bastidores zEnterprise que también permite realizar la funconalidad de firma electrónica con sus propias funciones criptográficas externalizadas del sistema principal (Datapower).

El sistema zBackTrust de Albalia se puede instalar sobre entornos de gestión de transacción para Java como WebSphere , Weblogic y Tomcat y soporta de forma nativa las diferentes funcionalidades de la norma DSS   (Digital Signature Services) de OASIS, de modo que la gestión de la firma electrónica se puede llevar a cabo de forma centralizada para toda la organización mediante webservices que se pueden invocar desde entornos Linux, Apple y Windows.

El sistema zBackTrust está disponible bajo diferentes tipos de licencias:

  • System
  • Site
  • Enterprise
  • Cloud

lo que permite que se pueda disponer de múltiples instancias de ejecución sin coste adicional.

El sistema zBackTrust puede contratarse a través de IBM, a través de INSA o directamente a través de Albalia, contactando con el 91 716 0555 de España (+34 917160555).

Otros artículos relacionados:

Recognition of electronic signatures between EEA countries


Reconocimiento de firmas electrónicas entre países miembros del Area Económica Europea (EEA)

El principio de reconocimiento de firmas electrónicas, certificados digitales y productos de firma entre Estados Miembros de la Unión Europea y el resto de miembros del Area Económica Europea (EEA) se rige por la incorporación de la Directiva 1999/93/EC en el Acuerdo del Area Económica Europea, en virtud de la Decisión del Comité Conjunto nº 66/2000 de fecha 02.08.2000 rectificando el Anexo XI (Servicios de Telecomunicaciones ) al acuerdo EEA.

The principle of recognition of electronic signatures, signature certificates and signature products between EU Member States and the other countries member of the European Economic Area (EEA), is governed by the incorporation of Directive 1999/93/EC in the Agreement on the European Economic Area, by virtue of Decision of the EEA Joint Committee n°66/2000 of 2.8.2000 amending Annex XI (telecommunication services) to the EEA Agreement.

Los firmantes del acuerdo son los 27 estados miembros de la Unión Europea, y los siguientes tres países  de la EFTA (European Free Trade Association, Asociación Europea de Libre Comercio): Islandia, Noruega y Liechtenstein (todos salvo Suiza).

Contracting parties of the EEA agreement are the 27 EU Member States and three EFTA countries, Iceland, Norway and Liechtenstein.

Reconocimiento de firmas electrónicas entre la Unión Europea y países y organizaciones internacionales terceros.

Recognition of electronic signatures between EU and third countries and international organisations

El reconocimiento de certificados de terceros países y organizaciones internacionales se recoge en el párrafo 1 del artículo 7 de la Directiva 1999/93/EC :

Recognition of signatures certificates from third countries and international organisations is provided for by paragraph 1 of article 7 of Directive 1999/93/EC on international aspects:

Member States shall ensure that certificates which are issued as qualified certificates to the public by a certification-  service-provider established in a third country are recognised as legally equivalent to certificates issued by a certification-service-provider established within the Community if:

(a) the certification-service-provider fulfils the requirements laid down in the Directive and has been accredited under a voluntary accreditation scheme established in a Member State; or

(b) a certification-service-provider established within the Community which fulfils the requirements laid down in the Directive guarantees the certificate; or

(c) the certificate or the certification-service-provider is recognised under a bilateral or multilateral agreement between the Community and third countries or international organisations.

En el momento actual no existen acuerdos diferentes de los referidos al área EAA, ya mencionados, en aplicación del párrafo 1.c del artículo 7 ni existe constancia de la existencia de casos de uso conformes con los párrafo 1.a y 1.b del citado artículo 7.

As of today, no agreement has been signed under article 7.1.c (except for EEA countries – see above) and no cases of usage of articles 7.1.a or 7.1.b has been reported.

The European Commission plans organising starting in 2012 three exploratory seminars on trust in e-business transactions within the South Mediterranean Region – see attached fiche for details.