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