Archivo de la categoría: #eIdaS

Certified Digitization, what is it and what is it for?


Certified Digitization, Certified Digitisation Certified scanning, Electronic Invoice, Electronic Signature, Electronic Certificate. EIDAS, All these concepts are related.

In the development of electronic invoicing regulations, Spanish ORDER EHA / 962/2007, of April 10, which develops certain provisions on electronic billing and electronic storage of invoices, has defined in Spain the concept of Certified Digitization. This blog has been a pioneer in dealing with Certified Digitization since 2006.

Also in english, with some posts:

The homologation procedure has been included in the resolution of October 24, 2007, of the State Tax Administration Agency, on the procedure for homologation of digitization software contemplated in Order EHA / 962/2007, of April 10, 2007 .

In a strict sense, certified digitization was defined for the procedures of the tax field, which would be outside the coverage of Law 39/2015 (eGovernment). However, the implementation of the concept and the large number of available applications make it a de facto standard , also for the public sector.

Certified digitisation is the process of converting paper documents into electronic documents that contain their facsimile reproduction and are electronically signed or sealed. The systems that manage the digitisation must meet certain criteria of integrity and unalterability in the database with which the digitisation is carried out and are required to be audited. The documents digitised with this type of system have the character of originals, so that the paper documents from which they originate can be dispensed with, which is why the legal value of these processes and of the documents to which they give rise is very relevant

Certified digitisation of invoices has led to the birth of the concept that is now also used in relation to public administrations and the digitisation of Justice.

For the certified digitisation of invoices, you can use the different variants of software approved by the Tax Agency that the AEAT also publishes on its website. The provincial councils of Navarre, Biscay, Alava and Guipuzcoa have also published equivalent regulations and have approval procedures similar to those of the Spanish National Tax Agency and have their own lists of approved software.

Electronic signature

Electronic signature is regulated in the EU Regulation 910/2014, which is abbreviated as “EIDAS”.

Advanced electronic signature is uniquely linked to the signatory; allows the identification of the signatory; It is created using electronic signature creation data that the signatory can, with a high level of confidence, use under his sole control; and is llinked to the data signed therewith in such a way that any subsequent change in the data is detectable.

In summary, the advanced signature links the signatory with what was signed.

What is signed many times is condensed in the “Hash” value of the document, which is also a way to guarantee the integrity of the signed document after the advanced signature has been carried out. And the signer can be associated in various ways, with biometrics in the case of non-certificate-based signatures, or with the mathematical operation of the hash with the signer’s private key if a certificate-based signature is applied.

Certificate-based signing uses public key cryptography, also called asymmetric cryptography.

In asymmetric cryptography there are 2 keys that are mathematically linked to each other:

1. Private Key
2. Public Key

What is encrypted with the private key can only be decrypted with the public key, and vice versa.

Hash functions are unidirectional and generate a short string of characters from a document or a long string of characters.

A possible simile would be a sum value: if we transform each character in a string into a number (for example, its ASCII value) and add the values ​​of all the characters in the string, the resulting value depends on the content of the string. IF you change a character, the sum changes. The algorithms used in cryptography are more elaborate so that modifications to the strings that result in the same hash value cannot be made, which will allow the contents to be changed. Therefore, the sum value, although it serves to explain the hash, is not in itself a good hashing method.

Given a document and its “hash”, it is possible to check if the hash truly corresponds to that document. However, from the hash it is not possible to deduce the document from which it came. There could be infinities. When two different documents produce the same hash value when calculating with a certain algorithm, a “collision” is said to have occurred.

How does an electronic signature work?

The document to be signed is hashed with a specific algorithm (for example, SHA-256) and the result obtained is mathematically operated with an asymmetric signature function (for example, RSA or ECC) with the private key of the signer (normally the private key resides in a chip card or a cryptographic token, and does not leave it, so the hash is sent to the chip and it is the chip that performs the cryptographic operation). The signature is made up of the result of that operation on the chip (which is sometimes called a PKCS # 1 value), and the signer’s certificate containing their data and the public key cryptographically related to the private one.

If the document and the signature are sent to the recipient (sometimes, the document format used allows the signature to be embedded inside, as is the case with PDF files). It can do the equivalent process in reverse to verify the signature.

Extracts the public key from the certificate, thereby applying the cryptographic function to the PKCS # 1 value from which the Hash value is extracted. Calculates the Hash value of the document and compares it with the value obtained from decrypting the PKCS # 1 signature. Both must be the same. If they are not the same there is a problem somewhere. For example, the document has changed in transmission or has been tampered with.

Therefore, an important effect of the electronic signature is that it guarantees the integrity and inalterability of the electronically signed documents.

The certificate used to sign is issued by a “certification authority” or a “trust service provider”. The issuance of electronic certificates is one of the possible trust services ”and, therefore, a“ certification authority ”is a“ trust service provider entity.

These entities verify the identity of the certificate applicants and after that they issue them an electronic certificate associating the public key of the certificate with a private key that must be secretly guarded by the certificate holder with maximum security.

The Electronic Certificate

The electronic certificates of a natural or legal person are electronic documents that contain information about the issuer, the period of validity of the certificate, the identity of the signer, …

The important thing is that this certificate links the public key with the identity of a specific person and that it is signed by the certification body, which has verified the applicant’s identity documents and their correspondence with the applicant’s characteristics. When the certificate is issued, its link with the private key is also established under the exclusive control of the signer.

Although unqualified certification authorities can issue certificates, in Europe qualified certification bodies, which issue qualified certificates, are preferred .

In Spain there are a significant number of qualified certificate issuing entities , among which we can mention Camerfirma, EADTrust, FNMT (CERES), Ivnosys or Vintegris.

In certain signature modalities (such as AdES – T or long-lived signatures) it is convenient to include information about the moment when the signature was created, which it does by adding a time stamp. Time stamps are issued by the Time Stamp Authority (TSA).

The timestamp shows that a certain combination of data existed before a given time and that none of this data has been modified since then.

In short, for the certified digitization of documents, an electronic certificate is needed with which to make the electronic signature on each of the scanned documents.

This requirement and the guarantee of integrity of the database in which the keeping of the invoice digitization process is managed are the most relevant to pass the audit that allows requesting the approval of the software from the AEAT.

Certified Digitization in the field of Justice.

Within the framework of the Lexnet regulations, the GIS for Certified Digitization has been defined by the CTEAJE (State Technical Committee of the Electronic Judicial Administration).

This standard allows any document to be digitized for presentation in legal proceedings, so it has a special value:

  • It is used in the private sector to digitize any document, not just invoices
  • It allows you to have digitized documents in case they are needed at any given time for a trial. This used to be the main reason for keeping paper documents: in case they were needed in court.

The requirements for certified digitization in the field of justice are very similar to those required in the tax field:

  • Electronic signature of scanned documents
  • Protection of the integrity and inalterability of the digitization record database

How do I start a certified digitization process?

To carry out the certified digitization of invoices in a company, it is necessary to have a software approved by the AEAT or by any of the foral estates of Alava, Guipuzcoa, Navarra or Vizcaya.

In order for the software to be able to carry out an electronic signature on each scanned invoice, it must be equipped with a qualified certificate. The current trend is to equip the software with a qualified legal entity certificate, in which case the resulting electronic signatures are called “qualified electronic seals” if they are managed in a device called “Qualified Seal Creation Device” (equipment that is also called HSM “Hardware Security Module”).

It is possible to carry out “certified digitization” or “guaranteed digitization” processes in the context of public administration, for which several of the Technical Interoperability Standards apply . In particular, that of authentic copy, that of digitization, that of signature policy and that of electronic document.

The ValidE portal provides some tools to validate electronic signatures and certificates. The EADTrust DSS tool also provides a lot of information about the certificates and signatures of electronic documents, whether or not they are the result of certified digitization.

Perhaps someone asked this question: is it necessary to start from the printed invoice document to be able to scan it in a certified digitization process or can an invoice received in pdf format be electronically signed?

The answer is given by ORDER EHA / 962/2007, of April 10, which develops certain provisions on telematic invoicing and electronic conservation of invoices in the different articles of which it consists.

Certified scanning can only be done from paper documents.

However, considering that the issuer and receiver can reach an agreement that the issuer of the invoice acts by sending “pre-invoices” in PDF format to the receiver and that the receiver converts them into electronic self-invoices by adding the electronic signature, the fundamental requirement of the electronic invoice, which is your electronic signature. The regulations allow invoices to be managed by the recipient (self-invoice) or a third party on behalf of the invoice issuer, who is usually the one who adds the electronic signatures or electronic stamps.

What to do if the device containing the electronic certificate is lost or stolen

In case of loss or theft of the device in which the private key associated with the electronic certificate is housed, it is necessary to request the revocation of the certificate by going to a Registration Authority of the Certification Authority that issued the certificate. Some certification authorities offer the possibility of remote revocation, using codes that were provided at the time the certificate was issued.

For example, EADTrust has a specific page and a form to request the revocation of the certificate .

Outsourcing of certified digitization processes

When a process is not focused on the core business of a company but can pose a significant administrative burden due to its volume, many entities resort to business process outsourcing (BPO).

A Certified Digitization service performed by third parties or a Remote Electronic Seal service managed by a qualified digital trust service provider can help in these cases.

Article 7 of Order EHA / 962/2007 indicates:

“This digitization process must meet the following requirements:

a) That the digitization process be carried out by the taxpayer himself or by a third party provider of digitization services , in the name and on his behalf, using in both cases software of certified digitization (…)
b) That the digitization process used guarantees the obtaining of a faithful and complete image of each digitized document and that this digital image is signed with an electronic signature in the terms of the previous articles of this Order based on an electronic certificate installed in the scanning system and invoked by the certified scanning software.This certificate must correspond to the taxpayer when the certified digitization is carried out by himself or to the digitization service provider in another case.

Advantages of Certified Digitisation

These are some of the advantages of Certified Digitisation:

  • Saving time in the search for documents, since, as they are documents in electronic format, searches can be generated by keywords.
  • Increase the efficiency and productivity of employees by saving time in filing and searching invoicess, reducing errors.
  • Frequently digitization allows incorporating the information of the invoices in the accounting or ERP system.
  • By having digital documents managed by computer software and stored in a secure repository, decision-making is streamlined by being certain that all the information is available.
  • Saves storage space by not having to guard paper documents and saves other costs related to archival material
  • It facilitates the adoption of repetitive procedures with the environment and, indirectly, helps to pass a possible ISO 14.001 type audit

Give us a call

You can contact EADTrust by calling +34 917 160 555 if you need help to homologate a certified digitization software to be approved by Spanish Tax Agency or if you need electronic certificates to be used in Spain or Europe.

Los certificados DSC de España con los que se firman los pasaportes COVID


Algunos paises europeos han publicado la información de los certificados electrónicos ECC (y unos pocos RSA) con los que se firman los pasaportes COVID (oficialmente “Certificados Digitales COVID” y anteriormente “Certificados verdes digitales”). Estos certificados se denominan DSC (Document Signing Certificate). Ya lo mencioné en el artículo “Public Key of Spain CSCA for European digital COVID certificate“.

Uno de los países que publican la información de dichos certificados electrónicos es Suecia, que hace referencia a los certificados incluidos en la pasarela de validación de confianza de pasaportes COVID (Técnicamente “Digital Green Certificate Gateway” DGCG).

En España, todos los certificados menos uno los ha expedido EADTrust (European Agency of Digital Trust), por lo que la Sub-CA de certificados de curva elíptica P-256 para sello de órgano de EADTrust se ha convertido en la principal CSCA (Certificate Signing Certificate Authority de España. Otra singularidad del sistema adoptado en España es que los DSC emitidos por EADTrust son, además, certificados cualificados de sello de órgano según el Reglamento EIDAS.

Estos son los datos principales de certificados de CSCA y DSC de España:

Country: ES
TypeNameContactPurpose
CSCA CertificateOU=Legal Person, OID.2.5.4.97=VATES-B85626240, C=ES, O=”European Agency of Digital Trust, S.L.”, CN=EADTrust ECC 256 SubCA For Qualified Certificates 2019ca@eadtrust.eu
CSCA CertificateCN=iCA Izenpe, OU=Peer, O=IZENPE S.A., C=ES
Document SignerC=ES, O=SERVICIO DE SALUD DE LAS ISLAS BALEARES, OID.2.5.4.97=VATES-Q0719003F, OU=SELLO ELECTRONICO, SERIALNUMBER=Q0719003F, CN=IBSALUT-CVD-SELLO1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=Servicio Extremeño de Salud, OID.2.5.4.97=VATES-Q0600413I, OU=SSII, OU=SELLO ELECTRONICO, SERIALNUMBER=Q0600413I, CN=Servicio Extremeño de Salud1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=GERENCIA REGIONAL DE SALUD DE CASTILLA Y LEON, OID.2.5.4.97=VATES- Q4700608E, OU=GERENCIA REGIONAL DE SALUD DE CASTILLA Y LEON, OU=SELLO ELECTRONICO, SERIALNUMBER=Q4700608E, CN=GERENCIA REGIONAL DE SALUD CASTILLA Y LEÓN (SACYL)1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=”DIRECCION GENERAL DE SALUD PUBLICA, CONSUMO Y CUIDADOS”, OID.2.5.4.97=VATES-S2633001I, OU=”DIRECCIÓN GENERAL DE SALUD PUBLICA, CONSUMO Y CUIDADOS”, OU=SELLO ELECTRONICO, SERIALNUMBER=S2633001I, CN=Gobierno de La Rioja1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=Servicio Canario de la Salud, OID.2.5.4.97=VATES-Q8555011I, OU=Secretaría General del Servicio Canario de la Salud, OU=SELLO ELECTRONICO, SERIALNUMBER=Q8555011I, CN=Secretaría General del Servicio Canario de la Salud1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=CIUDAD AUTÓNOMA DE MELILLA, OID.2.5.4.97=VATES-S7900010E, OU=DIRECCIÓN GENERAL DE LA SOCIEDAD DE LA INFORMACIÓN, OU=SELLO ELECTRONICO, SERIALNUMBER=S7900010E, CN=SELLO ELECTRONICO DE LA CIUDAD AUTÓNOMA DE MELILLA1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=SERVICIO ANDALUZ DE SALUD, OID.2.5.4.97=VATES-Q9150013B, OU=SERVICIO ANDALUZ DE SALUD, OU=SELLO ELECTRONICO, SERIALNUMBER=Q9150013B, CN=SELLO SAS PARA CERTIFICADO COVID DE LA UE1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerCN=DIRECCIÓN DE SALUD PÚBLICA Y ADICCIONES, OID.2.5.4.97=VATES-S4833001C, OU=SELLO ELECTRONICO, O=EUSKO JAURLARITZA – GOBIERNO VASCO, C=ES1.3.6.1.5.5.7.3.2
Document SignerC=ES, O=Servicio Cántabro de Salud, OID.2.5.4.97=VATES-Q3900738J, OU=SELLO ELECTRONICO, SERIALNUMBER=Q3900738J, CN=Servicio Cántabro de Salud1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=Servicio de Salud de Castilla-La Mancha, OID.2.5.4.97=VATES- Q4500146H, OU=SELLO ELECTRONICO, SERIALNUMBER=Q4500146H, CN=SESCAM Certificado Digital COVID UE1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=Ministerio de Defensa, OID.2.5.4.97=VATES-S2830001J, OU=Inspección General de Sanidad de la Defensa, OU=SELLO ELECTRONICO, SERIALNUMBER=S2830001J, CN=Inspección General de Sanidad de la Defensa1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=Principado de Asturias, OID.2.5.4.97=VATES- S3333001J, OU=SELLO ELECTRONICO, SERIALNUMBER=S3333001J, CN=Consejería de Salud del Principado de Asturias1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=Servicio Navarro de Salud-Osasunbidea, OID.2.5.4.97=VATES-Q3150004D, OU=Servicio Navarro de Salud-Osasunbidea, OU=SELLO ELECTRONICO, SERIALNUMBER=Q3150004D, CN=Sello Electrónico del Servicio Navarro de Salud-Osasunbidea1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=CIUDAD AUTONOMA DE CEUTA, OID.2.5.4.97=VATES-S6100007A, OU=CIUDAD AUTONOMA DE CEUTA, OU=SELLO ELECTRONICO, SERIALNUMBER=S6100007A, CN=CEUTA1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=GENERALITAT VALENCIANA, OID.2.5.4.97=VATES-S4611001A, OU=CONSELLERIA DE SANITAT UNIVERSAL I SALUT PÚBLICA, OU=SELLO ELECTRONICO, SERIALNUMBER=S4611001A, CN=GENERALITAT VALENCIANA1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=Departament de Salut de la Generalitat de Catalunya, OID.2.5.4.97=VATES-S0811001G, OU=Departament de Salut, OU=SELLO ELECTRONICO, SERIALNUMBER=S0811001G, CN=CERT-GENCAT-1S-211.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=COMUNIDAD AUTONOMA DE LA REGION DE MURCIA, OID.2.5.4.97=VATES- S3011001l, OU=DIRECCION GENERAL INFORMATICA CORPORATIVA, OU=SELLO ELECTRONICO, SERIALNUMBER=S3011001l, CN=DIRECCIÓN GENERAL DE SALUD PÚBLICA Y ADICCIONES1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=MINISTERIO DE SANIDAD, OID.2.5.4.97=VATES-S2827001E, OU=SELLO MINISTERIO DE SANIDAD CERTIFICACION COVID19, OU=SELLO ELECTRONICO, SERIALNUMBER=S2827001E, CN=SELLO MINISTERIO DE SANIDAD CERTIFICACION COVID191.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=GOBIERNO DE ARAGON, OID.2.5.4.97=VATES-S5011001D, OU=DEPARTAMENTO DE SANIDAD, OU=SELLO ELECTRONICO, SERIALNUMBER=S5011001D, CN=DEPARTAMENTO DE SANIDAD DEL GOBIERNO DE ARAGON1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=SERVICIO MADRILEÑO DE SALUD, OID.2.5.4.97=VATES-Q2801221I, OU=DG SISTEMAS DE INFORMACION Y EQUIPAMIENTOS SANITARIOS, OU=SELLO ELECTRONICO, SERIALNUMBER=Q2801221I, CN=FIRMA CERTIFICADO COVID DIGITAL UE 11.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=Consellería de Sanidad, OID.2.5.4.97=VATES-S1511001H, OU=SELLO ELECTRONICO, SERIALNUMBER=S1511001H, CN=ConselleriadeSanidade.XuntadeGalicia1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4

Compatibilidad con EIDAS de proyectos de blockchain. Criptografía.


EADTrust está emitiendo certificados cualificados de persona física y persona física para su integración en proyectos de blockchain, lo que permitirá comprobar la viabilidad de los sistemas de identidad digital basados en carteras virtuales (User-centric Identity, denominación que sustitute a Self-sovereign Identity).

Un reto del proyecto es la selección del marco de algoritmos criptográficos que se usarán.

Aunque hay razones técnicas para adoptar el esquema de firma digital “Edwards-curve Digital Signature Algorithm (EdDSA)” (denominacion Ed25519) o la variante de “Elliptic Curve Digital Signature Algorithm (ECDSA) denominada secp256k1 y en algunos proyectos de Blockchain se ha elegido alguno de dichos algoritmos (o variantes con diferentes tamaños de clave), en las discusiones técnicas del equipo del Prestador de Servicios de Confianza indicado, finalmente se ha decidido optar por “Elliptic Curve Digital Signature Algorithm (ECDSA) en linea con las recomendaciones de la norma ETSI TS 119 312 V1.3.1. En concreto, la variante P256 (además de esta denominacion, P-256, tiene además otros nombres prime256v1 o sec256r1).

Dibujo de Carl Mehner sobre la curva P-256 usado en su blog https://www.cem.me/20170410-ecc-1.html

EADtrust ha sido la primera autoridad de certificación en emitir certificados basados en criptografía de curva elíptica y una de las pocas que lo hacen en el mundo. En el contexto de EIDAS (Reglamento UE 910/2014), emite certificados cualificados de persona física y de persona jurídica basados en el algoritmo ECDSA , con las variantes P-256 y P-384.

La compatibilidad con despliegues de infraestructura ya existentes en EIDAS es la que hace recomendable el uso de estos mismos algoritmos en proyectos con Blockchain, especialmente en las fases iniciales del proyecto en las que todavía no se han creado dependencias con decisiones de diseño para las que exista ya un histórico de bloques minados.

Digitalización Certificada, ¿qué es y para qué sirve?


Software homologado

Digitalización Certificada, Factura Electrónica, Firma Electrónica, Certificado Electrónico. Todos estos conceptos están relacionados.

En el desarrollo de la normativa de facturación electrónica, la ORDEN EHA/962/2007, de 10 de abril, por la que se desarrollan determinadas disposiciones sobre facturación telemática y conservación electrónica de facturas ha definido el concepto de Digitalización Certificada. Este blog ha sido pionero al tratar sobre la Digitalización Certificada desde 2006.

El procedimiento de homologación se ha recogido en la resolución de 24 de octubre de 2007, de la Agencia Estatal de Administración Tributaria, sobre procedimiento para la homologación de software de digitalización contemplado en la Orden EHA/962/2007, de 10 de abril de 2007.

En sentido estricto la digitalización certificada se definió para los procedimientos del ámbito tributario por lo quedaría fuera de la cobertura de la Ley 39/2015, según determina la Disposición adicional primera relativa a la Especialidades por razón de materia. Sin embargo la implantación del concepto y el gran número de aplicaciones disponibles, lo convierten en estándar de facto, tambien para el sector público.

La digitalización certificada es el proceso de conversión de documentos en papel a documentos electrónicos que contienen su reproducción facsimilar y que están firmados electrónicamente. Los sistemas que gestionan la digitalización deben cumplir ciertos criterios de integridad e inalterabilidad en la base de datos con la que se realiza la llevanza de la digitalización y se requiere que sean auditados. Los documentos digitalizados con este tipo de sistemas tienen el carácter de original, por lo que se puede prescindir de los documentos en papel de los que proceden, por lo que es muy relevante el valor legal de estos procesos y de los documentos a los que dan lugar

La digitalización certificada de facturas ha propiciado el nacimiento del concepto que ahora se usa también en relación con las administraciones públicas y la digitalización de la Justicia.

Para la digitalización certificada de facturas se puede recurrir a las diferentes variantes de software homologado por la Agencia Tributaria que la AEAT publica también en su sitio web. Las diputaciones forales también han publicado normativa equivalente y cuentan con procedimintos de homologación semejantes a los de la Agencia Tributaria y con sus propias listas de software homologado.

Firma Electrónica

La firma electrónica se regula en el Reglamento UE 910 / 2014 que se denomina abreviadamente “EIDAS”.

La firma electrónica avanzada está vinculada al firmante de manera única; permite la identificación del firmante; se crea utilizando datos de creación de la firma electrónica que el firmante puede utilizar, con un alto nivel de confianza, bajo su control exclusivo, y está vinculada con los datos firmados por la misma de modo tal que cualquier modificación ulterior de los mismos sea detectable.

De forma resumida, la firma avanzada vincula al firmante con lo firmado.

Lo firmado muchas veces de condensa en el valor “Hash” del documento, lo que también es una forma de garantizar la integridad del documento firmado tras la realización de la firma avanzada. Y el firmante se puede asociar de varias formas, con biometría en caso de firmas no basadas en certificados, o con la operación matemática del hash con la clave privada del firmante si se aplica una firma basada en certificado.

La firma basada en certificados usa criptografía de clave pública, también llamada criptografía asimétrica.

En la criptografía asimétrica intervienen 2 claves vinculadas matemáticamente entre sí:

1.    Clave Privada
2.    Clave Pública

Lo que se cifre con la clave privada, sólo puede descifrarse con la clave pública, y viceversa.

Las funciones hash son unidireccionales y generan una ristra corta de caracteres a partir de un documento o de una ristra larga de caracteres.

Un posible simil sería un valor suma: si cada caracter de una ristra lo transformamos en un número (por ejemplo, su valor ASCII) y sumamos los valores de todos los caracteres de la ristra, el valor resultante depende del contenido de la ristra. SI cambia un carácter, la suma cambia. Los algoritmos utilizados en criptográfia son más elaborados para que no se puedan realizar modificaciones a las ristras que den como resultado el mismo valor de hash, lo que permitirá cambiar los contenidos. Por eso, el valor suma, aunque sirve para explicar el hash, no es en sí un buen método de hash.

Dado un documento y su “hash”, es posible comprobar si el hash corresponde verdaderamente a ese documento. No obstante, a partir del hash no es posible deducir el documento del que procede. Podría haber infinitos. Cuando dos documentos diferentes producen el mismo valor de hash al realizar su cálculo con un determinado algoritmo, se dice que se ha producido una “colisión”.

¿Cómo funciona la firma electrónica?

Al documento que se va a firmar se le aplica la función hash con un algoritmo concreto (por ejemplo, SHA-256) y el resultado obtenido se opera matemáticamente con una función de firma asimétrica (por ejemplo, RSA o ECC) con la clave privada del firmante (normalmente la clave privada reside en una tarjeta chipo o un token criptográfico, y no sale de el, por lo que el hash se envía al chip y es el chip el que realiza la operación criptográfica). La firma se compone del resultado de esa operación en el chip (lo que en ocasiones se llama valor PKCS#1), y el certificado del firmante que contiene sus datos y la clave pública relacionada criptograficamente con la privada.

Si se hace llegar el documento y la firma al destinatario (a veces, el formato de documento utilizado permite embeber la firma en su interior, como es el caso de los ficheros PDF)¡. Este puede realizar el proceso equivalente en sentido contrario para comprobar la firma.

Extrae la clave pública del certificado, con lo que puede aplicar la función criptográfica al valor PKCS#1 del que se extrae el valor Hash. Calcula el valor Hash del documento y lo compara con el valor obtenido de descifrar la firma PKCS#1. Ambos deben ser iguales. Si no son iguales hay un problema en algún lado. Por ejemplo, el documento ha cambiado en la transmisión o se ha manipulado.

Por eso un importante efecto de la firma electrónica es que garantiza la integridad e inalterabilidad de los documentos firmados electrónicamente.

El certificado utilizado para firmar lo expide una “autoridad de certificación” o una “entidad prestadora de servicios de confianza”. La expedición de certificados electrónicos es uno de los posibles servicios de confianza” y, por ello, una “autoridad de certificación” es una “entidad prestadora de servicios de confianza.

Estas entidades comprueban la identidad de los solicitantes de certificados y tras ello les expiden un certificado electrónico asociando la clave pública del certificado con una clave privada que debe custodiar de forma secreta el titular del certificado con la máxima seguridad.

El Certificado Electrónico

Los certificados electrónicos de persona física o jurídica son unos documentos electrónicos que contienen información del emisor, el periodo de validez del certificado, la identidad del firmante,…

Lo importante es que este certificado vincula la clave pública con la identidad de una persona concreta y que está firmado por la entidad de certificación, que ha comprobado los documentos de identidad del solicitante y su correspondencia con los rasgos del solicitante. Al expedir el certificado se establece también su vinculación con la clave privada bajo control exclusivo del firmante.

Aunque pueden emitir certificados autoridades de certificación no cualifiadas, en Europa se prefieren las entidades de certificación cualificadas, que emiten certificados cualificados.

En España existe un importante número de entidades emisoras de certificados cualificados, de entre los que cabe citar a Camerfirma, EADTrust, FNMT (CERES), Ivnosys o Vintegris.

En determinadas modalidades de firma (como la AdES – T o las firmas longevas) es conveniente incluir información sobre el momento en que se creó la firma, lo que realiza añadiendo un sello de tiempo. Los sellos de tiempo los expiden las Autoridades de Sellado de Tiempo (TSA – Time Stamp Authority).

El sello de tiempo demuestra que cierta combinación de datos existió antes de un momento dado y que ninguno de estos datos ha sido modificado desde entonces.

Resumiendo, para la digitalización certificada de documentos, se necesita un certificado electrónico con el que realizar la firma electrónica sobre cada uno de los documentos escaneados.

Este requisito y la garantía de integridad de la base de datos en la que se gestiona la llevanza del proceso de digitalización de facturas son los más relevantes para superar la auditoría que permite solicitar la homologación del software a la AEAT.

Digitalización Certificada en el ámbito de la Justicia.

En el marco de la normativa Lexnet se ha definido por el CTEAJE (Comité Tecnico Estatal de la Administración Judicial Electrónica) la GIS de Digitalización Certificada.

Esta norma permite digitalizar cualquier documento para su presentación en procesos judiciales por lo que tiene un valor especial:

  • Sirve en el sector privado para digitalizar cualquier documento, no solo facturas
  • Permite tener documentos digitalizados por si en un momento dado hacen falta para un jucio. Esta solía ser la principal razón para custodiar documentos en papel: por si hacían falta en un juicio.

Los requisitos de digitalización certificada en el ámbito de la justicia son muy parecidos a los exigidos en el ámbito tributario:

  • Firma electrónica de los documentos escaneados
  • Protección de la integridad e inalterabilidad de la base de datos de llevanza de la digitalización

¿Cómo pongo en marcha un proceso de digitalización certificada?

Para llevar a cabo la digitalización certificada de facturases en una empresa es necesario contar con un software homologado por la AEAT o por cualquera de las haciendas forales de Alava, Guipuzcoa, Navarra o Vizcaya.

Para que el software pueda realizar una firma electrónica en cada factura escaneada, hace falta equiparlo con un certificado cualificado. La tendencia actual es equipar el software con certificado cualificado de persona jurídica, en cuyo caso las firmas electrónicas resultantes se denominan “sellos electrónicos cualificados” si se gestionan en un equipo denominado “Dispositivo Cualificado de Creación de Sello” (equipos que también se denomina HSM “Hardware Security Module”).

Cabe la posibilidad de realizar procesos de “digitalización certificada” o “digitalización garantizada” en el contexto de la administración pública, para lo que seaplican varias de las Normas Técnicas de Interoperabilidad. En particular la de copia auténica, la de digitalización, la de política de firma y la de documento electrónico.

El portal ValidaE facilita algunas herramientas para validar firmas y certificados electrónicos. También la herramienta DSS de EADTrust proporciona mucha información sobre los certificados y las firmas de los documentos electrónicos, sean o no resultado de la una digitalización certificada.

Tal vez alguien se hizo esta pregunta: ¿es necesario partir del documento de la factura impreso para poder escanearlo en un proceso de digitalización certificada o se puede firmar electrónicamente una factura recibida en formato pdf?

La respuesta la da la ORDEN EHA/962/2007, de 10 de abril, por la que se desarrollan determinadas disposiciones sobre facturación telemática y conservación electrónica de facturas en los diferentes artículos de los que consta.

La digitalización certificada solo se puede hacer desde documentos en soporte papel.

No obstante, considerando que el emisor y el receptor pueden llegar al acuerdo de que el emisor de la factura actua enviando “prefacturas” en formato PDF al receptor y que este las convierte en autofacturas electrónicas añadiendo la firma electrónica, se cumple el requisito fundamental de la factura electrónica, que es su firma electrónica. La normativa permite que las facturas las gestione el destinatario (autofactura) o un tercero en nombre del emisor de la factura, que suele ser el que añade las firmas electrónicas o los sellos electrónicos.

Qué hacer si se pierde o alguien sustrae el dispositivo donde reside el certificado electrónico

En caso de pérdida o robo del dispositivo en el que se aloja la clave privada asociada al certificado electrónico, hay que solicitar la revocación del certificado personándose ante una Autoridad de Registo de la Autoridad de Certificación que expidió el certificado. Algunas autoridades de certificación ofrecen la posibilidad de realizar la revocación a distancia, empleando códigos que se entregaron en el momento de la expedición del certificado.

Por ejemplo, EADTrust dispone de una página específica y un formulario para solicitar la revocación del certificado.

Externalización de procesos de digitalización certificada

Cuando un proceso no está centrado en el núcleo de negocio de una empresa pero puede suponer una carga administrativa importante por su volumen, muchas entidades recurren a la externalización de procesos de negocio (BPO).

Un servicio de Digitalización Certificada realizado por terceros o un servicio de Sello electrónico remoto gestionado por un prestador de servicios de confianza digital cualificado pueden ayudar en estos casos.

El artículo 7 de la Orden EHA/962/2007 indica:

“Este proceso de digitalización deberá cumplir los siguientes requisitos:

a) Que el proceso de digitalización sea realizado por el propio obligado tributario o bien por un tercero prestador de servicios de digitalización, en nombre y por cuenta de aquel, utilizando en ambos casos un software de digitalización certificado (…)
b) Que el proceso de digitalización utilizado garantice la obtención de una imagen fiel e íntegra de cada documento digitalizado y que esta imagen digital sea firmada con firma electrónica en los términos de los artículos anteriores de esta Orden en base a un certificado electrónico instalado en el sistema de digitalización e invocado por el software de digitalización certificada. Este certificado debe corresponder al obligado tributario cuando la digitalización certificada se realice por el mismo o al prestador de servicios de digitalización en otro caso.

Ventajas de la Digitalización Certificada

Estas son algunas de las ventajas de la Digitalización Certificada:

  • Ahorro de tiempos en la búsqueda de documentos, puesto que, al tratarse de documentos en formato electrónico, se pueden generar búsquedas por palabras clave.
  • Aumenta la eficiencia y productividad de los empleados al ganar tiempo en el achivo y en las búsquedas, reduciendo los errores.
  • Frecuentennete la digitalización permite incorpoporar la información de las facturas en el sistema de contabilidad o ERP.
  • Al tener los documentos digitales gestionados por un software informático y custodiados en un repositorio seguro, se agilizan las tomas de decisiones al tener la certeza que se cuenta con toda la información.
  • Se ahorra espacio de almacenamiento al no tener que custodiar los dcumentos en papel y se ahorran otros costes relacionados con el material de archivo
  • Facilita la adopción de procedimientos repetuosos con el medio ambiente e, indirectamente, ayuda a superar una posible auditoría de tipo ISO 14.001

Llámenos

Puede contactar con EADTrust a través de los teléfonos 917160555 y 902 365 612 si necesita ayuda pata homologar una solucuón de digitalización certificada o necesita certificados electrónicos.

New EIDAS Regulation makes clear to web-browsers that they must recognize qualified website authentication certificates


New draft proposal to ammend Regulation (UE) No 910/2014 (EIDAS) replace Article 45 withe the following text:

Requirements for qualified certificates for website authentication

  1. Qualified certificates for website authentication shall meet the requirements laid down in Annex IV. Qualified certificates for website authentication shall be deemed compliant with the requirements laid down in Annex IV where they meet the standards referred to in paragraph 3.
  2. Qualified certificates for website authentication referred to in paragraph 1 shall be recognised by web-browsers. For those purposes web-browsers shall ensure that the identity data provided using any of the methods is displayed in a user friendly manner. Web-browsers shall ensure support and interoperability with qualified certificates for website authentication referred to in paragraph 1, with the exception of enterprises, considered to be microenterprises and small enterprises in accordance with Commission Recommendation 2003/361/EC in the first 5 years of operating as providers of web-browsing services.
  3. Within 12 months of the entering into force of this Regulation, the Commission shall, by means of implementing acts, provide the specifications and reference numbers of standards for qualified certificates for website authentication referred to in paragraph 1.  Those implementing acts shall be adopted in accordance with the examination procedure referred to in Article 48(2).’;

Nuevo DNIe 4.0


El Reglamento UE 2019/1157 del Parlamento Europeo y del Consejo de 20 de junio de 2019, armoniza el aspecto y las medidas de seguridad de los documentos de identidad y de residencia de los ciudadanos de todos los países miembros de la Unión Europea.

Los requisitos técnicos se basan en el documento 9303 de ICAO.

El tamaño de los documentos será el del formato ID-1 de la norma ISO/IEC 7810:2003, correspondiente al tamaño estándar de “tarjeta de crédito” que es de 85,60 × 53,98 mm (3 3⁄8 × 2 1⁄8 pulgadas) y esquinas redondeadas con un radio de entre 2.88 y 3.48 mm.

España ya lleva unos meses desarrollando con las nuevas especificaciones el nuevo documento DNIe 4.0 y el ministro del Interior, Fernando Grande-Marlaska, lo ha presentado oficialmente el 2 de junio de 2021.

El acto de presentación ha sido celebrado en la comisaría de la Policía Nacional de Móstoles y con el ministro han participado el director general de la Policía, Francisco Pardo, y por la delegada del Gobierno en Madrid, Mercedes González, entre otras autoridades.

La actriz Luisa Martín, la inspectora Miralles en la serie televisiva “Servir y proteger”, ha sido la primera persona en recibir el nuevo DNI. 

La Policía Nacional, en un trabajo conjunto con La Fábrica Nacional de Moneda y Timbre – Real Casa de la Moneda, ha diseñado un soporte que incluye características materiales, técnicas, de seguridad, funcionales y de usabilidad alineados con los avances más recientes de seguridad documental.

Entre los cambios introducidos, el nuevo DNI incluye la denominación en inglés “National Identity Card”y en el anverso, el código de dos letras que identifica el Estado miembro.

El nuevo modelo de DNI Europeo se enmarca dentro del Programa de Identidad Digital DNIE de la Policía Nacional. El programa trabaja en el desarrollo de una aplicación de teléfono móvil gratuita que permitirá la acreditación de la identidad y la firma electrónica.

Electronic signatures in EU Digital COVID Certificates, based on qualified certificates issued by #EIDAS Certification Authorities


To configure DGCG (Digital Green Certificate Gateway) in Digital COVID Certificate project, participating countries provide information regarding Public Key of the certificate of CSCA (Certificate Signing Certificate Authority). Spain uses a ECC #eIDAS Sub-CA as CSCA.

CSCA, as defined in the DGC project, requires the CSCA cert to include the country field for which the CSCA is valid. However, #EIDAS certificates are intended for cross-border interoperability, so the country field in the CA cert is irrelevant to countries in which it is valid.

DGC technical documents should be changed so CSCA of one country could be serviced from a CA in other country. So #EIDAS certification authorities could provide DSC certificates to health bodies in any country. The same principle should be extended to WHO technical documents.

Extended key Usage Identifiers could be present with some information in #EIDAS certificates, so the explanation that the DSC may contain an extended key usage extension with zero or more key usage policy identifiers that constrain the types of HCERTs such DSC certificate may sign, should consider other OIDs as “not present” if the eHealth application doesn´t understand them.

If one or more of the special DGC OIDs are present, the verifiers SHALL verify the extended key usage against the stored HCERT.

In absence of any key usage extension of the special DGC OIDs (i.e. no such special DGC OIDs extensions), the related DSC certificate can be used to sign any type of HCERT.

So, in #EIDAS DSC certificates to be used to electronically sign HCERT, the following OIDs can be used in Extended Key Usage extension fields:

  • OID 1.3.6.1.4.1.1847.2021.1.1 — valid for test
  • OID 1.3.6.1.4.1.1847.2021.1.2 — valid for vaccinations
  • OID 1.3.6.1.4.1.1847.2021.1.3 — valid for recovery

This OIDs can be present if the related EU Digital COVID Certificate is restricted to one of two kind of certificates. If all 3 are included (or none of them) the related EU Digital COVID Certificate is NOT restricted and can reflect any of the three options.

Public Key of Spain CSCA for European digital COVID certificate


In order to configure DGCG (Digital Green Certificate Gateway) participating countries need to deliver information regarding CSCA (Certificate Signing Certificate Authority), and specifically Public Key of the certificate of the CA used to sign the DSC (Document Signing Certificate) of every Body in charge of issuing DGC (Digital Green Certificates) . Remember that Health CSCA is different from CSCA used in Passports although both environments use similar terminology.

Trust List managed by Gateway

The ECC p-256 Public Key of Spain CSCA to be used for European Digital Green Certificates is

—–BEGIN PUBLIC KEY—–MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE1rjpdfCTyXE8RdrbW8rbLagURmGQerDBqh0WEaRCaJpqDuqKy0Zs1fXBhSPJQ4334X0TdMAWBIoLnLBC2up9Lg==
—–END PUBLIC KEY—–

Principles regarding validity

  • Rule 0: A certificate needs to be valid when it is used to sign/seal.
  • Rule 1: The DSC needs to be valid longer than anything it signs. So, the DSC expiry date must be >= than expiration date of the document it signs.
  • Rule 2: The CSCA needs to be valid longer than any DSC it signs.
  • Rule 3: If any certificate has a shorter ‘key usage period’ – then the signature has to be created in that period.

More info:

Para más información: +34 91716055

Thales anuncia la certificación EIDAS para firma remota de sus HSM


El Módulo de Seguridad de Hardware (Hardware Security Module, HSM) de Thales denominado Luna v.7.7.0 ya está certificado de acuerdo con los Criterios Comunes (Common Criteria, CC) en el nivel EAL4+ contra el Perfil de Protección (PP) EN 419 221-5 de los Servicios de Identificación, Autenticación y Confianza electrónicos (eIDAS). Además de la certificación CC, Luna HSM 7 también ha recibido la certificación eIDAS como dispositivo cualificado de creación de firmas y sellos (Qualified Signature/Seal Creation Device QSCD).

Los HSM Luna (de las generaciones 6 y 7, anteriormente englobados bajo la marca Safenet) ya habían conseguido certificaciones como QSCD independiente, o como parte de un QSCD de firma remota formado por módulos creados por entidades terceras que los incluían en su configuración. Han certificado su validez entidades de evaluación de conformidad de Austria, Italia y España, según lo previsto en el artículo 30.3.b (Procesos alternativos) del Reglamento EIDAS.

Los prestadores de servicios de confianza cualificados (Qualified Trust Service Providers, QTSP), así como las empresas públicas o privadas que emiten certificados digitales y proporcionan firmas y sellos digitales sobre servidores propios o remotos (avanzados y cualificados), sello de tiempo, entrega electrónica y servicios de autenticación de sitios web, pueden utilizar ahora los HSM Luna 7 como parte de su solución alineada con eIDAS.

Esta certificación CC EAL4+ de la familia de HSMs Luna es la quinta en cuatro generaciones de productos (Luna CA3, Luna 4, Luna 5/6 y ahora Luna 7).

Esta última versión de HSM Luna incluye funciones útiles para operaciones eIDAS de gran volumen, que requieran alto rendimiento, y funcionalidades como la autorización por clave (per-key authorization, PKA) y el almacenamiento escalable de claves (scalable key storage, SKS), funciones utilizadas por los sistemas que gestionan firmas remotas en nombre del titular del certificado.

Los Prestadores de Servicios de Confianza (Trust Service Providers – TSP) que adopten estos HSM de Thales pueden certificar sus soluciones de firma remota conPerfil de Protección Common Criteria EN 419 241-2 (perfil de protección para QSCD diseñado para la modalidad de firma electrónica en servidor), o en el caso de una certificación eIDAS existente (en base al artículo 30.3.b, procesos alternativos), ampliar su lista de certificaciones con esta nueva certificación Common Criteria.

La certificación en base al Perfil de Protección Common Criteria EN 419 221-5 “Cryptographic Modules for Trust Services” (Módulos criptográficos para servicios de confianza) puede utilizarse como certificación independiente o como base para una certificación CC de mayor alcance según el Perfil de Protección EN 419 241-2 para servicios de firma y sellado electrónico remotos. La norma EN 419 241-2 exige el empleo de un módulo criptográfico, como un HSM, destinado a ser utilizado por los TSP en apoyo de las operaciones de firma electrónica y sellado electrónico, que esté certificado conforme a la norma EN 419 221-5.

Además, los artículos 30 y 31 del reglamento eIDAS dictan que “La conformidad de los dispositivos cualificados de creación de firmas electrónicas con los requisitos [de la UE] […] será certificada por los organismos públicos o privados adecuados designados por los Estados miembros”. Luna HSM 7 está publicado en la lista del artículo 31 de eIDAS, promoviendo su uso como QSCD certificado.

El uso de un equipamiento de HSM basado en la nube o en las instalaciones de la entidad que lo adopta es una forma excelente de cumplir con el eIDAS y tiene muchas ventajas, pero se exige que el HSM esté certificado como dispositivo QSCD.

En los entornos de trabajo remotos existe la necesidad de acceder a las claves de firma digital en cualquier momento y lugar. Los HSM se utilizan para gestionar y proteger las claves de firma privadas de sus titulares, sin que el firmante deba preocuparse por su custodia (como ocurre cuando se utilizan tarjetas inteligentes). Sus claves se mantienen en el perímetro del Prestador de Servicios de Confianza (protegidas por el HSM) y con sujeción a la evaluación periódica del prestador.

HSMs Luna

Además de los requisitos a los HSM impuestos por el Reglamento eIDAS mencionados anteriormente, que requieren su evaluación de conformidad, los HSM de red y de tarjeta PCIe de Luna proporcionan altos rendimientos, protección de claves de alto nivel de aseguramiento y la administración y supervisión centralizada de las operaciones de criptografía necesarias para gestionar firmas electrónicas, sellos electrónicos y otros servicios de confianza y resultan necesarios para proporcionar servicios eIDAS.

Noticia comunicada por Thales (artículo de Hermann Bauer) .

ARCE, Archivo de Constancias Electrónicas, un buen ejemplo


Desde hace casi 20 años estoy pendiente del concepto “ARCE, Archivo de Constancias Electrónicas“, acuñado probablemente en el Ministerio de Ciencia y Tecnología en la época de Anna Maria Birulés i Bertran, Josep Piqué Camps o Juan Costa Climent.

La primera mención al “ARCE” en el BOE es de la época en que la denominación del Ministerio era “Ministerio de Industria, Turismo y Comercio”. Se trata de la Orden ITC/1475/2006, de 11 de mayo, sobre utilización del procedimiento electrónico para la compulsa de documentos en el ámbito del Ministerio de Industria, Turismo y Comercio.

Para mi es una de las normas seminales que inauguran de verdad la digitalización de la administración, ya que trata con detalle de la digitalización de los documentos en papel con carácter de auténtico a partir del concepto de “compulsa” por funcionario público. Y el manejo en papel de los documentos de procedencia digital.

El precedente directo era el Artículo 8 (Almacenamiento de documentos) del Real Decreto 263/1996, de 16 de febrero, por el que se regula la utilización de técnicas electrónicas, informáticas y telemáticas por la Administración General del Estado.

En mis cursos y seminarios, especialmente cuando trato de los conceptos de Diplomática Digital, el ARCE lo menciono siempre.

Sin embargo, uno de los retos que encaran las administraciones públicas, especialmente significativo en el caso de la digitalización, es el de construir de cara a los ciudadanos experiencias de usuario consistentes. Y no me quiero quedar con una frase generalista. Me refiero a que cada vez que cambian los nombres de los ministerios con cada gobiero, o se reorganizan las secretarías de estado que pasan de unos ministerios a otros, cambian los dominios internet que hacen referencia a los ministerios con nuevas siglas.

Y un aspecto esencial de la administración como la posibilidad de cotejar un CSV (Código Seguro de Verificación) de un documento electrónico se distorsiona porque el punto de cotejo (la página a la que se accede para comprobar la autenticidad de un documento) puede haber cambiado de nombre y de URL en alguna de las reorganizaciones del gobierno, especialmente tras unas elecciones.

Por eso, desde hace varios años sugiero (lo señalo en mis cursos) que se definan URLs genéricas para el servicio de cotejo, que hagan uso de denominaciones genéricas no vinculadas al nombre del Ministerio ni de la Secretaría de Estado.

Por eso ahora quiero referirme a la URL https://serviciosmin.gob.es/arce/ que en cierto modo implementa esta idea. En el Ministerio de Energía, Turismo y Agenda Digital (vigente desde el 4 de noviembre de 2016 hasta el 7 de junio de 2018) se incluían estas Secretarías de Estado:

  • Secretaría de Estado de Energía.
  • Secretaría de Estado para la Sociedad de la Información y la Agenda Digital.
  • Secretaría de Estado de Turismo

Que quedaron repartidas en varios Ministerios en el gobierno vigente en la actualidad:

  • La Secretaría de Estado de Energía pasó al “Ministerio para la Transición Ecológica y el Reto Demográfico”
  • La Secretaría de Estado para la Sociedad de la Información y la Agenda Digital, pasó a dividirse en 2, la Secretaría de Estado de Telecomunicaciones e Infraestructuras Digitales y la Secretaría de Estado de Digitalización e Inteligencia Artificial, formando ambas parte del Ministerio de Asuntos Económicos y Transformación Digital.
  • La Secretaría de Estado de Turismo se quedó en el “mismo” ministerio, que pasó a llamarse “Ministerio de Industria, Comercio y Turismo”, y que acogió otras secretarías de estado procedentes de otros ministerios.

Por tanto, los servicios informáticos que estaban en un mismo ministerio atendendiendo a varias secretarías de estado, tuvieron que hacer encaje de bolillos para no interrumpir el servicio que ya correspondía a varios ministerios.

Además otros movimientos de secretarías de estado han generado retos similares.

Así que la denominación https://serviciosmin.gob.es/arce/ ya no hace referencia a un Ministerio en particular.

Mi sugerencia es que https://arce.gob.es bien podría ser el punto de cotejo de CSVs de todos los Ministerios, sea cual sea su denominación. Seguro que la adaptación informática no es muy compleja, especialmente si se empiezan a adoptar los Códigos de Verificación Enrutables.