Aunque creo que ya no llego a corregirle alguna cosilla menor a Carlos Astorelli, autor del artículo, le agradezco que haya contado conmigo y con ASIMELEC al hablar de la factura electrónica en Consumer.
Incluso en noticias positivas en relación con el DNI electrónico como esta siempre hay alguien que con la mejor voluntad, lo critica «de oidas».
Que si vamos retrasados, que si otros paises van mejor, que si la seguridad del DNI es mala…
En algunos sitios he visto a «criptógrafos de salón» explicando teorías sobre la robustez del método de HASH para descalificar al DNI electrónico español, que precisamente en eso se pasa de paranoico.
Desde luego, respecto a la gestión de la identidad de los ciudadanos no se puede poner de ejemplo a Estados Unidos porque va claramente por detras de España.
En USA hay estados que se han inventado el «carné de conducir de no conductores» porque no existe un procedimiento general de acreditar la identidad como tenemos en España con el DNI y en casi todos los paises latinoamericanos con la cédula de identidad, o la cédula de votación.
Y en cuanto a las medidas de seguridad, el nuevo DNI español es probablemente el artilugio más seguro del mundo en relación con la acreditación de identidad, de los que caben en un bolsillo.
El DNI español se incardina en las especificaciones Citizen ID del Grupo de Porvoo, es compatible con PKCS#15 y tiene drivers para Windows, Linux y Mac. Tiene una pareja de claves para autenticar el dispositivo y parejas de claves de usuario separadas para FIRMA y AUTENTICACIÓN.
Creo que además, en esto de la certificación digital, España es un país que destaca en Europa, con Prestadores de Servicios de Certificación que cumplen este año su decimo tercer aniversario. Y un censo en el Ministerio de Industria, Comercio y Turismo que contabiliza 12 iniciativas (y alguna más en proceso) .
En fin, no estoy de acuerdo con el sempiterno complejo de inferioridad de los españoles, y menos en estos temas. Y estoy muy orgulloso del DNI electrónico que se ha definido. Y creo que he llegado a profundizar bastante en el tema.
Tras desarrollar el driver del prototipo del DNI electrónico para teléfono móvil en aquel proyecto ya mencionado en este Blog en el que Albalia Interactiva colaboró con Movistar, llegamos a tener un conocimiento bastante profundo de las peculiaridades de la tarjeta chip, gracias, en buena medida, al soporte recibido de la FNMT-RCM, diseñadora del sistema operativo.
Como en aquel proyecto no pudimos usar las librerías criptográficas de Windows CE, llegamos a desarrollar nuestra propia implementación para leer los certificados del sistema de ficheros de la tarjeta y también para generar firmas PKCS#7 usando los servicios de generación de hash de la tarjeta y pidiendo a este dispositivo la firma con la clave privada.
Afortunadamente, tras aquel gran esfuerzo, este conocimiento nos está sirviendo para que nos estén lloviendo estos días propuestas para desarrollar interfaces con el DNI electrónico en los entornos más diversos.
Kioskos de servicios interactivos para eAdministración, Cajeros Automáticos, Terminales Puntos de Venta (EFT-POS o TPV), Tornos de control de entrada, sistemas de control horario, Set Top Boxes (decodificadores) de TDT (Televisión digital terrestre), puestos de oficina bancaria, la lista se amplia cada día.
Incluso estamos valorando la posibilidad de leer el DNI electrónico en una máquina vending para la que solo se desea saber si el usuario es mayor de edad de forma que se pueda permitir la venta de ciertos productos, como el tabaco.
Cuando pueda daros más datos os contaré algunas anécdotas curiosas.
Por cierto, da gusto trabajar con gente como la de C3PO para poder adaptarse a cualquier entorno hardware, gracias a su experiencia en el diseño de lectores de tarjeta chip para el DNI electrónico.
Con frecuencia me toca explicar que existe un repositorio europeo en el que encontrar información de todos los Prestadores de Servicios de Certificación que operan en el marco de la Directiva 1999/93/CE.
Este repositorio es la página web creada a partir de lo prescrito en el artículo 11 de la Directiva y está accesible en esta dirección: http://europa.eu.int/information_society/eeurope/2005/all_about/security/esignatures/index_en.htm
En esta ocasión voy a replicar su contenido (actualizado a 4 de febrero de 2006) y sabiendo que puede cambiar en el futuro.
Por cierto la indicación que se refiere a España está desactualizada. La dirección que funciona hoy (parece que se cambiaron las URL tras comunicarlas al organismo internacional) del repositorio de prestadores del Ministerio de Industria Comercio y Turismo es https://www11.mityc.es/prestadores/busquedaPrestadores.jsp
Notification procedure
Article 11 of Directive 1999/93/CE :
Member States shall notify to the Commission and the other Member States the following :
a) information on national voluntary accreditation schemes, including any additional requirements pursuant to Article 3(7) ;
b) the names and addresses of the national bodies responsible for accreditation and supervision as well as of the bodies referred to in Article 3(4) ;
c) the names and addresses of all accredited national certification service providers.
a) information on national voluntary accreditation schemes, including any additional requirements pursuant to Article 3(7):
Austrian Signature Act (BGBI I 1999/190, amendments: BGBI I 2000/137, BGBI I 2001/32, BGBI I 2001/152, BGBl I 2005/164) – especially § 17, and Austrian Signature Ordinance (BGBI II 2000/30, amendment: BGBl II 2004/527) http://www.signatur.rtr.at/en/legal/
b) the names and addresses of the national bodies responsible for accreditation and supervision as well as of the bodies referred to in Article 3(4):
– Accreditation and supervision body:
Telekom-Control-Kommission
http://www.signatur.rtr.at/en/supervision/index.html
– Bodies referred to in article 3 (4):
Zentrum für sichere Informationtechnologie -Austria (A-SIT)
c) the names and addresses of all accredited national certification service providers:
Notification 1/Notification 2
– A-Trust Gesellschaft für Sicherheitssysteme im elektronischen Datenverkehr GmbH
Landstraßer Hauptstraße 5
A – 1030 Wien
d) additional information:
– Certification Service Providers established in Austria delivering qualified certificates to the public:
A-Trust Gesellschaft für Sicherheitssysteme im elektronischen Datenverkehr GmbH
Landstraßer Hauptstraße 5
A – 1030 Wien
– Certification Service Providers established in Austria delivering non qualified certificates to the public:
Please see the list under http://www.signatur.rtr.at/en/providers/providers.html
a) information on national voluntary accreditation schemes, including any additional requirements pursuant to Article 3(7):
None
b) the names and addresses of the national bodies responsible for accreditation and supervision as well as of the bodies referred to in Article 3(4):
-Accreditation and supervision body:
Electronic Signature Service
Accreditation Division
FPS Economy, SMEs, Self-employed and Energy
World Trade Centre III
Simon Bolivarlaan 30
1000 BRUXELLES
Tel: 00 32 2 208 36 42
Fax: 00 32 0 208 36 55
Email: Electronic Signature Service: be.sign@mineco.fgov.be
Website: http://www.mineco.fgov.be
c) the names and addresses of all accredited national certification service providers:
–
d) additional information:
– Certification Service Providers established in Belgium delivering qualified certificates to the public:
– Citizen CA
– E-Trust
cfr: http://www.mineco.fgov.be/information_society/e-signatures/list_e_signature_nl.pdf
– Certification Service Providers established in Belgium delivering non qualified certificates to the public:
The Belgian legislation only requires a registration of CSP’s issuing QC’s, so we have no data on NQC’s.
a) information on national voluntary accreditation schemes, including any additional requirements pursuant to Article 3(7):
Accreditation scheme in the Czech Republic is defined in the Act on Electronic Signatures, 227/2000 Coll. It is available at http://www.micr.cz/scripts/detail.php?id=1542
b) the names and addresses of the national bodies responsible for accreditation and supervision as well as of the bodies referred to in Article 3(4):
– Accreditation and supervision body:
Ministerstvo informatiky/Ministry of Informatics
Havelkova 2; 130 00 Praha 3; Czech Republic
Email: posta@micr.cz
Website: http://www.micr.cz
– Body referred to in art 3 (4):
None
c) the names and addresses of all accredited national certification service providers:
První certifikační autorita, a. s.,
Podvinný mlýn 2178/6; 190 00 Praha 9; Czech Republic
Website: http://www.ica.cz
Česká pošta, s. p.,
Olšanská 38/9; 225 99 Praha 3; Czech Republic
Website: http://qca.postsignum.cz
eIdentity a. s.,
Vinohradská 184/2396; 130 00 Praha 3; Czech Republic
Website: http://www.ie.cz
d) additional information:
– Certification Service Providers established in Czech republic delivering qualified certificates to the public:
První certifikační autorita, a. s.,
Podvinný mlýn 2178/6; 190 00 Praha 9; Czech Republic
Website: http://www.ica.cz
Česká pošta, s. p.,
Olšanská 38/9; 225 99 Praha 3; Czech Republic
Website: http://qca.postsignum.cz
eIdentity a. s.,
Vinohradská 184/2396; 130 00 Praha 3; Czech Republic
Website: http://www.ie.cz
– Certification Service Providers established in Czech republic delivering non qualified certificates to the public:
Those Certification service providers (CSP) aren’t obliged to notify us, that they issue certificates, so this is not 100% complete. All CSP’s issuing qualified certificates issue also non qualified certificates.
AEC, spol. s r.o., http://www.aec.cz , http://www.trustport.cz/
Zoner software, s.r.o., http://www.zoner.cz, http://www.caczechia.cz/
CESNET, z. s. p. o., http://www.cesnet.cz/cesnet-ca/
There is many CSP’s issuing non qualified certificates for their organization or their clients. Those are banks, universities, public administration institutions (e.g. ministries), telecommunication companies (e.g. Český Telecom, a.s.), internet service providers, etc
a) information on national voluntary accreditation schemes, including any additional requirements pursuant to Article 3(7):
Denmark has no voluntary accreditation schemes
Denmark has no additional requirements at the present moment.
b) the names and addresses of the national bodies responsible for accreditation and supervision as well as of the bodies referred to in Article 3(4):
– Supervision Body:
The National IT and Telecom Agency
Holsteinsgade
632100 København
ØDK
– Body referred to in art 3 (4):
None
c) the names and addresses of all accredited national certification service providers:
–
d) additional information:
– Certification Service Providers established in Denmark delivering qualified certificates to the public:
None
– Certification Service Providers established in Denmark delivering non qualified certificates to the public:
TDC Certificeringscenter
Slet Parkvej 1-7
8310 Tranbjerg J.
DK
VeriSign Denmark ApS
Sikkerhedstjenester
Poppelgårdvej 11 – 13
DK-2860 Søborg
a) information on national voluntary accreditation schemes, including any additional requirements pursuant to Article 3(7):
There are no voluntary accreditation schemes and no additional requirements pursuant to Article 3(7) in Finland.
b) the names and addresses of the national bodies responsible for accreditation and supervision as well as of the bodies referred to in Article 3(4):
– Accreditation body:
None
– Supervision body:
According to Section 22 (General Guidance and Supervision) of the Act on Electronic Signatures (14/2003)(in force February, 2003) the Finnish Communications Regulatory Authority shall be in charge of supervision in compliance with the Act on Electronic Signatures. The Data Protection Ombudsman shall supervise the compliance with the provisions of the Act on Electronic Signatures concerning personal data. Please find an unofficial translation of the Act on:
http://www.finlex.fi/en/laki/kaannokset/2003/en20030013
Finnish Communications Regulatory Authority (FICORA)
P.O.Box 313
FIN-00180 Helsinki
FINLAND
Tel: +359 9 69 661
Fax: +358 9 9699 410
URL: www.ficora.fi/englanti/index.html
Data Protection Ombudsman
P.O. Box 315
FIN-00180 Helsinki
FINLAND
Tel: +358 9 259 8771
Fax: +358 9 259 87735
URL: www.tietosuoja.fi/1560.htm
– Bodies referred to in Article 3(4):
None
c) the names and addresses of all accredited national certification service providers:
Population Register Centre
P.O.Box 70
FIN-00581 Helsinki
FINLAND
Tel: +358 9 229 161
Fax: +358 9 2291 6795
URL: http://www.vaestorekisterikeskus.fi/vrk/home.nsf/pages/index_eng
Please find updated information also on www.ficora.fi/englanti/tietoturva/rekisteri.htm
a) information on national voluntary accreditation schemes, including any additional requirements pursuant to Article 3(7):
Le schéma volontaire de reconnaissance de la qualification des prestataires (au sens d’accréditation volontaire) a été mis en place comme prévu par l’article 7 du décret no. 2001-272 du 30 mars 2001 et ses arrêtés d’application du 31 mai 2002 et 26 juillet 2004. Ces textes précisent que la reconnaissance de la qualification des prestataires de services de certification électronique est délivrée par des organismes d’évaluation et de qualification préalablement accrédités. L’instance d’accréditation est le COFRAC (Comité Français d’Accréditation) ou toute autre instance européenne équivalente, signataire des accords européens relatifs à l’accréditation. L’accréditation dont la durée ne peut dépasser 5 ans atteste que l’organisme d’évaluation et de qualification est compétent pour exercer l’activité de certification de conformité des prestataires de services de certification électronique aux exigences de l’article 6 du décret du 30 mars 2001. Pendant la durée de sa qualification qui ne peut dépasser 3 ans, le prestataire doit faire l’objet d’un audit annuel.
b) the names and addresses of the national bodies responsible for accreditation and supervision as well as of the bodies referred to in Article 3(4):
– Accreditation body:
COFRAC
37 rue de Lyon,
75012 Paris
– Supervision body:
Secrétariat général de la Défense Nationale
DCSSI
51, boulevard de La Tour-Maubourg
75700 Paris 07 SP
c) the names and addresses of all accredited national certification service providers:
None
– Bodies referred to in Article 3(4):
Secrétariat général de la Défense Nationale
DCSSI
51, boulevard de La Tour-Maubourg
75700 Paris 07 SP
www.ssi.gouv.fr
For more information :
a) information on national voluntary accreditation schemes, including any additional requirements pursuant to Article 3(7):
– national voluntary accreditation scheme
The detailed national voluntary accreditation scheme is laid down in §§ 15 and 16 of the “Law Governing Framework Conditions for Electronic Signatures and Amending Other Regulations” of 16 May 2001 (Signatures Act; SigG) http://www.bundesnetzagentur.de/media/archive/3612.pdf and in §11 of the “Ordinance on Electronic Signatures” of 16 November 2001 (SigV) http://www.bundesnetzagentur.de/media/archive/3613.pdf.
additional requirements pursuant to Article 3(7)
All additional requirements pursuant to Article 3(7) are laid down in the “Law Governing Framework Conditions for Electronic Signatures and Amending Other Regulations” of 16 May 2001 (SigG) http://www.bundesnetzagentur.de/media/archive/3612.pdf and in the “Ordinance on Electronic Signatures” of 16 November 2001 (SigV) http://www.bundesnetzagentur.de/media/archive/3613.pdf.
SigG, SigV in German language and further detailed information are found under http://www.bundesnetzagentur.de/enid/6e36713104f448c490888c493a922c2d,0/Technische_Regulierung_Telekommunikation/Elektronische_Signatur_gz.html
b) the names and addresses of the national bodies responsible for accreditation and supervision as well as of the bodies referred to in Article 3(4):
– Supervision and accreditation body:
Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen
Referat für Elekronische Signatur
Canisiusstr.21,
D-55122 Mainz
-bodies referred to in Article 3(4):
Bundesamt für Sicherheit in der Informationstechnik (BSI)
Referat Zertifizierung, Zulassung
Godesberger Allee 185 – 189
D-53175 Bonn
TÜV InformationstechnikGmbH
Unternehmensgruppe TÜV NORD
Zertifizierungsstelle
Landgemarckstr. 20
45141 Essen
Zertifizieungsstelle der T-Systems
T-Systems GEI GmbH, BU ITC Security
Rabinstr. 8
D-53111 Bonn
c) the names and addresses of all accredited national certification service providers:
Please find updated information on http://www.bundesnetzagentur.de/enid/elsig (in German) and http://www.bundesnetzagentur.de/enid/en/elsig (in English).
a) information on national voluntary accreditation schemes, including any additional requirements pursuant to Article 3(7):
| Regulations | Concerning |
248-71  |
Provision of Electronic Signature Certification Services |
| 295- 63 |
Designation of Bodies for the Conformity Assessment of Secure-Signature-Creation Devices and Secure Cryptographic Modules and on the Designation of Bodies for the Conformity Assessment of Certification Service Providers using the Voluntary Accreditation Criteria |
| 295-64 |
Conformity Assessment of Secure Signature Creation Devices and Secure Cryptographic Modules |
| 295-65 |
Voluntary Accreditation of Certification Service Providers |
| 308-37 |
Selection of technological solution for the implementation of the Voluntary Accreditation scheme |
b) the names and addresses of the national bodies responsible for accreditation and supervision as well as of the bodies referred to in Article 3(4):
– Supervision and accreditation body:
National Telecommunications and Post Commission (EETT)
60, Kifissias Ave.
151 25 Maroussi
Athens-Greece
Tel: 0030 210 6151000
Fax: 0030 210 6105049
– Body referred to in art 3 (4):
None
c) the names and addresses of all accredited national certification service providers:
There is no accredited certification service provider at the moment.
d) additional information:
– Certification Service Providers established in Greece delivering qualified certificates to the public:
ΑΝΤΑΚΟΜ-ADVANCE INTERNET APPLICATIONS S.A., www.adacom.com
ATHENS EXCHANGE S.A., www.ase.gr
– Certification Service Providers established in Greece delivering non qualified certificates to the public:
EFG EUROBANK ERGASIAS BANK S.A, www.eurobank.gr
ATHENS CHAMBER OF COMMERCE AND INDUSTRY (EVEA), www.acci.gr
EDPS SA, www.edps.gr
a) information on national voluntary accreditation schemes, including any additional requirements pursuant to Article 3(7):
Decreto legislativo 7 marzo 2005, n. 82, DPCM 13 gennaio 2004, Deliberazione CNIPA 17 febbraio 2005, n.4.
All texts are available on http://www.cnipa.gov.it/certificatorinormativa
b) the names and addresses of the national bodies responsible for accreditation and supervision as well as of the bodies referred to in Article 3(4):
– Body responsible for supervision and accreditation:
CNIPA (Centro nazionale per l’informatica nella pubblica amministrazione), Via Isonzo 21/b, 00198 Rome – Italy www.cnipa.gov.it
– Body referred to in art 3 (4):
Istituto superiore delle comunicazioni e delle tecnologie dell’informazione (ISCTI) – (Ministry of communication) ISCOM/OCSI www.ocsi.gov.it
c) the names and addresses of all accredited national certification service providers:
Infocamere SC.p.A.
Piazza Sallustio, 21 – 00187 Roma, IT
Postecom S.p.A.
Viale Europa, 175 – 00144 Roma, IT
In.Te.S.A. S.p.A.
Via G. Servais, 125 – 10146 Torino, IT
Trust Italia S.p.A.
Piazzale Bosco, 3/A – 05100 Terni, IT
Cedacri S.p.A.
via del Conventino, 1 – 43044 Collecchio (Parma), IT
ACTALIS S.p.A.
via Torquato Taramelli, 26 – 20124 Milano, IT
Consiglio Nazionale del Notariato
via Flaminia, 160 – 00196 Roma, IT
Comando Transmissioni e Informazioni Esercito
via Ardeatina, 16 – 00042 Anzio, IT
Consiglio Nazionale Forense
via Arenula, 71 – 00196 Roma, IT
SOGEI S.p.A.
Via Mario Carucci, 99 – 00143 Roma, IT
Sanpaolo IMI S.p.A.
P.za San Carlo, 156 – 10126 Torino, IT
Banca Monte dei Paschi di Siena S.p.A.
P.zza Salimbeni, 3 – 53100 Siena, IT
Lombardia Integrata S.p.A. Servizi Infotelematici per il Territorio
Via don Minzoni 24 – 20158 Milano, IT
Banca Intesa S.p.A.
Piazza Paolo Ferrari, 10 – 20121 Milano, IT
Banca di Roma S.p.A.
Viale Umberto Tupini, 180 – 00144 Roma, IT
CNIPA – Centro nazionale per l’informatica nella pubblica amministrazione
Via Isonzo, 21b – 00198 Roma, IT
IT Telecom S.r.L.
Via Cornelio Tacito, 14 – 20137 Milano, IT
Consorzio Certicomm
Plaza della Repubblica, 59 – 00185 Roma, IT
Comando C4 Difesa – Stato Maggiore della Difesa
Via Stresa 31/B – 00135 Roma, IT
The above information is available on http://www.cnipa.gov.it/certificatoriattivi/
a) information on national voluntary accreditation schemes, including any additional requirements pursuant to Article 3(7):
There are no additional requirements under article 3.7.
b) the names and addresses of the national bodies responsible for accreditation and supervision as well as of the bodies referred to in Article 3(4):
– Body responsible for supervision and voluntary accreditation:
Information Society Development Committee under the Government of the Republic of Lithuania, (Gedimino Ave. 56, LT-01110, Vilnius, Lithuania, telephone: (+370 5) 2 66 51 61, fax: (+370 5) 2 66 51 80, e-mail: info@ivpk.lt , www.ivpk.lt , http://epp.ivpk.lt/
– Body referred to in Article 3(4):
None
c) the names and addresses of all accredited national certification service providers:
None
d) additional information:
– Certification Service Providers established in Lithuania delivering qualified certificates to the public:
UAB Skaitmeninio sertifikavimo centras,
Contacts: Jogailos str. 8-16 , LT-01116 Vilnius, LITHUANIA,
phone: +370-699-26662 fax: +370-700-22-715
Certification Service Providers established in Lithuania delivering non qualified certificates to the public:
The Bank of Lithuania www.lb.lt (in operation from 2001, serves interbanking needs), Information Society Development Committee under the Government of the Republic of Lithuania www.ivpk.lt (CSP for public sector,) some private banks, …Supervision body does not register CSPs of this kind, so such information isn’t complete.
a) information on national voluntary accreditation schemes, including any additional requirements pursuant to Article 3(7):
There are currently no voluntary accreditation schemes in Malta. A technical committee has been established under the auspices of the Malta Standards Authority, which is responsible for accreditation in Malta, to develop the terms of such a scheme.
It is the Maltese Government’s intention to seek accreditation for MITTS Ltd. when this possibility is made available in Malta.
Contact Details:
National Accreditation Body,
Malta Standards Authority,
Second Floor,
Evans Building,
Valletta, VLT03,
Malta
Tel: +356 21 255548, +356 21 242420
Fax: +356 21 242406
http://www.msa.org.mt
b) the names and addresses of the national bodies responsible for accreditation and supervision as well as of the bodies referred to in Article 3(4):
– Supervision body:
According to Article 25 (3) of the Electronic Commerce Act, the Minister for Competitiveness and Competition has, by virtue of Legal Notice 326 of 2005 designated the Malta Communications Authority as from the 15th September, 2005, to be the competent authority responsible for monitoring and ensuring compliance with the Electronic Commerce Act, and therefore of supervising the activities of Certification Service Providers issuing Qualified Certificates established in Malta:
http://docs.justice.gov.mt/lom/legislation/english/leg/vol_13/chapt426.pdf (Act)
http://www.mca.org.mt/library/channel.asp?lc=3&ch=38&t=2 (Legal Notice)
Contact Details:
Malta Communications Authority (MCA)
Valletta Waterfront,
Pinto Wharf,
Valletta VLT 01
Tel: +356 21 336 40
Fax: +356 21 336 48
URL: www.mca.org.mt
– Bodies referred to in article 3 (4):
None
c) the names and addresses of all accredited national certification service providers:
There are currently no Certification Service Providers established in Malta delivering qualified certificates to the public. Qualified digital certificates, will however be rolled out to all Citizens on the new Electronic Identity Card. The e-ID Card will replace the mandatory Identity Card and a national roll-out will take place during 2007. The Identity Card is issued by the Government of Malta.
The associated Certification Services will be provided by MITTS Ltd, which falls under the responsibility of the Ministry for Investments, Industry and Information Technology (MIIIT).
The Ministry for Investments, Industry and Information Technology (MIIIT) is responsible for drawing up the National Identity Management Strategy including electronic identity (e-ID). The Level 2 and Level 3 authentication mechanism of the electronic identity is based on PKI digital certificates. The Identity Management Office, currently within MIIIT, is thus responsible for the supervision of the deployment of the necessary infrastructure within the Public Sector.
a) information on national voluntary accreditation schemes, including any additional requirements pursuant to Article 3(7):
Over the last few years a voluntary accreditation scheme, named TTP.NL, has been developed. This scheme is meant to assess Certificate Service Providers (CSP’s) on compliance with ETSI TS 101 456. TTP.NL is a self regulation initiative, stimulated by the Ministry of Economic Affairs, and occurs under the administration of the Electronic Commerce Platform Netherlands, ECP.NL. For more information about this scheme, contact ECP.NL: info@ecp.nl ; tel. +31704190309; http://www.ecp.nl.
According to the Dutch law on electronic signatures (article 18.16 Telecommunications Act), the Minister of Economic Affairs may designate certification bodies that want to issue (under a voluntary accreditation scheme, such as TTP.NL) certificates of conformity to CSP’s complying with the requirements as laid down in the Dutch law on electronic signatures. The designating of such certification bodies is in process at the moment.
b) the names and addresses of the national bodies responsible for accreditation and supervision as well as of the bodies referred to in Article 3(4):
– Supervision body:
OPTA (Independent Post and Telecommunications Authority), P.O. Box 90420, 2509 LK The Hague www.opta.nl
– Accreditation body:
None
– Body referred to in art 3 (4):
None
c) the names and addresses of all accredited national certification service providers:
None
a) information on national voluntary accreditation schemes, including any additional requirements pursuant to Article 3(7):
None
b) the names and addresses of the national bodies responsible for accreditation and supervision as well as of the bodies referred to in Article 3(4):
– Supervision and accreditation body:
Ministry of Economy
Pl. Trzech Krzyzy 3/5
00-507 Warszawa POLAND
TEL. +48(022)6280981
FAX. +48(022)6934030
c) the names and addresses of all accredited national certification service providers:
Unizeto Technologies S.A
Ul.Krolowej Korony Polskiej 21,
70-486 Szczecin, Poland.
TEL. +48(091)4801202
FAX. +48(091)4801220
http://www.unizeto.pl/
Polska Wytwornia Papierow Wartosciowych S.A
Ul.Sabguszki 1,
00-222 Warszawa, Poland
TEL. +48(022)5302000
FAX. +48(022)5302450
http://www.pwpw.pl/
Krajowa Izba Rozliczeniowa S.A
Ul.Cypryjska 72,
02-761 Warszawa, Poland
TEL. +48(022)6516383
FAX. +48(022)6516393
a) information on national voluntary accreditation schemes, including any additional requirements pursuant to Article 3(7):
Accreditation scheme available on: http://www.nbusr.sk/NBU_SEP/leg_rozne/akreditacna_schema_ca.pdf
b) the names and addresses of the national bodies responsible for accreditation and supervision as well as of the bodies referred to in Article 3(4):
– Accreditation and supervision body:
National Security Authority – NSA (Národný bezpečnostný úrad – NBÚ)
Budatínska 30
850 07 Bratislava
Slovak Republic
Phone: +421 2 6869 1111, +421 2 6869 2114, +421 2 6869 2714
Fax: +421 2 6868 1701
Web site: http://www.nbusr.sk
– Bodies referred to in article 3 (4):
National Security Authority – NSA (Národný bezpečnostný úrad – NBÚ)
Budatínska 30
850 07 Bratislava
Slovak Republic
Phone: +421 2 6869 2114
Fax: +421 2 6868 1701
Web site: http://www.nbusr.sk
c) the names and addresses of all accredited national certification service providers:
National Security Authority – NSA (Národný bezpečnostný úrad – NBÚ)
Section of Information Security and Electronic Signature
Budatínska 30
850 07 Bratislava
Slovak Republic
Phone: +421 2 6869 2138
Fax: +421 2 6868 1701
Cell: +421 903 993 176
Web site: http://www.nbusr.sk
Mail: mikulaskova@nbusr.sk
D. Trust Certification Authority
Plynárenská 7/C
821 09 Bratislava
Slovak Republic
http://www.dtca.sk
First Slovak Certification Authority (PSCA – Prvá slovenská certifikačná autorita)
Borská 6
841 04 Bratislava
Slovak Republic
http://www.psca.sk
d) additional information:
– Certification Service Providers established in Slovakia delivering qualified certificates to the public:
CA EVPU (Certification Authority EVPU), Trenčianska 19, Nová Dubnica 018 51, http://www.caevpu.sk, accredited since 30th January 2004,
D. Trust Certification Authority, Plynárenská 7/C, 821 09 Bratislava, http://www.dtca.sk, accredited since 28th June 2004,
First Slovak Certification Authority (PSCA – Prvá slovenská certifikačná autorita), Borská 6, 841 04 Bratislava, http://www.psca.sk, accredited since 15th June 2005.
– Certification Service Providers established in Slovakia delivering non qualified certificates to the public:
First Slovak Certification Authority (PSCA), www.psca.sk,
D. Trust Certification Authority (DTCA), www.dtca.sk,
Certification Authority VÚB (CA VÚB), www.vub.sk (Only for bank’s clients),
Certification Authority EVPÚ (CA EVPÚ), www.caevpu.sk,
Certification Authority Dexia Slovakia, www.dexia.sk (Only for bank’s clients),
Certification Authority Apollo (CA APOLLO) www.apollo.sk (Only for insurance’s clients),
Certification Authority Tedis, www.tedis.sk (Only for contractual partners),
Certification Authority Disig (CA Disig), www.disig.sk (Only for contractual partners).
SLOVENIA
a) information on national voluntary accreditation schemes, including any additional requirements pursuant to Article 3(7):
The legal basis for national voluntary accreditation schemes is provided in the ELECTRONIC COMMERCE AND ELECTRONIC SIGNATURE ACT (ZEPEP-UPB1), Third chapter (Electronic Signature), Section 7 (Voluntary accreditation), Articles 42 – 45 (http://www.uradni-list.si/1/objava.jsp?urlid=200498&stevilka=4284, http://www.si-ca.si/eng/ZEPEP-UPB1-eng.doc). There is no national voluntary accreditation scheme implemented at present moment.
Regarding the additional requirements under Article 3(7): there are no additional requirements for the public sector, except by the Decree on conditions for Electronic Commerce and Electronic Signature the internal governmental applications must be secured by qualified certificates issued by CSP on Ministry of Public Administration.
b) the names and addresses of the national bodies responsible for accreditation and supervision as well as of the bodies referred to in Article 3(4):
-Accreditation and supervision body:
There is no accreditation body in Slovenia at the moment. All registered CSPs are subject to supervision by the Ministry of the Economy; Inspectorate for electronic communications, electronic signature and post (Ministrstvo za gospodarstvo; Inšpektorat Republike Slovenije za elektronske komunikacije, elektronsko podpisovanje in pošto), Stegne 7, SI-1000 Ljubljana, http://www.mg.gov.si/
c) the names and addresses of all accredited national certification service providers:
None
d) additional information:
– Certification Service Providers established in Slovenia delivering qualified certificates to the public:
– Certification Authority at the Ministry of Public Administration, Republic of Slovenia (Overitelj na Ministrstvu za javno upravo Republike Slovenije ), Tržaška cesta 21, 1000 Ljubljana, Slovenija, Tel.: +386 (1) 478 86 00, Fax: +386 (1) 478 86 49, E-mail: overitelj.mju@gov.si, Web: http://www.ca.gov.si
– HALCOM informatika d.o.o.,Služba HALCOM-CA, Tržaška cesta 118, 1000 Ljubljana, Slovenija, Tel.: +386 (1) 200 33 40, Fax: +386 (1) 200 33 56, E-mail: ca@halcom.si, Web: http://www.halcom.si
– AC NLB (Nova ljubljanska banka), Šmartinska 132, 1520 Ljubljana, Slovenija, Tel.: +386 (1) 477 20 00, Fax: +386 (1) 476 47 99, E-mail: acnlb@nlb.si, Web: http://www.nlb.si/acnlb
– POŠTA CA (Pošta Slovenije), Slomškov trg 10, 2500 Maribor, Slovenija, Tel.: +386 (2) 449 23 46, Fax: +386 (2) 449 22 55, E-mail: info.postarca@posta.si, Web: https://postarca.posta.si
Find here data relevant to Certificate Service Providers.
– Certification Service Providers established in Slovenia delivering non qualified certificates to the public:
No registered CSP is issuing non-qualified certificates. There are a number of certification authorities issuing non-qualified certificates for the closed systems.
a) information on national voluntary accreditation schemes, including any additional requirements pursuant to Article 3(7):
Spain has no national governmental voluntary accreditation schemes.
Nonetheless, there is a private initiative of a voluntary accreditation scheme managed by the «Asociación Multisectorial de Empresas Españolas de Electrónica y Comunicaciones» (ASIMELEC – www.asimelec.es)
The Spanish Law on electronic signatures implements article 3(7) of the Directive. Therefore, Public Administrations may impose additional requirements accordingly.
b) the names and addresses of the national bodies responsible for accreditation and supervision as well as of the bodies referred to in Article 3(4):
– Body responsible for supervision:
Ministry of Industry, Tourism and Commerce. http://www.mityc.es (Spanish/English)
– Accreditation body:
NA
– Certification bodies: In process of being designated: National Cryptology Centre – National Intelligence Centre. http://www.oc.ccn.cni.es/index_en.html
c) the names and addresses of all accredited national certification service providers:
The certification service providers which have notified (not accredited) their activities in Spain at the present moment are listed in the following URL:
http://www11.mityc.es/prestadores/busquedaPrestadores.jsp (Spanish)
a) information on national voluntary accreditation schemes, including any additional requirements pursuant to Article 3(7):
– Guidelines from the Swedish Board for Accreditation and Conformity Assessment’s Regulations for Accredited Bodies that Certify Information Security Management Systems: 
– Certification of information security management systems according to SS 62 77 99-2 including the issue of electronic certificates with reference to Directive 1999/93/EC of the European Parliament and of the Council: 
b) the names and addresses of the national bodies responsible for accreditation and supervision as well as of the bodies referred to in Article 3(4):
SWEDAC – Swedish Board for
Accreditation and Conformity Assessment.
SWEDAC
PO box 878
S-501 15 BORÅS
Sweden
Tel. +46 33 17 77 00
Fax +46 33 10 13 92
Website: www.swedac.se
c) the names and addresses of all accredited national certification service providers:
None
a) information on national voluntary accreditation schemes, including any additional requirements pursuant to Article 3(7):
None
b) the names and addresses of the national bodies responsible for accreditation and supervision as well as of the bodies referred to in Article 3(4):
– Accreditation body:
tScheme Limited
15 Court Lodge
Shorne
GRAVESEND
Kent
DA12 3EQ
www.tScheme.org
– Body responsible for supervision:
Information Security Policy Group
Department of Trade and Industry
151 Buckingham Palace Road
London
SW1W 9SS
– Body referred to in art 3 (4):
None
c) the names and addresses of all accredited national certification service providers:
Trust Assured
The Royal Bank of Scotland plc.
6th Floor, Premier Place
2½ Devonshire Place
London
EC2M 4BA
Certificate Factory
Trustis Limited
Building 273, New Greenham Park
Thatcham
Newbury
RG19 6HN
OnSite (Managed PKI) Service
BT Ignite
81 Newgate Street
London
EC1A 7AJ
SecureMark
Equifax Secure Limited
Capital House
25 Chapel Street
London
NW1 5DS
d) additional information:
– Certification Service Providers established in United Kingdom delivering qualified certificates to the public:
BT, http://www.bt.com/index.jsp
Certification Service Providers established in United Kingdom delivering non qualified certificates to the public:
Equifax, http://www.equifax.co.uk/
Royal Bank of Scotland, http://www.rbs.co.uk/default.htm
Trustis, http://www.trustis.com/company.htm
Con frecuencia he visto en presentaciones sobre firma electrónica y sobre DNIe de otras personas describir una serie de propiedades de la firma digital entre las que se cita la de ‘no-repudio’ .
Desde hace mucho años, una de mis manías es la de eliminar ese término de mis propias presentaciones, ya que es incorrecto tanto en español como en inglés, idioma en el que se ha popularizado desde el comienzo de uso de la tecnología de criptografía de clave pública.
Este término se usa además en dos contextos diferentes. En uno de ellos es un tipo de cualidad que se codifica en los certificados y en otro es una propiedad general de la firma electrónica.
Veamos. El repudio es posible siempre, tanto con firma manuscrita (u ológrafa) como con firma electrónica. Ese es uno de los motivos por los que yo intento eliminar el término «no repudio».
En términos técnicos, el antiguo bit ‘NR’ «Non repudiation» que se codifica en la extensión «key usage» de los certificados, en la actualidad se denomina «content commitment» cuando se refiere a la cualidad de un tipo de certificado que indica al software en el que se usa que debe permitir que el usuario conozca lo que firma (what you see is what you sign). Es decir, lo importante es el compromiso con el contenido. Esta codificación se emplea en la clave de FIRMA del DNI electrónico.
Cuando el bit ‘ES’ de «electronic signature» se codifica en la extensión «key usage» se supone que en realidad NO ES una verdadera FIRMA en el sentido jurídico, sino que puede ser una firma electrónica automatizada por el sistema utilizado. Por eso se diferencia entre ambas modalidades, de forma que sus bits respectivos son incompatibles y no pueden ir activados a la condición booleana «TRUE» simultáneamente en el mismo certificado. Esta codificación se emplea en la clave de AUTENTICACIÓN del DNI electrónico y no exige conocimiento de lo firmado por el usuario, ya que lo que el dispositivo suele firmar es un código de desafío, lo que constituye la respuesta en la aplicación de un modelo «challenge -response».
El otro uso del término «no repudio» tiene que ver más bien con el concepto jurídico de «vicio de consentimiento» que
se produce cuando se engaña o se amenaza a una persona para que firme , y es una de las causas de nulidad de contratos. Lo que es aplicable tanto a la firma manuscrita como a la digital.
Con esta orientación, una firma electrónica no garantiza el «no repudio» aunque es un término muy usado por los técnicos y algunos abogados para referirse a otro concepto que es más bien «prueba de firma» o «presunción de firma».
En efecto, la firma electrónica cualificada (o reconocida) crea la presunción de firma al mismo nivel o a mayor nivel que el que se deriva del empleo de la firma manuscrita. E impone la carga de la prueba a quien sostiene que la firma no es válida.
De hecho aparecen casos en los que se puede decir que uno no ha firmado (casos «de repudio»), un poco diferentes a los de la firma manusctita. La firma manuscrita se puede «falsificar«. Por otro lado, en la firma electrónica no existe «inmediación» (no se vincula indisolublemente al firmante). Es decir, otra persona que tenga la tarjeta o el DNIe y conozca el PIN puede llevar a cabo la firma.
A veces esta es una función deseada, cuando la tarjeta y el PIN se usan como un «poder al portador» y se cede a un tercero la posibilidad de firmar. Pero en todo caso, lo firmado le es atribuible o imputable a quien aparece como firmante: al titular del certificado.
Organiza: Asociación Española de Documentación Digital (AEDD)
Fechas: 8 de noviembre de 2006
Lugar: IFEMA (Feria de Madrid)
Materias:
Normativas y legislación relacionadas con la gestión de los documentos digitales
Precio: evento gratuito
Víctor Canivell, ex-Presidente de Safelayer.com, estará al frente de WISeKey ELA, una joint venture de WISeKey y el Grupo Velasco radicada en Bilbao .
Me alegro que Víctor siga en nuestro sector. Lo conozco desde la época de Silicon Graphics (con una máquina SGI puse en marcha en 1995 los primeros servicios bancarios de España en Banesto, con el primer servidor seguro y el primer entorno de autor de páginas web). Y tuve muy buena relación con él en su etapa de Safelayer. Creo que es un acierto que lo haya fichado esta multinacional de la certificación electrónica.
WISeKey ELA ha nombrado Presidente a Víctor Canivell. Víctor Canivell llega a WISeKey ELA con un bagaje de más de 25 años de experiencia en el área de gestión de los sectores de informática y redes. Ha desempeñado diversos puestos de vicepresidente para la zona EMEA, tanto en el área de ventas como de servicios, en empresas como Hewlett Packard, 3Com, Silicon Graphics, Cray Research y en start-ups como Aspective. Recientemente ha desempeñado el puesto de Presidente de Safelayer, la start-up española pionera en el campo de la firma digital. Llega ahora de SSA Global, donde ha contribuido al éxito de la OPV en NASDAQ de la empresa.
«Ahora que entramos en la siguiente fase de crecimiento, que incluye el establecimiento de un ecosistema ID para los mercados de habla española y portuguesa, Víctor Canivell aporta a WISeKey ELA la competencia, los conocimientos y la experiencia necesaria para liderar a la empresa en un mercado que se expande tan rápidamente como es el de la gestión de ID», declara Carlos Moreira, Cofundador y Presidente de WISeKey .
WISeKey ELA, la recientemente fundada empresa de tecnología de seguridad informática con sede central en Bilbao, distribuirá en España y América Latina productos manufacturados en Ginebra por WISeKey SA, estableciendo la presencia de WISEkey en estos mercados por medio de una red de filiales. WISeKey ELA ha crecido sobre los sólidos y reputados fundamentos tecnológicos de WISEkey, respondiendo a un significativo nicho de mercado en materia de ID y PKI.
«La dilatada experiencia de Víctor Canivell y su fidedigno historial al frente de otras empresas lo convierten en la elección natural para ocupar el puesto de Presidente de WISeKey ELA», afirma Pedro Luis Velasco Ibáñez, Presidente del Grupo Velasco. «Su diversificada competencia en desarrollo de software, PKI, gestión de ID y mercados IT coincide exactamente con la línea de negocio de WISeKey . Estoy convencido de que conducirá a la empresa hacia éxitos todavía mayores».
«Encaro con entusiasmo mi incorporación al equipo de WISeKey ELA y la posibilidad de trabajar sobre el impulso hacia adelante que ha cobrado la empresa gracias a su probada capacidad a la hora de posibilitar la implementación distribuida de aplicaciones de gestión ID y PKI por Internet, aspectos cruciales donde los haya», afirma Víctor Canivell. «Sabiendo como sé que WISeKey ELA duplicará el éxito de WISeKey en el mercado español y latinoamericano, estoy impaciente por ayudar a la empresa a llegar a un espectro todavía más amplio de clientes».
Ejecutivo veterano con muchos años de experiencia en la gestión de empresas de tecnologías de la información, Víctor ha vivido y desarrollado su carrera profesional en diferentes puntos geográficos, con estancias de varios años en Londres, Cupertino (EE.UU.), Ginebra, Stuttgart, Madrid y Barcelona. Habla varios idiomas con fluidez, recuerdo de su paso por el barcelonés Colegio Suizo. Víctor posee un MBA del ESADE (Barcelona) y es doctor en Física por la Universidad de Barcelona. Ha cursado estudios de gestión empresarial en el INSEAD y el IESE.
Los pasados 18 y 19 de mayo de 2006 participé, junto con Fernando Pino en un evento organizado por Maat en la Caja Rural de Toledo, del que transcribo el resumen.
DÍA 18 DE MAYO
La primera jornada del seminario Documento Electrónico y Factura Electrónica se centró en el Documento Electrónico. Julián Inza, experto en certificación digital, Presidente de Albalia Interactiva y exdirector General de Camerfirma y colaborador habitual de maat Gknowledge, y Fernando Pino, experto en Legislación sobre certificación digital, durante el Seminario expusieron los puntos básicos de los documentos electrónicos y su equiparación con los de papel, haciendo especial hincapié en el DNI electrónico.Julián Inza, experto en certificación digital, fue el encargado de inaugurar la primera sesión del Seminario, explicando la importancia que supone modificar los soportes ante el ritmo imparable de las nuevas tecnologías. A continuación, Fernando Pino expuso los aspectos prácticos de la Firma Electrónica. En este sentido, incidió en los diferentes tipos de firmas existentes, haciendo un análisis de la criptografía asimétrica, técnica en la que esté basada la Firma Electrónica.
Durante su alocución, Fernando Pino también se refirió a la función que cumplen las Entidades de Certificación y a otras funciones asociadas que también les son asignadas, como reglamento, gestión de certificados revocados, lista de certificados expedidos…
Asimismo, detalló cuáles son las partes que componen un certificado digital. Éste tendría que estar formado por el nombre, una clave pública que viene determinada por la Entidad de Certificación, un periodo de validez del certificado, su número de serie, otros atributos de interés y el nombre de la entidad de certificación y su firma. Fernando Pino resaltó que este sistema está fundamentado en una base matemática, igual que la criptografía que se basa en una serie de operaciones que hace que determinadas claves tengan unas características diferentes de otras.
El experto de Firma Electrónica también hizo hincapié en las funciones de seguridad que desempeña la utilización de la firma electrónica, obtenida mediante algoritmos de HASH. Para concluir, Fernando Pino, tras la explicación conceptual, argumentó con ejemplos concretos la aplicación práctica de los mismos e hizo mención a la normativa vigente relativa a los certificados digitales y a los correspondientes prestadores españoles.
Por su parte, Julián Inza se refirió a la realidad que ya supone el DNI electrónico y la necesidad que conlleva su utilización por los ciudadanos como representación de su personalidad jurídica. Tras hacer un breve repaso a la historia del DNI electrónico, señaló que no se trata de un problema de productividad de este documento, sino de cambiar la infraestructura y la educación en España.
El chip que se incorporará en el DNI electrónico contendrá la siguiente información: datos de filiación del titular, imagen digitalizada de la fotografía, imagen digitalizada de la firma manuscrita, plantilla de la impresión digital del dedo índice de la mano derecha, o en su caso, del que corresponda según lo indicado en el artículo 5.3 del Real Decreto 1553/2005, certificados reconocidos de autentificación y firma, y certificado electrónico de la autoridad emisora, que contendrán sus respectivos periodos de validez y las claves privadas pertinentes. En este mismo Real Decreto se alude a la protección de los datos del titular del documento.
Para este experto, uno de los mayores handicaps es que los ciudadanos no van a saber cuáles son las verdaderas utilidades del DNI electrónico, ya que su acceso a la información de este documento es más sencilla. En este sentido, señaló que está previsto que todos los españoles dispongan del DNI electrónico en 2018, debido al proceso espiral que está siguiendo la Administración Pública a la hora de implantarlo. La primera ciudad en disfrutar de él ha sido Burgos, donde las expediciones de DNI se han duplicado, y el proceso finalizará en Madrid y Barcelona, debido a su complejidad burocrática y logística.
Por otro lado, según Julián Inza, es necesario trasladar algunos aspectos del documento papel al electrónico, de manera que queden garantizados ciertos puntos, como la titularidad, la autenticidad, el conocimiento por parte de los interesados, las atribuciones de quien lo expide, los efectos que produce y un marco temporal que estipule tanto la expedición como la validez. Todo ello es posible gracias a las especiales características de los documentos electrónicos (referencias de URL, criptografía, anotaciones en registro de anotaciones)
El paso del soporte papel a electrónico se realiza como compulsa electrónica, en la que el documento electrónico es una copia auténtica, o como replicación electrónico o digitalización certificada, donde partiendo del documento en papel se trata de hacer uno electrónico que permita eliminar el primero. De esta última forma se podrían eliminar toneladas de papeles y facturas.
DÍA 19 DE MAYO
Esta segunda jornada del Seminario versó sobre la regulación normativa de la facturación electrónica en España y en las oportunidades de esta nueva herramienta para todas las empresas.La segunda jornada del Seminario Documento Electrónico y Factura Electrónica se inició con una explicación, realizada por Julián Inza, sobre la Facturación, como justificante de las operaciones que se realizan. Durante su exposición, el experto en certificación digital, indicó que aunque su formato habitual es el de papel, cada vez más se está utilizando el formato electrónico. Sin embargo, su aceptación total vendrá determinada por el receptor de la misma.
Julián Inza realizó un breve repaso de la normativa sobre facturación destacando la Directiva 115/2001, por la que a partir del 1 de enero de 2004 todas las facturas electrónicas emitidas debían estar armonizadas con el resto de Europa. Esta Directiva establece unos requisitos mínimos que los países no pueden exceder. En esta misma Directiva, se señala, según expuso Julián Inza, que las facturas electrónicas irán con una firma electrónica avanzada, pudiendo ser exigible la cualificada. Por ello, es aconsejable que se incluya directamente la cualificada, como se exige en España, para evitar posibles devoluciones.
En el ámbito empresarial, todos los empresarios y profesionales están obligados a expedir facturas electrónicas, cuando el destinatario sea otro que así lo solicite y cuando el importe sea superior a 3.000 euros. Sin embargo, están exentas de expedición de factura electrónica las operaciones autorizadas por el Departamento de Gestión AEAT, cuando el destinatario sea un particular o en regímenes especiales.
En el caso de delegación a la hora de expedir una factura electrónica, ésta se realiza de igual manera que una factura en papel. Sin embargo, una que de las condiciones que existen es que haya un acuerdo firmado entre la parte que emite y la que recibe la factura para que esto se realice así.
A lo largo del seminario, se hizo un repaso a todos los requisitos que tiene que cumplir una factura, tanto electrónica como papel. En esencia, se trata de que lleven el número y la serie, -pudiendo darse la situación de que haya series separadas (operaciones de diferente naturaleza)-, fecha de expedición, la denominación social completa aunque algunas aplicaciones informáticas no permiten demasiados caracteres-, el NIF, el domicilio societario -no el del centro de trabajo-, la descripción de las operaciones, el tipo o tipos impositivos aplicables, la cuota tributaria y los pagos anticipados, si los hubiera. Además de todos estos datos, también se hará constar si se trata de una copia, de operaciones triangulares
Durante su alocución, Julián Inza también explicó la existencia de documentos sustitutivos, válidos para operaciones inferiores a 3.000 euros. Estos documentos, al no incluir todos los requisitos de las facturas, no tienen derecho a deducción. En este caso, el emisor sólo podía emitir una factura electrónica, si así lo aceptaba el receptor. Sin embargo, ahora bastará con que el emisor diga que si no está de acuerdo con la recepción de facturas electrónicas, lo diga.
En su intervención, Julián Inza hizo referencia a las facturas recapitulativas y rectificativas. Respecto a las primeras, son aquellas que se expiden a final de mes dando fe de las emitidas electrónicamente. En cuanto a las segundas, es preciso señalar cuál es la rectificación, aunque también puede realizarse en la siguiente factura que se emita. Este tipo de facturas han venido a sustituir a las antiguas notas de abono.
Además señaló cuáles son los requisitos que acreditan la autenticidad e integridad de una factura electrónica: la existencia de una firma electrónica avanzada, el intercambio electrónico de datos (EDI) o cualquiera de los elementos propuestos por interesados y autorizados por la AEAT.
Tras la explicación conceptual de la factura electrónica, Julián Inza mostró un ejemplo práctico de la misma. Posteriormente incidió en las ventajas que supone el empleo de este proyecto para las empresas del municipio. En este sentido señaló: los menores costes derivados del ahorro de papel, gastos de envío y gastos de almacenamiento, la agilidad en la tramitación, el ahorro en espacio, un procedimiento más seguro, el ahorro en la recepción de facturas, y la mejora en el control de los procedimientos de las facturas.
Para evidenciar estas ventajas, Julián Inza, presentó un cálculo orientativo de costes del proyecto de lo que supone el envío por correo ordinario frente al empleo de la factura electrónica. En su opinión, es fundamental analizar todos los pasos que influyen en el proceso para poder extraer una conclusión. Un análisis pormenorizado de distintos conceptos para poder establecer un coste total.
Una vez explicadas estas consideraciones, Julián Inza destacó los objetivos del proyecto de facturación, basados en la búsqueda de reducción de costes directos a través de la eliminación de impresión, gestión manual de la factura y correos, y las fases que lo integran. A continuación expuso los distintos formatos que pueden emplearse: tanto los recomendados como los existentes, así como las ventajas que aportan cada uno de ellos.
La fase final del Seminario se dedicó a la exposición de las obligaciones del Emisor, al proceso de Remisión, a las obligaciones del Receptor, como parte determinante del proceso, y a los pasos a seguir en la Recepción.
El Emisor tiene la responsabilidad de conservar los datos de la factura, la responsabilidad de asegurar la legibilidad en formato original, la garantía de acceso a las facturas y, en caso de la factura electrónica, la firma o la delegación en un tercero de esta acción o en el Receptor. Por su parte, al Receptor le corresponde conservar las facturas recibidas en su formato original, opcionalmente puede conservar la factura impresa con marcas gráficas PDF-417, asegurar la legibilidad en formato original, garantizar el acceso completo a las facturas y la disposición del software, que permita verificar la firma y la identidad el Emisor así como la vigencia del certificado.
Julián Inza concluyó el Seminario con un breve resumen de los conceptos tratados durante esta segunda Jornada del que pueden extraerse las siguientes conclusiones:
La normativa de factura electrónica tiene alcance europeo. Cualquier formato de factura es válido, aunque cada uno implica su propio formato de firma. Formatos recomendados: PDF (tagged form), XML (UBL 2.0), EDIFACT, UNeDocs. Otros formatos posibles: PKCS#7 y firma de mensajes de Correo (S/MIME). La firma de Ficheros PDF es fácil de entender y permite conversión a XML. La firma de Ficheros EDIFACT y XML es más adecuada para sistemas automatizados. Links de interés:
www.albalia.com
Veo con disgusto que en la próxima reunión de trabajo abierta de factura electrónica en el marco del Comité Europeo de Normalización se presentan borradores de documentos sobre el grado de avance en la adopción de la factura electrónica en Europa que, además de incompletos y sesgados, reflejan una notable ausencia: la de España. No sé si es que los miembros del grupo de trabajo, coordinado por AFNOR (el equivalente de AENOR en Francia) no preguntaron o no recibieron respuesta, pero me parece una ausencia injusta.
La reunión es en Bruselas el próximo dia 11 de abril de 2006, con motivo de los trabajos del CEN/ISSS Workshop on «Interoperability of Electronic Invoices in the European Community» .
La página web del Comité de Interoperabilidad de las Facturas Electrónicas en la Comunidad Europea está hospedado en AFNOR.
A la vista de los propios esfuerzos de normalización de la factura electrónica por la Agencia Estatal de Administración Tributaria, España está muy infrarrepresentada en estos trabajos del CEN.
Lo cierto es que desde la publicación de la Directiva 115 del año 2001, la unión europea está manifestando un gran respaldo a la facturación electrónica, dentro del esfuerzo de armonización de los mecanismos tributarios relacionados con el IVA (Impuesto sobre el Valor Añadido) y la facturación de las empresas y de los profesionales.
Parte de ese esfuerzo puede verse en estas Reglas de Facturación del IVA.
Por otro lado, es inevitable plantearse cómo de sincronizados van los esfuerzos de normalización de la factura a nivel técnico, lo que claramente es un objetivo de este grupo de trabajo, respecto a los grupos de trabajo de OASIS que están avanzando no solo en el mensaje de factura, sino en otros mensajes necesarios en la comunicación entre empresas. De hecho, estamos en la fase previa a la publicación de la versión 2.0 de UBL.
En el ámbito de la gestión de la firma electrónica, a veces es interesante conocer los desarrollos normativos de otros países. Por ejemplo la
Deliberazione CNIPA 4/2005 (Centro Nazionale per l´Informatica nella Púbblica Amministrazione) 17 febbraio 2005. Regole per il riconoscimento e la verifica del documento informatico.
Esta norma italiana es muy clarificadora respecto a la forma de codificar los certificados electrónicos considerando las extensiones definidas en las normas técnicas de ETSI. Se incorpora a continuación gracias al traductor de Google.
Deliberación CNIPA 4/2005 (Centro Nacional de Informática en la Administración Pública ) de 17 febrero de 2005. Reglas para el reconocimiento y la verificación de los documentos electrónicos.
Título I. DISPOSICIONES GENERALES
LA JUNTA
Teniendo en cuenta el Decreto Legislativo de 12 de febrero 1993 no. 39, en su versión modificada por el artículo 176, apartado 3, del Decreto Legislativo 30 de junio 2003, n. 196;
Teniendo en cuenta el Decreto del Presidente de la República de 28 de diciembre de 2000, n. 445, que contiene el texto refundido de las leyes y reglamentos en el ámbito de la documentación administrativa;
Dado el decreto legislativo 23 de enero 2002 n. 10, la Directiva 1999/93/CE por la aplicación de un marco comunitario para la firma electrónica;
Visto el artículo 40, apartado 4, del Decreto del Presidente del Consejo de Ministros del 13 de enero de 2004;
Resuelve
adoptar las siguientes normas para el reconocimiento y la verificación de los documentos electrónicos.
Artículo 1 . Definiciones
1 . Sin perjuicio de las definiciones contenidas en los artículos 1 y 22 del Decreto del Presidente de la República de 28 de diciembre de 2000, n. 445, y sucesivas modificaciones, a efectos del presente reglamento se entiende por:
a) texto único, el texto refundido de las leyes y reglamentos en el ámbito de los documentos administrativos , emitidos por el Decreto del Presidente de la República de 28 de diciembre de 2000, n . 445 ;
b ) los reglamentos técnicos , normas técnicas para elaborar, transmitir , conservar, duplicar , reproducir y validar , aunque sea temporalmente , de los documentos electrónicos emitidos por decreto del Presidente del Consejo de Ministros del 13 de enero de 2004 publicado en la Gaceta Oficial 27 Abril de 2004, no. 98 ;
c ) firma múltiple, firmas digitales colocados por diferentes firmantes en el mismo documento ;
d ) campo, información de la unidad contenida en el certificado . Puede estar compuesto por varias unidades de información elementales llamadas «atributos»;
e) extensión método utilizado para asociar la información específica ( atributos ) a la clave pública contenida en el certificado , que se utiliza para proporcionar información adicional sobre el titular del certificado y de la gestión de la jerarquía de certificación;
f ) atributo , la información básica contenida en un campo de un certificado electrónico como un nombre, un número o una fecha ;
g ) atributos autenticados , conjunto de atributos firmados con firma electrónica por el suscriptor ;
h ) marca crítica característica que puede aplicar a ciertas extensiones de los certificados de acuerdo con la RFC 3280 ;
i ) sello de tiempo evidencia informática determina la vinculación temporal ;
l ) OID ( Object Identifier) , el código numérico estándar para la identificación única de prueba la información utilizada para la representación de estructuras de datos como parte de la norma instrumentos internacionales para la interconexión de sistemas abiertos ;
m) RFC ( Request For Comments ) documentos que contienen especificaciones técnicas estándar , internacionalmente reconocido , definido por la Internet Engineering Task Force ( IETF) y la versión de Internet Grupo de Ingeniería Directivo ( IESG );
n) ETSI ( Instituto de Estándares Europeos de Telecomunicaciones) , una organización independiente sin fines de lucro cuya misión es producir normas de telecomunicaciones . Es oficialmente responsable de la creación de normas sobre firma electrónica en Europa;
o) HTTP ( Hypertext Transfer Protocol) protocolo para la transferencia de páginas de hipertexto y recursos de la red cumple con RFC 2616 y sucesivas modificaciones ;
p ) LDAP ( Lightweight Directory Access Protocol ) protocolo de red que se utiliza para hacer la información accesible en la red cumple con RFC 3494 y sus posteriores modificaciones .
Artículo 2 . Alcance y contenido
1 . La presente Decisión establece, de conformidad con el artículo 40 , párrafo 4 de las normas técnicas , las reglas para el reconocimiento y la verificación del documento electrónico al que deben atenerse que acredita certificadores debe seguir con el fin de obtener y mantener la autorización contemplada en el artículo 28 , apartado 1, del texto único .
2 . Las disposiciones del Título II define el formato de los certificados reconocidos y de la información que debe figurar en ellos.
3 . Las disposiciones del título III define el formato de los certificados electrónicos de la certificación y la información que contiene se deben generar de conformidad con el artículo 13, párrafo 2 , los reglamentos técnicos y el formato de los certificados electrónicos de marca de tiempo y la información que debe figurar en ellos.
4 . Las disposiciones del título IV define el formato y la información que debe figurar en las marcas de tiempo utilizados por los sistemas de validación temporal de los documentos , por lo que tal como se define en el Título IV de los reglamentos técnicos .
5 . Las disposiciones del título V definen el formato y los procedimientos para el acceso a la información sobre la revocación y suspensión de certificados , de conformidad con el artículo 29, párrafo 1 , de las normas técnicas .
6 . Las disposiciones del título VI se definen los tamaños de sobres criptográficos diseñados para mantener los artículos firmados con una firma digital.
7 . Las disposiciones del título VII definen los requisitos de la aplicación de la verificación de la firma digital se refiere el artículo 10 de las normas técnicas.
Título II. PERFIL DE LOS CERTIFICADOS RECONOCIDOS
Artículo 3 . reglas generales
1 . El perfil de los certificados es , a menos que se indique lo contrario , conforme a RFC 3280, capítulo 4 , titulado «Perfil de certificados y listas de revocación de certificados de infraestructura de clave pública «, y , a menos que se indique otra cosa , conforme a la especificación ETSI TS 101 862 V1.3.2 , titulado «Perfil de certificados reconocidos . »
Artículo 4 . Perfil de certificados reconocidos
1 . Salvo disposición en contrario en la presente resolución , se aplica a los certificados reconocidos como se especifica en la especificación ETSI TS 102 280 V1.1.1 , titulado «Perfil de los certificados Para los certificados X.509 v3 expedidos a personas naturales » .
2 . El campo de emisor ( emisor) del certificado deberá contener al menos los siguientes atributos:
a) organizationName ( OID: 2.5.4.10 ), que contiene el nombre o la denominación de la organización que emite el certificado reconocido;
b ) countryName ( OID: 2.5.4.6 ) , que contiene el código de país ISO 3166 del Estado en el que la organización está registrada nell’organizationName indicó .
3 . El subjectDN campo ( datos de identificación del propietario) del certificado contiene los siguientes atributos :
a) givenName y apellidos ( OID: 2.5.4.42 y 2.5.4.4 ) que contenga el nombre y apellidos del titular del certificado;
b ) countryName ( OID: 2.5.4.6 ) que, en el caso de que el organizationName contiene el valor » no está presente » , contiene el código de país ISO 3166 del Estado de residencia del titular. En caso donde el organizationName contiene un valor distinto de » no presente » , contiene el código de país ISO 3166 del estado que tiene el código de identificación asignado a la organización organizationName en el atributo ;
c ) organizationName ( OID: 2.5.4.10 ) que contiene , en su caso , el nombre o razón social y el número de identificación de la organización que ha solicitado o autorizado el tema del titular del certificado . El código de identificación es un código emitido por la autoridad gubernamental del Estado especificado en el countryName atributo. Si el organizationName no es aplicable , toma el valor » no disponible»;
d ) serialNumber ( OID: 2.5.4.5 ) que contenga código fiscal del titular expedido por la autoridad competente del Estado de residencia del titular o , en su defecto , un código de identificación similar, que tal como un número de seguro social o un identificador general. Con el fin de definir el contexto para la comprensión del código en cuestión , el código en sí está precedido por el código de país ISO 3166 y el carácter «:» ( en notación hexadecimal » 0x3A «);
e) como una alternativa a los atributos especificados en el inciso a ) , el certificado puede contener el atributo seudónimo ( OID: 2.5.4.65 ) que contiene cualquier cadena única, a discreción del propietario.
La cadena que se utiliza para rastrear los datos no permite la identificación del propietario. Si el atributo seudónimo está presente , el atributo countryName tiene el valor de «IT» , el atributo organizationName tiene el valor » no presente «, el valor del atributo serialNumber «alias» y el título de atributos y localityName no están presentes ;
f ) dnQualifier ( OID: 2.5.4.46 ) contiene la identidad del titular de la certificadora . Código asignado por el certificador , es único.
4 . El campo subjectDN ( datos de identificación del titular ) del certificado puede contener otros atributos , siempre y cuando no entren en conflicto con las disposiciones de la ETSI TS 102 280 . La eventual codificación de los atributos title , localityName , unitName commonName y organizativa cumplir con las siguientes reglas:
a) título ( OID: 2.5.4.12 ) contiene una indicación específica de la condición de titular , que las órdenes o la pertenencia a colegios profesionales , la matrícula en la posesión de libros u otro cualificaciones profesionales o de las facultades de representación dentro de la organización se especifican en el organizationName . En el caso de que el atributo organizationName contiene un valor distinto de » no presente » , la inclusión de información en el título es requerido por la organización. De lo contrario, contiene la información derivada de la auto- certificación realizada por el titular de conformidad con la legislación aplicable ;
b ) localityName ( OID: 2.5.4.7 ) contiene , en el caso en que el atributo organizationName contiene un valor distinto de » no presente » , la información especificada en cuestión a la organización ;
c ) commonName ( OID: 2.5.4.3 ) , además del apellido y givenName , contener cualquier otro nombre por el que el titular se conoce comúnmente ;
d ) organizationalUnitName ( OID: 2.5.4.11 ) contiene más información sobre la organización Lla . Puede aparecer Este atributo , como máximo , cinco veces .
5 . El certificado también contiene las siguientes extensiones :
a) keyUsage ( OID: 2.5.29.15 ) que contiene sólo el no repudio de valor ( 1 bit en 1 ) . La extensión está marcado crítico ;
b ) certificatePolicies (OID : 2.5.29.32 ) que contiene el OID de la Política de Certificados (PC) y el localizador uniforme de recursos ( URL) que apunta a la Declaración de Prácticas de Certificación ( CPS ) respecto de las cuales la
certificadora ha emitido el certificado. Si no adopta un CP definido a nivel nacional o europeo , la CA define su propio CP y que OID está definido y anunciado por
certificador. Se puede mostrar más de Política de Certificación ( CP ) . La URL se configura una ruta absoluta para acceder a la CRL . La extensión no está marcada crítica;
c ) cRLDistributionPoints ( OID: 2.5.29.31 ) que contiene la dirección URL que apunta a la CRL / CSL publicado por el certificador puede estar disponible cuando la información relativa a la revocación o suspensión del certificado en cuestión. La URL se configura una ruta absoluta para acceder a la CRL . El esquema que se utilizará para la URL es HTTP o LDAP permite la descarga en el anonimato la CRL. En caso de que se valoran más de un URL para la ampliación , estas URL configurar rutas en consonancia con la última CRL / CSL publicada . La extensión no está marcada crítica;
d ) authorityKeyIdentifier ( OID : 2.5.29.35 ) que contiene al menos el atributo keyIdentifier . La extensión no está marcada crítica;
e) subjectKeyIdentifier ( OID : 2.5.29.14 ) que contiene al menos el keyIdentifier atributo . La extensión no está marcada crítica;
f ) QcStatements identificados en ETSI TS 101 862 de la siguiente manera :
1 ) Identificación – ETSI – sth- QcCompliance ( OID: 0.4.0.1862.1.1 );
2 ) Identificación – ETSI – sth- QcLimitValue ( OID: 0.4.0.1862.1.2 ) , si se trata de los límites aplicables en las negociaciones;
. 3 ) Identificación – ETSI – sth- QcRetentionPeriod ( OID: 0.4.0 01/03/1862 ), el valor indicado es mayor que o igual a » 10 «;
4 ) Identificación del ETSI – sth- QcSSCD ( OID: 0.4.0.1862.1.4 ) . La extensión no se considera crítica .
6 . El certificado de suscripción puede contener las siguientes extensiones:
a) SubjectDirectoryAttributes (OID : 2.5.29.9 ) . No contiene ninguno de los campos especificados en los párrafos 3 y 4 . El atributo fechaDeNacimiento ( OID: 1.3.6.1.5.5.7.9.1 ) , si está presente, se codifica en
GeneralizedTime . La extensión no está marcada crítica;
b ) AuthorityInfoAccess ( OID: 1.3.6.1.5.5.7.1.1 ) .
En el caso de que el certificador de poner a disposición , de conformidad con el artículo 10 , un sistema de OCSP para comprobar la validez de un certificado, la extensión Autoridad InfoAccess accessDescription contiene un campo con una descripción de cómo acceder al servicio de OCSP , y contiene los siguientes atributos:
1 ) AccessMethod , que contiene el identificador id- ad – ocsp ( OID: 1.3.6.1.5.5.7.48.1 );
2 ) accessLocation , que contiene el URI que apunta a la certificación de respuesta de OCSP , se puede utilizar para la verificación del certificado. El URI configura una ruta absoluta a Responder acceso OCSP.
En el caso de que más campos se especifican acceso Descripción contiene el identificador ID – AD- OCSP AccessMethod en el atributo , tales indicaciones configurar varias rutas alternativas para la consulta, utilizando el estado del certificado OCSP. La extensión no está marcada crítica;
c ) Salvo lo dispuesto en el artículo 4 , apartado 5 , letra f ) , los límites de uso adicionales establecidos en el artículo 43 de las normas técnicas se incluyen en el campo de atributo certificatePolicies extensión explicitText UserNotice ;
d ) nuevas extensiones se pueden incluir en el certificado siempre y cuando cumplan con las normas mencionadas en la presente resolución y que no estén marcadas crítico.
Título III . PERFIL DE LOS CERTIFICADOS DE CERTIFICACIÓN Y MARCADO DE TIEMPO
Artículo 5 . Perfil de los certificados de certificación y sellado de tiempo
1 . Salvo disposición en contrario , el perfil de los certificados cumple con RFC 3280 .
Artículo 6 . El uso de extensiones en los certificados de certificación
1 . Los certificados de los certificados contienen las siguientes extensiones :
a) keyUsage (OID 2.5.29.15 ) , contiene los valores keyCertSign y cRLSign ( 05:06 bit se establece en 1 ) . La extensión está marcado crítico ;
b ) basicConstraints ( OID 2.5.29.19 ) , contiene el valor CA = true. La extensión está marcado crítico ;
c ) certificatePolicies ( OID 2.5.29.32 ) , contiene uno o más identificadores de policyIdentifier y la dirección URL relativa del PSC . Puede contener el OID prevé RFC genérico 3280 ( 2.5.29.32.0 ) .
La extensión no está marcada crítica;
d ) cRLDistributionPoints ( OID 2.5.29.31 ) , contiene una o más URLs para acceder a CRL / CSL . La URL se configura una ruta absoluta para acceder a la CRL . La extensión no está marcada crítica;
e) subjectKeyIdentifier (OID 2.5.29.14 ) , contiene la keyIdentifier valor . La extensión no se considera crítica .
2 . Otras extensiones se pueden incluir en el certificado siempre y cuando cumplan con las normas mencionadas en la presente resolución y no marcado «crítico» .
Artículo 7 . El uso de extensiones en los certificados de marcar el tiempo
1 . Los certificados de marca de tiempo contiene las siguientes extensiones:
a) keyUsage (OID 2.5.29.15 ) , contiene el valor digitalSignature (bit 0 puesto a 1 ) . La extensión está marcado crítico ;
b ) ExtendedKeyUsage (OID 2.5.29.37 ) , contiene el valor KeyPurposeID = timestamping . La extensión está marcado crítico ;
c ) certificatePolicies OID 2.5.29.32 ) , contiene uno o más identificadores de policyIdentifier y la dirección URL relativa del PSC . La extensión no está marcada crítica;
d ) authorityKeyIdentifier ( OID 2.5.29.35 ) , contiene al menos un keyIdentifier . La extensión no está marcada crítica;
e) subjectKeyIdentifier ( OID 2.5.29.14 ) , contiene al menos un keyIdentifier . La extensión no se considera crítica .
2 . Otras extensiones se pueden incluir en el certificado establecido de conformidad con las normas establecidas en la presente resolución y no marcado «crítico» .
Título IV . REGLAS PARA EL TIEMPO DE VALIDACIÓN
Artículo 8 . Reglas para los servicios de validación temporal
1 . El acceso a la prestación del servicio , de la validación temporal certificadores se realiza mediante el protocolo y formato definido en la especificación ETSI TS 101 861 V.1.2.1 , titulado «Perfil de la validación temporal» y RFC 3161 , según enmendada. Las marcas de hora enviados en respuesta al solicitante siguen las mismas normas .
2 . Certificadores poner a disposición o indican un sistema que permite la apertura , el análisis y la visualización de las marcas de tiempo a que se refiere el apartado 1. Este sistema funciona correctamente
estructuras y TimeStampToken TimeStampResp al menos en el formato individual, con verificación de firma y validación del sistema de la asociación temporal correcta , llevado a cabo por la función hash, el documento que se ha generado la misma marca de tiempo .
3 . La extensión asociada con la estructura y TimeStampToken TimeStampResp no debe afectar al buen funcionamiento del sistema mencionado en el apartado 2.
4 . El TimeStampToken debe incluir un identificador único de la política de seguridad en el que se generó el token. Dicho identificador, si no se define a nivel nacional
o europeo , se define y se hará público por el certificador .
Título V. INFORMACIÓN SOBRE LA REVOCACIÓN Y SUSPENSIÓN DE CERTIFICADOS
Artículo 9 . La verificación de los certificados – CRL
1 . La información sobre la revocación y suspensión de certificados , emitidos por los certificadores y disposición del público a través de la suspensión y las listas de revocación , tiene un formato compatible con RFC 3280, sección 5 , a excepción de las secciones 5.2.4 y 5.2.6 .
2 . Las listas de certificados revocados suspendidos y están disponibles al público a través de HTTP o LDAP.
Artículo 10 . Verificación en tiempo real de los certificados – OCSP
1 . No obstante lo dispuesto en el artículo 9 , los certificadores tienen el derecho de poner a disposición información sobre la revocación y suspensión de certificados a través de servicios de OCSP . En este caso , estos servicios deben cumplir con RFC 2560 y sus posteriores modificaciones .
Artículo 11 . La consistencia de la información sobre la revocación y suspensión de certificados
1 . Si un certificador ofrece varios servicios para acceder a la información sobre la revocación o suspensión de certificados o diferentes URL para acceder al mismo servicio , la información obtenida mediante el acceso a los distintos modos debe ser coherente si es compatible con la tecnología utilizada .
Título VI . FORMATOS DE FIRMA
Artículo 12 . Busta firma criptográfica
1 . El sobre criptográfica para contener el objeto se ajusta firmantes, salvo lo dispuesto en los párrafos 8 y 9 , RFC 2315 ( PKCS7 ver. 1.5 ) .
2 . El sobre criptografía se refiere el apartado 1 es de tipo signedData ( OID: 1.2.840.113549.1.7.2 ) .
3 . Para la codificación de envolvente criptográfico se puede utilizar formatos ASN.1 DER (ISO 8824 , 8825 ) o BASE64 (RFC 1421 ) .
4 . El documento que se firmará está envuelto en su formato original, sin pies ni cabeza añadido en el mismo formato .
5 . El nombre del archivo firmado , es decir, el sobre, toma la extensión adicional » p7m . »
6 . Los sobres criptográficos se refiere el apartado 5 , a su vez , pueden contener sobres criptográficos. En este caso se aplica a una extensión » p7m » más .
7 . La presencia de atributos autentificados en el sobre de cifrado no se considera crítico. La gestión de la misma no debe ser un obstáculo para la aplicación de la verificación a que se refiere el artículo 14.
8 . CNIPA puede establecer una medida ad hoc , tamaños más habituales de envoltura criptográfica , reconocido a nivel nacional o internacional , conforme a públicos específicos ( Especificación Públicamente Disponible PAS) .
9 . CNIPA puede suscribir memorandos de entendimiento específicos con el fin de poner a disposición de formatos de firma adicionales. Estos memorandos de entendimiento , deben incluir un compromiso por parte del suscriptor asegurar:
a) la disponibilidad de las especificaciones necesarias para el desarrollo del producto o verificación de las librerías necesarias para el desarrollo de productos para la verificación de la firma digital , de conformidad con el tema del Memorando de Entendimiento de generación y de software ;
b ) la ausencia de una carga financiera para los que desarrollar, implantar o utilizar los productos mencionados en el párrafo anterior ;
c ) la disponibilidad de cualquier cambio relativo a las disposiciones de la letra a) un avance de por lo menos 90 días a partir de la fecha de lanzamiento de nuevas versiones del producto que implementa el tamaño de sobre objeto criptográfico del Memorando de Entendimiento;
d ) la disponibilidad , sin cargo alguno para el uso personal de un producto para verificar las firmas digitales del tema del MoU y ver el documento electrónico está suscrito;
e) la capacidad de utilizar la información contenida en la lista pública de los certificadores en el artículo 41 de las normas técnicas y listas de revocación mencionadas en el artículo 29 de la citada medir en la verificación de los productos a que se refiere el párrafo anterior .
10 . Siempre que se cumplan las condiciones establecidas en el apartado 9, el CNIPA , previa consulta a las autoridades y asociaciones de la industria más representativa evaluar las solicitudes de suscripción de memorandos de entendimiento previstos en el párrafo citado más arriba teniendo en cuenta:
a) la importancia de las necesidades que pueden satisfacer ;
b ) la posibilidad de proporcionar el apoyo adecuado y la difusión apropiada en el mercado nacional e internacional de los productos que llevan la estructura de la información del documento firmado , a fin de ser reconocido y aceptado como la norma de referencia;
c ) la necesidad de evitar los efectos adversos sobre la interoperabilidad.
11 . Los gobiernos pueden aceptar documentos firmados con los formatos de firma que se hace referencia en los párrafos 8 y 9 y , si lo consideran conveniente aceptar uno o más de estos formatos tendrán que hacer una mención especial en los procedimientos administrativos a los que se apliquen y que lo comunique a CNIPA . Los poderes públicos garantizan el manejo del formato mencionado en el apartado 1.
12 . La persona que firma el Memorando de Entendimiento se refiere el apartado 9 se indican las direcciones de Internet CNIPA donde se puede obtener de forma gratuita y libremente , como se indica en las letras a) yd ) del mismo párrafo 9 ,
13 . CNIPA pone a disposición en su sitio web: la lista de formatos incluidos en memorandos de entendimiento , las direcciones de Internet que se refiere el párrafo 12, y los posibles formatos de envoltura criptográfica que
en el apartado 8 .
14 . En caso de incumplimiento por parte del suscriptor del memorando de entendimiento a lo dispuesto en los párrafos 9 y 12 CNIPA informará sin demora a la persona de que se trate y, si es el mismo no se ajusta rápidamente para el pleno cumplimiento de las disposiciones , revocar el memorando de entendimiento por dar publicidad a la lista mencionada en el párrafo 13 , e informar oportunamente al público
autoridades mencionadas en el párrafo 11 .
Artículo 13 . Reglas para el uso de múltiples firmas
1 . Un solo sobre criptografía puede contener firmas más digitales. Estos se identifican como :
a) «Firmas paralelas» , en cuyo caso el abonado , usando su propia clave privada , sólo los datos de la firma en el mismo sobre ( OID : 1.2.840.113549.1.7.1 ) ;
b ) » Firmas de «, en cuyo caso el suscriptor , usando su propia clave privada , la firma de una firma previa ( OID: 1.2.840.113549.1.9.6 ) fijado a otro abonado .
2 . El tamaño de varias firmas como se define en este artículo se ajusta a RFC 2315 .
3 . Se prohíbe la colocación de varias firmas que se refiere este artículo no exige la aplicación de extensiones adicionales al archivo firmado , además de la primera .
Título VII . APLICACIONES DE LA VERIFICACIÓN DE LA FIRMA
Artículo 14 . Requisitos para la solicitud de verificación
1 . Las solicitudes de verificación de la firma digital de un signo o distribuidos por las certificadoras acreditadas , de conformidad con el artículo 10 de las normas técnicas , además de gestionar adecuadamente los certificados electrónicos cuyo formato está establecido en la presente resolución , reconocer los siguientes elementos de los certificados reconocidos :
a) la extensión atributo DateOfBirth SubjectDirectoryAttributes ;
b ) los siguientes QcStatements :
1 ) Identificación – ETSI – sth- QcCompliance ( OID: 0.4.0.1862.1.1 );
2 ) Identificación – ETSI – sth- QcLimitValue ( OID: 0.4.0.1862.1.2 );
3 ) Identificación – ETSI – sth- QcRetentionPeriod ( OID: . 0.4.0.1862 1.3 );
4 ) Identificación del ETSI – sth- QcSSCD ( OID: 0.4.0.1862.1.4 ) .
2 . Además de los requisitos del apartado 1 anterior, las solicitudes de verificación de la firma digital de un signo o distribuidos por certificadores acreditados están a cargo de formatos de firma y sobres de cifrado que se refiere el artículo 12 , apartados 1 a 7 , y en el artículo 13 .
3 . Las solicitudes contempladas en este artículo manejar correctamente el proceso de verificación de firmas digitales producidas antes de la entrada en vigor de la presente resolución , que no pierden su validez específica.
Título VIII . DISPOSICIONES TRANSITORIAS Y FINALES
Artículo 15 . operación
1 . Esta decisión entrará en vigor con efectos a nueve meses a partir de la fecha de publicación en el Boletín Oficial.
2 . El requisito para utilizar UTF- 8 , según lo dispuesto en el RFC 3280, entrará en vigor nueve meses después de la entrada en vigor de la presente resolución .
3 . La obligación contemplada en el artículo 4 , apartado 5 , letra f ) comenzará a regir nueve meses después de la entrada en vigor de la presente resolución . Hasta esa fecha, si el certificado no contiene la extensión QCStatement valora id- ETSI – sth- QcCompliance -id ETSI – sth- QcSSCD , al menos uno de la política declarada de forma explícita en el certificado indica que el certificado es un certificado reconocido y que la clave privada correspondiente a la clave pública en el certificado reconocido se almacena en un dispositivo seguro para la generación de la firma cumple con la normativa .
4 . Durante el período de prórroga se refiere el apartado 3 , si el certificado no contiene la extensión QCStatement el valor id- ETSI – sth- QcLimitValue , límites en el comercio
insertado en el campo de atributo explicitText UserNotice .
5 . Las disposiciones del artículo 14 entrarán en vigor nueve meses después de la entrada en vigor de la presente resolución .
6 . Los certificados electrónicos expedidos antes de la entrada en vigor de la presente resolución seguirán siendo válidos hasta la fecha de vencimiento en el momento de la emisión , a menos que la revoque antes
o suspensión .
Roma, 17 de febrero 2005
El Presidente : Zoffoli
Todo es electrónico 