9 nov 2015

SSL Handshake



Excelente explicacion de como se lleva a cabo una comunicacion SSL entre el cliente (generalmente el navegador web) y un servidor.



Figure 2.

Figure 2. How SSL established connections, step-by-step


Fuente: Symantec

6 nov 2015

Install/Config AutoMysqlBackup

Install/Config AutoMysqlBackup #Backup #Ubuntu
  • Download script de backup from: http://bit.ly/uM0aGw
  • Subir archivo descargado al equipo TARGET
    • scp automysqlbackup-v3.0_rc5.tar.gz root01@x.x.x.x:/tmp
  • Descomprimir automysqlbackup-v3.0_rc5.tar.gz en /tmp
    • ssh root01@x.x.x.x
    • mkdir /tmp/AutoMysqlBackup/
    • tar xzvf automysqlbackup-v3.0_rc5.tar.gz -C /tmp/AutoMysqlBackup
  • Verificar/Instalar camandos para Netbios
    • Verificar si esta instalado mount.cifs :sudo dpkg -l | grep smbfs
    • Instalar Samba file system utilities sino esta: sudo apt-get install smbfs
  • Ejecutar install.sh
    • cd /tmp/AutoMysqlBackup
    • chmod +x install.sh
    • sudo su && ./install.sh
  • Configurar Script myserver.conf
    • sudo vi /etc/automysqlbackup/myserver.conf
    • Cambiar linea 18 a: CONFIG_mysql_dump_username='backupDB'
    • Cambiar linea 21 a: CONFIG_mysql_dump_password='algo'
    • Cambiar linea 31 a: CONFIG_backup_dir='/var/backups/db/[hostname]/db'
    • sudo mkdir -p /var/backups/db/
    • Cambiar linea 85 a: CONFIG_do_weekly="7"
      Which day do you want weekly backups? (1 to 7 where 1 is Lunes)
    • Descomentar linea 167
    • Cambiar linea 176 a: CONFIG_mysql_dump_create_database='yes'
    • mount.cifs //x.x.x./backup$ /var/backups/db/ -o domain=domain,user=backupusr,password=xxxxx
    • mkdir -p /var/backups/db/ubuntu-db01/db
    • Crear tarea programada para ejecutarlo
      • 1. Create a script as below called runmysqlbackup using the lines below:

      • #~~~~ Copy From Below Here ~~~~
      • #!/bin/sh
      • export PATH=$PATH:/usr/bin:/usr/local/bin:/bin
      • # Donde se va a guardar el backup. Este es un site remoto mount.cifs
      • to="/var/backups/db"
      • if [ -f ${to}/testigo.txt ]
      • then
      • /usr/local/bin/automysqlbackup /etc/automysqlbackup/myserver.conf
      • chown root.root /var/backup/db* -R
      • find /var/backup/db* -type f -exec chmod 400 {} \;
      • find /var/backup/db* -type d -exec chmod 700 {} \;
      • else
      • umount ${to}
      • mount.cifs //x.x.x.x/backup$ ${to} -o domain=domain,user=backupusr,password=xxxxxx
      • echo "DISPOSITIVO SIN FUNCIONAR ... SE INTENTARA DESMONTAR y MONTAR !!!!"
      • date
      • if [ -f ${to}/testigo.txt ]
      • then
      • /usr/local/bin/automysqlbackup /etc/automysqlbackup/myserver.conf
      • chown root.root /var/backup/db* -R
      • find /var/backup/db* -type f -exec chmod 400 {} \;
      • find /var/backup/db* -type d -exec chmod 700 {} \;
      • echo "REALIZANDO EXITOSAMENTE LA SINCRONIZACION !!!"
      • else
      • echo "NO SE PUEDE INGRESAR AL RECURSO ....."
      • date
      • fi
      • fi
      • #~~~~~ Copy To Above Here ~~~~

      • 2. Save it to a suitable location or copy it to your /etc/cron.daily folder.

      • 3. Make it executable, i.e. chmod +x /etc/cron.daily/runmysqlbackup.
  • Crear usuario de base de datos con super-privilegios
    • #>mysql -u root -p
    • mysql> create user 'backupDB'@'localhost' IDENTIFIED BY 'algo';
    • mysql> grant all privileges on *.* to 'backupDB'@'localhost' ;
    • mysql> flush privileges;
    • mysql>\q
  • Auto montar el recurso NetBios cuando inicia el equipo
    • sudo vi /etc/rc.local
      Agregar linea: /sbin/mount.cifs //x.x.x.x/backup$ /var/backups/db/ -o domain=domain,user=backupusr,password=xxxx

20 oct 2015

PKI - Normas y RFC.


Debido a lo entramado de las normas/estándares que rigen el mundo de la PKI y en consecuencia los servicio basados en esta, me veo en la obligación de acomodarme un poco las ideas y tomar algunas referencias.

Estándares tecnológicos según la Jefatura de Gabinete de Ministros de la República Argentina

RFC 5280: Perfil de Certificado y lista de certificados revocados (CRL)
RFC 3739: Perfil de Certificado emitido a personas físicas
RFC 2560: OCSP
RSA, ECDSA, DSAM: Algoritmos para la generación del par de clave publica-privada
FIPS: Requisitos de seguridad para módulos de seguridad (Gobierno de USA)

Lo anterior, muy escueto comparado con el listado de Normas Técnicas del ministerio de economía de Chile.  Puntualmente lo que me interesa,  un indicio de las normativas que se aplican a TimeStamping.

e) Sellado de Tiempo/Time stamping:

ETSI TS 102 023, v.1.2.1 y v.1.2.2.
Electronic Signatures and Infrastructures (ESI);
Policy requirements for time-stamping authorities.

ETSI TS 101 861 V1.3.1 Time-stamping profile.

  • ISO/IEC 18014-1:2008 Information technology – Security techniques
- Time-stamping services – Part 1: Framework.
  • ISO / IEC 18014-2:2009 Information technology – Security techniques 
– Time-stamping services – Part 2: Mechanism producing independent tokens.
  • ISO / IEC 18014-3:2009 Information technology – Security techniques 
– Time-stamping services – Part 3: Mechanisms producing linked tokens.

RFC 3161 Internet X.509 Public Key Infrastructure Time – Stamp Protocol (TSP) (2001),
describes the format of a request sent to a Time Stamping Authority (TSA) 
and of the response that is returned

RFC 5816 (update), ANSI ASC X 9.95.
This document updates RFC 3161.  It allows the use of ESSCertIDv2, as
defined in RFC 5035, to specify the hash of a signer certificate when
the hash is calculated with a function other than the Secure Hash
Algorithm (SHA-1).

RFC 3628 Requirements for Times Stamping Authorities.
Este documento define los requisitos para una politica base de sellado de tiempo, para una autoridad de Sellado de tiempo, emitiendo tokens de sello de tiempo, soportado por certificados de clave publica, con una presicion de un segundo o mejor.
NIST Special publication 800-102, Sept.2009.


La siguiente la halle googleando, y lo interesante de esta en el  "Anexo A"

ETSI ETSI TS 102 176-1 V2.0.0 (2007-11)
Electronic Signature and Infraestructure (ESI) 
Algorithms and Parameters for Secure Electronic Signatures; 
Part 1:Hash function and asymmetric algorithms
Mil veces me he preguntado:

¿Cuales son el grupo de  RFCs y normas sostiene el estándar x509 y la PKI ?
¿ Que puedo tomar como referencia si necesito escribir documentos relacionados a certificados x509 o servicios relacionados a la PKI ?

La respuesta a mi entender comienza por aquí, con el conglomerado de normas que circunscriben a la PKI: http://www.oasis-pki.org/resources/techstandards/

17 sept 2015

Cipher.exe is a command-line tool that you can use to manage encrypted data by using the Encrypting File System (EFS). As of June 2001, Microsoft has developed an improved version of the Cipher.exe tool that provides the ability to permanently overwrite (or "wipe") all of the deleted data on a hard disk.

Fuente: https://support.microsoft.com/en-us/kb/298009

18 jun 2015

RFC 3628 Requisitos para Política de Autoridades de Sellado de Tiempo (TSA)

Mi aporte a este mundo, no soy traductor de profesión, así que van a encontrar errores seguro, si quieren colaborar tienen los comentarios para hacerlo.

Abstract

Este documento define los requisitos para una politica base, de sellado de tiempo, para una autoridad de Sellado de tiempo, emitiendo tokens de sello de tiempo, suportado por certificados de clave publica, con una presicion de un segundo o mejor.

Índice


1.- Introducción
2.  Visión Global
2.1 Referencias
3.  Definición y abreviaciones
3.1.  Definiciones
3.2.  Abreviaciones
4.-  Conceptos generales
4.1.  Servicio de Sellado de Tiempo
4.2.  Autoridad de Sellado de Tiempo
4.3.  Suscriptor
4.4.  Política de Sellado de Tiempo y Declaración de Prácticas de la TSA.
4.4.1.  Propósito
5.  Time-Stamp Policies
5.1.  General
5.2.  Identificación
5.3.  Comunidad de Usuarios y Aplicabilidad
5.4.  Conformidad/Cumplimiento
6- Obligaciones y Responsabilidades
6.1- Obligaciones de la TSA
6.1.1- General
6.1.2- Obligación de la TSA hacia los suscriptores
6.2- Obligaciones del suscriptor
6.3. Obligaciones de partes confiantes.
6.4 Responsabilidad
7.  Requerimientos sobre las prácticas de la TSA
7.1.  Prácticas y declaración de divulgación
7.1.1 Declaración de prácticas de la TSA
7.1.2.  Declaracion TSA Disclosure Statement (Declaracion de divulgacion de la TSA | Divulgacion legal de informacion )
7.2 Administración del ciclo de vida de las claves.
7.2.1 Generación de la clave de la TSA
7.2.2.  Protección de la clave privada de la TSU.
7.2.3.  Distribución de la clave pública de la TSA
7.2.4.  Rekeying TSU's Key
7.2.5. Fin del ciclo de vida de la TSU
7.2.6. Administración del ciclo de vida del modulo criptografico usado para firmar Sellos de tiempo.
7.3.  Sello de Tiempo
7.3.1.  Token de Sello de Tiempo
7.3.2.  Sincornizacion de Reloj con UTC.
7.4.  Operacion y Gestion de la TSA
7.4.1.  Gestión de la Seguridad
7.4.2.  Gestion y clasificacion de Activos
7.4.3.  Seguridad del Personal
7.4.4.  Seguridad fisica y del entorno.
7.4.5.  Gestion de la Operaciones
7.4.6.  Administración del sistema de control de acceso
7.4.7.  Trustworthy Systems Deployment and Maintenance
7.4.8.  Compromise of TSA Services
7.4.9.  TSA Termination
7.4.10.  Compliance with Legal Requirements
7.5.  Organizational
8.  Consideraciones de Seguridad
9.  Acknowledgments
10.  References



1.- Introducción


Para la creación de evidencia digital confiable es necesario disponer de un método que permita demostrar que una serie de datos han existido y no han sido alterados desde un instante específico en el tiempo, para ser comparado posteriormente unos con otros.


Toda autoridad competente que quiera gestionar una Autoridad de Sello de Tiempo en el territorio de la provincia de San Luis deberá cumplimentar los establecido en el presente documento y adherir al convenio con el ente regulador de la provincia que corresponda. [a]



2.  Visión Global


Los requisitos de esta política están dirigidos al servicio de sellado de tiempo usado en soporte de firma digitales reconocidas, pero puede ser aplicada a los requisitos de de cualquier aplicación  para probar existencia de un dato antes de un tiempo particular.
  
Los requisitos de esta política están basados sobre el uso de criptografía de clave pública, certificados de clave pública y fuentes de tiempo confiables.
El presente documento puede ser usado por cuerpos independientes como la base para confirmar que una TSA puede ser confiable para proveer servicio de sellado de tiempo.
  
Este documento direcciona los requerimientos para sincronizar la TSA emitiendo tokens de sello de tiempo con Coordinated universal time (UTC) y la firma digital por las TSUs.


2.1 Referencias


En lo referente Para la confección
3.  Definición y abreviaciones


3.1.  Definiciones
  
   Para el propósito de este documento los siguientes término y definiciones aplican:
  
   NOTA: Donde una definición es copiada desde un documento de referencia
   esto es indicado por la inclusión de un número de identificador de
   referencia al final de la definición.


   Terceras parte: receptor de un token  de sello de tiempo quien
             confía en este token de sello de tiempo.
            
   suscriptor: entidad requiriendo el servicio provisto por una TSA y cual
             está explícitamente o implícitamente de acuerdo a sus términos y
             condiciones.


   token de sello de tiempo: objeto de datos
  
   time-stamp token: data object that binds a representation of a datum
             to a particular time, thus establishing evidence that the datum
             existed before that time.


   autoridad de sellado de tiempo: autoridad cual emite token de sellado
            de tiempo.


   Declaración de divulgación de la TSA: conjunto de declaraciones sobre
             las políticas y prácticas de la TSA que particularmente requieren
             énfasis o de la divulgación a los suscriptores y terceras partes
             de confianza,por ejemplo para cumplir con requisitos regulatorios.
            
   Declaración de prácticas de la TSA: declaración de prácticas que una TSA
             emplea para la emisión de tokens de sello de tiempo.


   Sistema TSA: composición de productos de tecnologías de la información
             y componentes organizados para soportar la provisión del servicio
             de sellado de tiempo.


   Políticas de sellado de tiempo: conjunto de reglas que indican
             la aplicabilidad de un token de sello de tiempo para un comunidad
             particular y/o clase de aplicación con requerimiento de seguridad
             comunes.
  
   Unidad de sellado de tiempo: conjunto de hardware y software que es
             administrado como una unidad y tiene una sola clave de firma
             para el token de sello de tiempo activa a la vez.
  


   Coordinated Universal Time (UTC): escala de tiempo basada sobre la segundo
             como se define en las recomendaciones ITU-R TF.460-5 [TF.460-5].


             NOTE: para propósitos más prácticos UTC es equivalente al tiempo
             solar en el primer meridiano. Más específicamente, UTC es el
             compromiso entre el altamente estable tiempo atómico (Temps
             Atomique International - TAI) y tiempo solar derivado de la
             rotación irregular de la tierra.
            
            
3.2.  Abreviaciones


   Para el propósito del presente documento, las siguientes abreviaciones aplican:


          TSA  Autoridad de Sellado de Tiempo
          TSU  Unidad de Sellado de Tiempo
          TST  Token de Sellado de Tiempo
          UTC  Hora Universal Coordinada



4.-  Conceptos generales


4.1.  Servicio de Sellado de Tiempo


   La entrega del servicio de sellado de tiempo es dividida en los siguientes servicios componentes, para el propósito de los requerimientos de clasificación:
  
   -  Time-stamping provision: este servicio componente genera los
          los token de sello de tiempo.
         
   -  Time-stamping management: el servicio componente que monitorea
          y controla las operaciones del servicio de sellado de tiempo para
          garantizar que el servicio es provistos como lo especifica la TSA.
          Este servicio componente es responsable por la instalación y
          desinstalación de los servicios de provisión de sellos de tiempo (
          Time-stamping provisión). Por ejemplo, la administración del sellado
          de tiempo garantiza que los relojes usados para el sellado de tiempo
          están correctamente sincronizados con UTC.
         
   Esta subdivisión de servicios es solamente para propósitos de clarificación
   de los requisitos especificados en el corriente documento y no coloca
   restricciones para cualquier otra subdivisión en la implementación del
   servicio de sellado de tiempo.


4.2.  Autoridad de Sellado de Tiempo


   La autoridad a emitir "tokens" de sello de tiempo, de confianza para
   el usuario del servicio de sellado de tiempo (ej: suscriptores y
   terceras parte de confianza) es llamada Autoridad de Sellado de Tiempo
   (TSA). La TSA tiene la responsabilidad absoluta por el servicio de
   sellado de tiempo, identificados en la cláusula 4.1.
   La TSA tiene la responsabilidad por la operación de una o más TUS que
   crea y firma en nombre de la TSA. La TSA responsable de emitir un token
   de sello de tiempo es identificable (véase 7.3.1 h).
  
   La TSA puede utilizar otras partes para proporcionar partes de los
   servicios de sellado de tiempo. Sin embargo, la TSA siempre mantiene
   la responsabilidad total y asegura que se cumplen los requisitos de las
   políticas identificadas en el presente documento. Por ejemplo, una TSA
   podrá subcontratar todos los servicios de componentes, incluidos los
   servicios que generan tokens de sello de tiempo utilizando las claves
   de la TSU. Sin embargo, la clave privada o claves utilizadas para generar
   las tokens de sello de tiempo pertenecen a la TSA que mantiene la
   responsabilidad total de cumplimiento de los requisitos de este documento.


   Una TSA puede operar varias unidades identificables de sellado de tiempo.
   Cada unidad tienen una clave diferente. Ver Anexo B para posibles
   implementaciones.
   Una TSA es un proveedor de servicio de certificación, como se define
   en EU Directive on Electronic Signatures (see article 2(11)), que emite
   tokens de sello de tiempo.


4.3.  Suscriptor


   El suscriptor puede ser una organización que comprende varios usuarios
   finales o un usuario individual.
   Cuando el suscriptor es una organización, algunas de las obligaciones
   que aplica a esta organización, tendrán que aplicarse también a los
   usuarios finales. En cualquier caso la organización será la responsable.
  
   Cuando el suscriptor es una organización, alguna de las obligaciones que
   aplica a la organización tendrá que aplicar también a los usuarios
   finales. En cualquier caso la organización se hace responsable sino se
   cumplen correctamente las obligaciones de los usuarios finales y por lo
   tanto se espera que la organización informe adecuadamente a sus usuarios
   finales.
   Cuando el suscriptor es un usuario final, éste será directamente el
   responsable si sus obligaciones no son completamente cumplidas.
  
4.4.  Política de Sellado de Tiempo y Declaración de Prácticas de la TSA.


   Esta sección explica lo relativo a los roles de la política de sellado
   de tiempo y a la declaración de prácticas de la TSA.
   Esto no coloca restricciones específicas sobre la
   política de sellado de tiempo o la declaración de prácticas.
  
4.4.1.  Propósito


   En general, política de sellado de tiempo establece "a lo que hay que adherirse", mientras una declaración de prácticas de TSA
   establece "la forma de cómo se adhiere", ejemplo: el proceso que se utilizara
   para la creación de sellos de tiempo y mantenimiento de la precisión
   de su reloj. La relación entre la política de sellado de tiempo y la
   declaración de prácticas de la TSA es de naturaleza similar a la
   relación a otras políticas empresariales cuales indican los requisitos
   de la empresa, mientras las unidades operaciones definen las prácticas
   y procedimientos de cómo estas políticas son llevadas a cabo.
  
   El presente documento especifica una política de sellado de tiempo para
   cumplir con los requisitos para un servicio de sellado de tiempo
   confiable. TSAs especifican en su declaración de prácticas de TSA como
   estos requisitos son llevados a cabo.




4.4.2.  Nivel de Especificación


   La declaración de práctica de las TSA es más específica que una política
   de sellado de tiempo. Una declaración de prácticas de la TSA es una
   descripción más detallada de los términos y condiciones así como las
   prácticas empresariales y operativas de una TSA en emitir y gestionar
   de otra forma los servicios de sellado de tiempo. La declaración de
   prácticas de una TSA refuerza las reglas estabilizadas por una política
   de sellado de tiempo. Una declaración de prácticas de TSA define como
   una TSA específica, cumple los requisitos técnicos, organizacionales y
   procedimentales identificados en la política de sellado de tiempo.


   NOTA: Incluso la documentación interna de bajo nivel puede ser apropiada
   para un TSA que detalla los procedimientos específicos necesarios para
   completar las prácticas identificadas en la declaración de prácticas de
   TSA.




4.4.3.  Enfoque
  
   El enfoque de una política de sellado de tiempo es significativamente
   diferente a declaración de prácticas de TSA. Una política de sellado
   de tiempo es definida independientemente de los detalles específicos
   del ambiente de operaciones de una TSA, mientras que la
   declaración de prácticas de la TSA se adapta a la estructura
   organizativa, procedimientos operacionales, comodidades y ambiente
   computacional de la TSA. Una política de sellado de tiempo puede ser
   definida por el usuario de servicio de sellado de tiempo, mientras que la
   declaración de prácticas de la TSA es siempre definida por el proveedor.




5.  Time-Stamp Policies


5.1.  General


   Una política de sellado de tiempo es un "llamado conjunto de reglas
   que indican la aplicabilidad de un token de sello de tiempo a una comunidad
   particular y/o clase de aplicación con requerimientos comunes de seguridad"
   (ver cláusula 3.1 and 4.4).


   El presente documento define requisitos de base para una política
   de sello de tiempo emitiendo tokens de sello de tiempo, soportado por
   certificados de clave pública, con una precisión igual a mejor a un segundo.


   Nota 1: Sin medidas adicionales, la parte confiante puede no ser capaz
   de garantizar la validez de un token de sello de tiempo más allá del fin
   del período de validez que soporta el certificado. Ver anexo C sobre la verificación de la  
   validez de token de sello de tiempo luego del periodo de validez del certificado de las
  TSU’s.


   Una TSA pude definir su propia política la cual mejora la política definida
   en este documento. Tal política debe incorporar o restringir aún más los
   requisitos identificados en este documento.


   Si la TSA provee una precisión mejor a un segundo, y si todas
   las TSUs tienen la misma característica, entonces la precisión debe ser
   indicada en la declaración de divulgación de la TSA (sección 7.1.2) que
   cada token de sello de tiempo es emitido con una precisión mejor a
   un segundo.
  
   NOTE 2: Es requerido que el token de sello de tiempo incluye un identificador
   para la política aplicable (sección 7.3.1)




5.2.  Identificación


   El identificador de objeto [X.208] de la política base de sellado
   de tiempo es:
   itu-t(0) identified-organization(4) etsi(0) time-stamp-policy(2023)
   policy-identifiers(1) baseline-ts-policy (1)


   En la declaración de divulgación TSA puesto a disposición de los
   suscriptores y partes de confianza, una TSA también incluirá el
   identificador de la política de sello de tiempo para indicar su
   conformidad.


5.3.  Comunidad de Usuarios y Aplicabilidad
  
   Esta política está dirigida a satisfacer los requisitos de sellado
   de tiempo de la firma digital, para períodos de validez de largo
   plazo, pero es generalmente aplicable a cualquier requisito
   de calidad equivalente.
   Esta política puede ser usada por el servicio público de sellado
   de tiempo o por una comunidad cerrada.
  
5.4.  Conformidad/Cumplimiento


   La TSA debe usar el identificador de la política de sellado de tiempo  en los tokens de sello
   de tiempo, como se muestra en la sección 5.2 ó definir su propia política de sellado de
   tiempo, que incorpore o restrinja aún más los requisitos identificados en este documento:


   a) Si la TSA afirma conformidad con el identificador de la política de sellado de tiempo y
   pone a disposición de los suscriptores y terceras partes confiantes la solicitud que evidencia la conformidad referenciada;


   b) Si la TSA ha sido evaluada para cumplir con la política de sello de tiempo identificada por una tercera parte independiente.


   Una TSA que cumple debe demostrar que:
  
   a) este cumple sus obligaciones como se define en la sección 6.1;
   b) este ha implementado controles cual cumple con los requisitos especificados en la
   sección 7.
 


6- Obligaciones y Responsabilidades


6.1- Obligaciones de la TSA
   
6.1.1- General


- La TSA debe asegurar que todos los requerimientos sobre la TSA, como se detalla en la
  sección 7, son implementados como aplicables a la seleccionada política de sellado de tiempo.
- La TSA debe asegurar conformidad con los procedimientos prescrito en esta política, incluso,  cuando la funcionalidad de la TSA sea realizada por subcontratistas.
- La TSA debe también asegurar adherencia a cualquier obligación adicional indicada en el sello de tiempo directa o incorporado por referencia.
- La TSA debe proveer todo sus servicios de sellado de tiempo consistente con su declaración de prácticas.
           
6.1.2- Obligación de la TSA hacia los suscriptores


   La TSA debe cumplir obligaciones como declara en sus términos y condiciones,
   incluyendo la disponibilidad y precisión de sus servicios.
           
6.2- Obligaciones del suscriptor


   El presente documento no especifica obligaciones del suscriptor mas alla del estado de
   cualquier requerimiento específico de la TSA, en los términos y condiciones.
   Nota: es recomendable que cuando se obtenga el token de sello de tiempo, el suscriptor
   verifique que el token de sello de tiempo ha sido correctamente firmado y que la clave
   privada usada para firmar el token de sello de tiempo no haya sido comprometida.
           
6.3. Obligaciones de partes confiantes.


   Los términos y condiciones disponibles para las partes confiantes (ver sección 7.1.2)
   deben incluir obligación sobre las terceras partes que, cuando confía en un token de
   sellado de tiempo, este deberá:
   a) verificar que el token de sellado de tiempo ha sido correctamente firmado y que la clave privada  usada para firmar el sello de tiempo no ha sido comprometida hasta el tiempo de la verificación.


   NOTA: durante la validez del certificado de la TSU, la validez de la clave de firma puede ser chequeada usando el estado de revocación para el certificado de la TSU. Si el tiempo de verificación excede el fin del periodo de validez del correspondiente certificado, ver anexo C como guia.[b]
   b) Tener en cuenta cualquier limitación sobre el uso de sellos de tiempos indicados por la política de sello de tiempo.
   c) Tomar en cuenta cualquier otra precaución prescripta en acuerdos o en otra parte.
                           
6.4 Responsabilidad


   El presente documento no especifica ningún requerimiento sobre responsabilidades.
   En particular, debe destacarse que una TSA puede rechazar o limitar cualquier responsabilidad a menos que esté estipulado por las leyes aplicables.
           
7.  Requerimientos sobre las prácticas de la TSA


    La TSA deberá implementar los controles que cumplan los siguientes requsitos.
   
Los requisitos de esta política no pretenden implicar ninguna restricción sobre
    el cobro por los servicios de la TSA.
   
    Los requisitos son indicados en términos de objetivos de seguridad, seguido por
    requerimientos más específicos, para el control, para cumplir aquellos objetivos donde es
    necesario proveer confianza de los objetivos serán satisfechos.


    Nota: los detalles de los controles requeridos para satisfacer un objetivo es balanceado,
    entre, lograr la confianza necesaria, mientras minimiza las restricciones sobre las técnicas que una TSA puede emplear en la emisión de tokens de sellado de tiempo. En el caso de la sección 7.4 (administración y operación de la TSA), se hace referencia a una fuente más detallada de requisitos de control. Debido a estos factores, la especificación de los requisitos dados bajo un determinado tema, puede variar.
   
    La provisión de un token de sellado de tiempo, en respuesta a un requerimiento, es a criterio de la TSA , dependiendo del acuerdo de nivel de servicio con el suscriptor.
   
    7.1.  Prácticas y declaración de divulgación
   
    7.1.1 Declaración de prácticas de la TSA


    La TSA debe asegurar, que esta demuestra fiabilidad necesaria, para proveer servicios de sellado de tiempo.


    En particular:
   
    a) La TSA debe tener  una evaluación de riesgos llevada a cabo con el fin de evaluar activos del negocio y amenazas para aquellos activos en el orden de determinar los controles de seguridad necesarios y procedimientos operacionales.


    b) La TSA debe tener una declaración de las prácticas y procedimientos usado para direccionar todos los requerimientos identificado en esta política de sellado de tiempo.
    Nota1: esta política no hace requerimientos en cuanto a la estructura de la declaración de prácticas de la TSA.


    c) La declaración de práctica de la TSA debe identificar las obligaciones de todas las organizaciones externas soportando los servicios de la TSA, incluyendo las políticas y prácticas aplicables.


    d) La TSA debe poner a disposición de los suscriptores y terceras partes (partes confiantes) su declaración de prácticas y otra documentación relevante, como necesaria para evaluar conformidad a la política de sellado de tiempo.


Nota2: la TSA generalmente no está obligada a hacer público todos los detalles de su política.


    e) la TSA debe divulgar a todos los suscriptores y terceras partes los términos y condiciones con respecto al uso del servicio  de sellado de tiempo como se especifica en la sección 7.1.2.
    f) La TSA debe tener un comité ejecutivo con autoridad suficiente para aprobar la declaración de prácticas de la TSA.
    g) El senior managment de la TSA debe asegurar que las prácticas son propiamente implementada.
    h) La TSA debe definir un proceso de revisión para las prácticas incluyendo responsabilidades para el mantenimiento de la declaración de prácticas de la TSA.
    i) La TSA dará la debida notificación de los cambios que se propone hacer en su declaración de prácticas y deberá seguido a la aprobación (punto f)  ponerla inmediatamente a disposición, como lo requiere el punto d.


7.1.2. Declaración de Divulgación de la TSA


La  TSA debe notificar a todos los suscriptores y potenciales terceras partes confiantes, los términos y condiciones con respecto al uso del servicio de sellado de tiempo. Esta declaración deberá al menos especificarse para cada una de las políticas soportadas por la TSA:


a) Información de los contactos de la TSA
b) La política de sellado de tiempo siendo aplicada.
c) El último algoritmo de hash que puede ser usado para representar el digesto de datos, a ser sellado. (No hash algorithm is mandated).
d) El tiempo de vida de la firma, usado para firmar el token de sellado de tiempo (depende del algoritmo de hash siendo usado, el algoritmo de firma siendo usado y la longitud de la clave privada).
e) La precisión del tiempo en los tokens de sellado de tiempo con respecto al UTC.
f) Cualquier limitación sobre el uso del servicio de sellado de tiempo.
g) Las obligaciones del suscriptor como se define en la sección 6.2 .
h) Las obligaciones de las terceras partes confiantes, como se define en la sección 6.3 .
i) Informacion de como verificar los tokens de sellado de tiempo, tal que las terceras partes
confiantes se considere una "tercera parte responsable" sobre los token de sello de tiempo (sección 6.3) y cualquier posible limitación sobre el periodo de validez.
j) El periodo de tiempo durante el cual los logs de eventos serán retenidos (Ver sección 7.4.10).
k) El sistema legal aplicable, incluyendo cualquier reclamo para cumplir los requerimientos sobre el servicio de sellado de tiempo, bajo las leyes nacionales.
l) Limitaciones de responsabilidades.
m) Procedimientos para quejas y solución de controversias.
n) Si la TSA ha sido auditada para satisfacer la política de sellado de tiempo, y de ser así, qué organismo independiente lo realizó.
 Nota1: Es también recomendable que la TSA incluya en su declaración de divulgación la disponibilidad de su servicio, por ejemplo el tiempo medio de espera entre fallas del servicio de sellado de tiempo, tiempo medio de recuperación seguido a una falla, y las provisiones hechas para recuperaciones ante desastres, incluyendo los servicios de backup.
   
Esta información debe estar disponible a través de medios de comunicación durables. Esta información debe estar en un lenguaje entendible. Esta puede ser transmitida electrónicamente.
   
Nota2: Un modelo de declaración (TSA disclosure statement) cual puede ser usado como la base de esta comunicación, se encuentra en el anexo D. Alternativamente este puede provisto en el acuerdo con suscriptores y terceras partes confiantes. Esta declaración puede ser incluida en la  declaración de prácticas provista, que son visibles para el lector.


7.2 Administración del ciclo de vida de las claves.


7.2.1 Generación de la clave de la TSA


La TSA debe asegurar que todas sus claves criptográficas son generadas bajo circunstancias controladas.


En particular:


a) La generación de la clave/s de firma de la TSU debe ser realizado en un ambiente físico seguro (ver 7.4.4) por personal con roles de confianza, bajo al menos un control doble. El personal autorizado a llevar a cabo esta función deberá ser limitado a aquellos que sean requeridos para hacerlo, bajo las prácticas de la TSA.
b) La generación de la clave de firma debe ser llevada dentro de un módulo criptográfico que o bien:
    - Cumpla los requisitos identificados en FIPS 140-1
    - Cumpla con los mensajes identificados en CEN Workshop Agreement 14167-2
    - Es un sistema digno de confianza cual está asegurado para EAL4 o superior de acuerdo a la ISO 15408, o algún criterio de seguridad equivalente. This shall be to a security target or protection profile which meets the requirements of the current document,         based on a risk analysis and taking into account physical and other non-technical security measures.
c) EL algoritmo de generación de clave de la TSU, la longitud de la clave de firma y el algoritmo de firma usado para firmar los token de sello de tiempo deben ser reconocidos por cualquier organismo nacional de supervisión o concordar con el actual estado del arte, as being fit for the purposes of time-stamp tokens as issued by the TSA.




7.2.2.  Protección de la clave privada de la TSU.[c]


   La TSA debe asegurar que las claves privadas de la TSU se mantiene confidencial y mantiene su integridad.


En particular:
  
   a) La clave privada de firma de la TSU será conservada y usada dentro de un módulo criptográfico cual:


          -  cumple los  requerimientos identificados en FIPS 140-1 level 3 or superior; o


          -  cumplir con los requerimientos identificados en CEN Workshop Agreement 14167-2 [CWA 14167-2]; o


          -  es un sistema confiable cual es asegurado a EAL4 o superior de acuerdo a la ISO 15408, o equivalente criterio de seguridad. Este será un objetivo de seguridad o perfil de protección cual cumple los requerimientos de este documento, basado sobre análisis de riesgos y tomando en cuenta medidas de seguridad física y otras no técnicas.


          NOTA: Backup de la clave privada de la TSU está en desuso para evitar minimizar los riesgos de compromiso de la clave.


   b) Si la clave privada de la TSU son backepeada, esta debe ser copiada, almacenada y recuperado sólo por personal en los puesto  de confianza, usando un control dual en un ambiente físicamente seguro (ver 7.4.4). El personal autorizado a llevar esta función
   debe ser limitado a aquellos requeridos para hacerlo las prácticas de la TSA.
   c) Cualquier copia de backup de la clave privada de firma de la TSU debe estar protegida para asegurar su confidencialidad por un módulo criptográfico antes de ser almacenada fuera del dispositivo.


7.2.3.  Distribución de la clave pública de la TSA


  La TSA debe asegurar que la integridad y autenticidad de la firma de la TSU, verificando las claves (pública) y cualquier parámetro asociado que sea mantenido durante su distribución a las terceras partes confiantes.
  
   En particular:


   a) Las verificacion de las claves (pública) de la TSU debe estar disponible a las terceras partes confiantes dentro del certificado de clave pública.
        Nota: por ejemplo, el certificado de las TSU's puede ser emitido
          por una autoridad de certificación operado por la misma organización
          que la TSA, o emitida por otra autoridad.
 
   b) La verificación de la firma de los certificado de clave pública
          de las TSUs deben ser emitidos por una autoridad de certificación
          operada bajo una política la cual provea un nivel de seguridad
          equivalente o mayor que esta política de sellado de tiempo.
         
7.2.4.  Rekeying TSU's Key


     El tiempo de vida del certificado de la TSU no debe mayor al tiempo de
   vida reconocido para el algoritmo y la longitud de la clave. (see section 7.2.1c).
   NOTE 1: Las siguientes consideraciones aplican cuando se limita el tiempo de vida:
  
   - Section 7.4.10 requires that records concerning time-stamping services shall be held for a period of time,as appropriate, for at least 1 year after the expiration of the validity of the TSU's signing keys. The longer the validity period of the TSU certificates will be, the longer the size of the records to be kept will be.
        
   - Should a TSU private key be compromised, then the longer the
         life-time, the more affected time-stamp tokens there will be.


         NOTE 2: El compromiso de la clave de la TSU no solamente depende de
         las características del módulo criptográfico siendo usado, sino también
         del procedimiento siendo usado en la inicialización del sistema y exportación
         de clave (cuando esta función es soportada)










7.2.5. Fin del ciclo de vida de la TSU


   La TSA debe asegurarse que la clave privada de la TSU no es usada luego del fin de su ciclo de vida. En particular:


   a) Procedimientos operacionales o técnicos deben asegurar que la nueva
   clave es colocada en su lugar cuando la clave de la TSU expira.


   b) La clave privada de la TSU, o cualquier parte incluyendo copias deben
   ser destruidas tal que la clave privada no puede ser recuperada.


   c) El sistema de generacion de token de sellado de tiempo debe rechazar
   cualquier intento de emitir tokens si la clave privada de firma ha expirado




7.2.6. Administración del ciclo de vida del modulo criptografico usado para firmar Sellos de tiempo.


   La TSA velara por la seguridad de su hardware de seguridad a lo largo
   de su ciclo de vida.
  
   En particular la TSA velara por que:


   a) El hardware criptografico para firma de tokens de sellos de tiempo no ha sido
   manipulado/alterado durante su translado.


   b) El hardware criptografico para firma de tokens de sellos de tiempo no ha sido
   manipulado/alterado mientras estaba almacenado.


   c) Instalacion, activacion y duplicacion de la clave de firma de la TSU en el hardware
   criptografico debe ser realizado solo por personal con roles adecuados de confianza,
   usando controles duales en un ambiente fisicamente seguro (ver 7.4.4).


   d) El hardware criptografico para firma de tokens de sellos de tiempo esta funcionando
   correctamente; y


   e) La clave privada de firma de la TSU (almacenada en el modulo criptografico) son
   eliminadas cuando el modulo es retirado.




7.3.  Sello de Tiempo


7.3.1.  Token de Sello de Tiempo


   La TSA debe asegurad que los token de sello de tiempo son emitidos de forma segura e incluye un tiempo correcto.
  
   En particular:


   a) El token de sellado de tiempo debe incluir un identificador para la politica de sellado de tiempo;


   b) Cada token de sello de tiempo debe tener un identificador unico;


   c) Los valores de tiempo que la TSU use en los token de sello de tiempo deben ser  trazable al menos uno de
   los valores de tiempo real distribuido por un laboratirio UTC.

          NOTE 1: The Bureau International des Poids et Mesures (BIPM)
          computes UTC on the basis of its local representations UTC(k) from
          a large ensemble of atomic clocks in national metrology institutes
          and national astronomical observatories round the world.  The BIPM
          disseminates UTC through its monthly Circular T [list 1].  This is
          available on the BIPM website (www.bipm.org) and it officially
          identifies all those institutes having recognized UTC(k) time
          scales.


   d) El tiempo incluido en los token de sello de tiempo deben estar sincornizados con UTC dentro de
          la presicion definida en esta politica y, si esta presente, dentro de la presicion definida
          en el propio token de sello de tiempo.


   e) Si se detecta que el proveedor de hora de los sellos de tiempo (ver 7.3.2 c), comienza estar
          fuera de la presicion establecida (ver 7.1.2 e) el token de sello de tiempo no debe ser emitido.
  
   f) El token de sello de tiempo debe incluir una representacion (ej.valor hash)
          de dato que es time-stamped, como es proporcionado por el solicitante;


   g) El token de sellado de tiempo debe ser firmado usando una clave generada exclusivamente para
          este proposito.
         
          NOTE 2: Un protocolo para un token de sello de tiempo es definido en la RFC 3631
          y el perfil en TS 101 861 [TS 101861].


          NOTE 3: En el caso de un numero de solicitantes en aproximadamente el mismo tiempo, el
          orden del tiempo dentro de la presicion del reloj de la TSU no es mandatorio.
         
   h) El token de sello de tiempo debe incluir:


          -  donde aplique, un identificador para el pais en el cual la TSA esta establecida;
          -  un identificador para la TSA;
          -  un identificador para la unidad que emite el sello de tiempo.


7.3.2.  Sincornizacion de Reloj con UTC.


   La TSA debe asegurar que su reloj esta sincronizado con UTC, dentro de la
   presicion declarada.


   En particular:


   a) La calibracion del reloj de la TSU debe ser mantenido de tal forma
          que el reloj no tenga una desvicion mayor a la presion declarada.


   b) Los relojes de la TSU deben estar protegidos contra amenzas que pudieran
          resultar en un cambio indetectable al reloj externo del cual
          toma su calibracion.
         
          NOTE 1: amenzas pueden incluir manipulacion por personal no autorizado,
          interferencias de radio o electricas.
         
   c) La TSA debe asegurar que, si el tiempo que deberia ser indicado
          en el token de sello de tiempo se desvia o salta fuera de la sincronizacion
          con UTC, esto sera detectado (ver 7.3.1e).
         
          NOTE 2: Es obligatorio informar a las terceras partes ante el suceso de tales
          eventos(ver 7.4.8).


   d) La TSA debe asegurar que la sincronozacion del reloj es mantenidad cuando
          un segundo intercalar (leap second) ocurre, segun lo notificado por el organo
          competente. El cambio para tener en cuenta este segundo intercalar (leap second)
          ocurre durante las ultimos minutos del dia, cuando segundo intercalar(leap second)
          es programado que ocurra. "es.wikipedia.org/wiki/Segundo_intercalar"
          Un registro debe debe ser mantenido del tiempo exacto (dentro de la declaracion de presicion)
          cuando este cambio ocurre. Ver anexo A para mas detalles.


          NOTE 3: Un segundo intercalar es un ajuste a UTC por saltar o agregar un segundo extra sobre
          el ultimo segundo de un mes UTC. Primera preferencia es dada a el de mes diciembre y Junio, y
          la segunda preferencia es dada a el dinde Marzo y Septiembre.


7.4.  Operacion y Gestion de la TSA


7.4.1.  Gestión de la Seguridad


   La TSA asegura que los procedimiento administrativos y de gestion
   aplicados son adecuados y corresponde a la mejores practicas
   reconicidas.
  
   En particular:


   TSA General


   a) La TSA mentiene responsabilidad absuluta sobre el servicio de sellado
          de tiempo, dentro del alcance de esta politica de sellado de tiempo,
          "aun cuando existan funciones tercializadas". Responsabilidades de
          estas terceras partes seran claramente definida por la TSA y se
          realizaran acuerdos para asegura que las terceras partes esten
          obligados a implemenrar todos los controles requeridos por la TSA. La
          TSA mantiene responsabilidad por la divulgacion de las practicas
          relevantes a todas las partes.
         
   b) La gerencia de la TSA debe proveer direccion sobre la seguridad de la
          informacion, a traves de un foro de alto nivel que sea responsable de
          definir la politica de seguridad de la TSA. La TSA debe asegurar la
          comunicacion de esta politica a todos los empleados que estan
          implicados en ella.
         
   c) La infraestructura necesaria para manejar la seguridad de la informacion
          dentro de la TSA debe ser mantenieda continuamente. Cualquier cambio que
          impacte sobre el nivel de seguridad provisto, sera aprobado por el forum
          ejecutivo de la TSA.


          NOTE 1: See ISO/IEC 17799 [ISO 17799] for guidance on information
          security management including information security infrastructure,
          management information security forum and information security
          policies.


   d) Los controles de seguridad y los procedimientos operativos, para
          las instalaciones de la TSA, sistemas y activos de informacion,
          que proveen el servicion de sellado de tiempo, debe estar
          documentado, implementado y mantenido.


          NOTE 2: La presente documentacion (comunmente llamdo politica
          o manual de seguridad) debe indentificar todos los objetivos
          relevante, objetos y potenciales amenzas realcionadas a el
          servicio, y las salvaguaras requeridass para evitar o limitar
          los efecto de aquellas amenazas, consistente con el Analisis de Riesgo
          requerido bajo la seccion 7.1.1a. Este debe describir las reglas,
          directivas y procedimientos al respecto, de como el servicio especificado
          y las garantias de seguridad asociadas son garantizadas, en adicional a la
          politica sobre incidentes y desastres.


   e) La TSA debe asegurar que la seguridad de la informacion es mantenida
          cuendo la responsabilidad de las funciones de la TSA sea tercializada
          por otras organizacones o enteidades.
         
7.4.2.  Gestion y clasificacion de Activos


   La TSA debe asegurar que su informacion y otros activos, reciben un apropiado
   nivel de proteccion.
  
   En particular:
  
        - La TSA debe mantenner un inventario de todos los activos y
          debe asignar una clasificacion, para los requisitos de proteccion de
          aquellos activos, el cual debe ser cosnistente com el Analisis de
          Riesgos.
         
7.4.3.  Seguridad del Personal


   La TSA asegura que el personal y las practicas de contratacion mejora
   y respalda la fiabilidad de las operaciones de la TSA.


   En particular (TSA general):


   a) La TSA debe emplear personal que posea conocimiento experto, experiencia
          y calificaciones necesarias para los servicios ofrecidos, segun sea
          apropiado para el puesto de trabajo.


          NOTE 1: el personal de la TSA debe ser capaz de cumplir todos los
          requerimientos de "conocimiento experto", experiencia y calificaciones
          mediante capacitacion formal y credenciales, experiencia actual, o una
          combiancion de las dos.
         
          NOTE 2: Personal empleado por la TSA incluye al personal individual
          contractualmente comprometido en realizar funciones de soporte en los
          servicios de la TSA. Personal quien esta involucrado en el monitoreo de
          los servicios de la TSA, no necesita ser personal de la misma.


   b) La responsabilidad de los roles de seguridad, como se especifica en la
          politica de seguridad de la TSA, debe esta documentado en la descripcion
          de puestos. Los puestos de confianza, sobre los cuales las operaciones
          de seguridad de la TSA depende,deben ser claramente indentificados.
         
   c) Personal de la TSA (temporal y permanente) debe tener un descripcion de
          puesto definido desde el punto de vista de la separacion de tareas y
          privilegios minimos, determiando la sensibilidad de la posicion sobre
          la tarea y niveles de acceso, investigacion de antecendentes, formacion y
          sensibilizacion de los empleados. Cuando sea apropiado, se debe diferenciar
          entre funciones generales y funciones especificas de la TSA. Este debe
          incluir requerimeintos de experiencia y skill.


   d) El personal debe ejercitar los procesos/procedimiento administrativos y de
          gestion que estan alineados con los procedimientos de la gestion de la
          seguridad de la informacion (ver 7.4.1).


          NOTE 3: See ISO/IEC 17799 [ISO 17799] for guidance.


          Los siguientes controles deben ser ser aplicados
          a la gestion del sellado de tiempo:
               
   e) Debera emplearse personal Directivo que posea:
         
          - Conocimiento en tecnologia de sellado de tiempo; y
          - Cocimineto ne tecnologia de firma digital; y
          - Conocimiento en mecanismos de calibracion o sincronizacion de
            los relojes de la TSI con UTC, y
          - familiarizado con procedimientos de seguridad para el personal
            con responsabilidad en seguridad; y
          - experiencia con seguridad de la informacion y analisis de riesgos.
         
   f) Todo el personal de la TSA en cargos de confianza deben estar en
          libres de conflictos de interes que puedan perjudicar la imparcialidad
          de las operaciones de la TSA.


   g) los puestos de confianza incluyen cargos que involucran las
          siguientes responsabilidades:
  
          -  Oficiales de Seguridad: responsabilidad global por la gestion
             de la implementacion de las practicas de seguridad.
            
          -  Administradores de Sistemas: autorizados a instalar, configurar y
             mantener la fidelidad de los sistemas de la TSA.


          -  Operadores de Sistema: responsables de la operaciones basicas
             de de los sistemas de la TSA dia a dia. Autorizados a realizar
             backup y recovery.


          -  Auditores de Sistemas: Auotrizados a ver archivos y logs de auditoria
             de los sistemas de la TSA.
            
   h) El personal de la TSA debe ser formalmente designado en los roles de confianza
          por altos directivos responsables de la seguridad.
         
   i) No deben ser designadps los puestos de confianza o directivos, a personas quienes
          ya son conocidos por tener condenas por delitos graves o otros delitos que afecte
          su idoneidad para el cargo. El personal no debe tener acceso a los puestos de
          confianza hasta que todos los chequeos necesarios sean terminados.
         
          NOTE 4: En algunos paises no es posible que la TSA obtenga la informacion del pasado
          delictivo sin la colaboracion del candidato al puesto.
         
7.4.4.  Seguridad fisica y del entorno.




   La TSa debe asegurar que el acceso fisico a los servicios criticos es controlada
   y el riesgo a los activos fisicos es minimizado.




   En particular (general):


   a) Para ambos, la provision de sellos de tiempo y la gestion de los sellos de tiempo:
  
          -  acceso fisico a las instalaciones con el servicio de sellado de tiempo deben
             ser limitada a personas debidamente autorizadas;
          -  controles deben ser implementados para evitar perdidas, daño o compromiso de
             los activos e interrupciones a las actividades del negocio; y
            
          -  controles deben ser implementados para evitar, compromiso o robo de informacion,
             y de procesamiento de informacion.
   b) Controles de acceso deben ser aplicados a los modulos de seguridad para cumplir los
   requisitos de seguridad de los modulos criptograficos como se define en 7.2.1 and 7.2.2.


   c) Los siguientes controles adicionales deben ser aplicados a la gestion de los sellos
   de tiempo:
  
          -  La gestion de las instalaciones de sellado de tiempo deben ser operadas en un
             ambinete el cual este protegido fisicamnete el servicio del compromiso, a traves
             de acceso inautorizado a los sistemas o datos.
         
          -  La proteccion fisica se logra a traves de la creacion de perimetros claramente
             definidos (barreras fisicas) en torno a la gestion del sellado de tiempo. Cualquier
             de las instalaciones compartidas con otra organizacion, dene estar fuera de este
             perimetro.


          -  Los controles de seguridad fisica y del entorno deben ser implementados para
             proteger las instalaciones que resguardan los recursos de los sistemas, los
             sistemas en si, y las  instalaciones para soportar sus operaciones. La politica
             de seguridad fisica y del entorno para los sistenas de la TSA, concernientes con
             la administracion del sellado de tiempo, debe ser dirigida como minimo al control
             de acceso, protecion contra desastres naturales, seguridad contra los factores de
             incendio, fallas de equipamiento de soporte (energia, telecomunicaciones), colapso de
             la estrucutura, perdidas en las cañerias, proteccion contra robo, allanamientos y
             recuperacion ante desastres.

          -  Los controles deben ser implementados para proteger el equipamiento,
             informacion, y que el software/medios relacionado al servicio de sellado
             de tiempo sea llevado fuera del sitio sin autorizacion.


          NOTE 1: See ISO/IEC 17799 [ISO 17799] for guidance on physical and
          environmental security.


          NOTE 2: Otras funciones pueden ser soportadas dento de la misma area
          de seguridad siempre que el acceso sea limitado a personal autorizado.
         
         
7.4.5.  Gestion de la Operaciones


   La TSA debe asegura que los sistenmas componentes de la TSA son seguros
   y correctamente operados, con un riesgo minimo de falla:
  
   En particular (general):


   a) La integridad de los sistemas componentes de la TSA y la informacion
          deben ser protegida contra virus, software malicioso o inautorizado.


   b) Procedimientos de reporte y respuesta a incidentes deben ser empleado
          de tal manera que el daño causado por incidente de seguridad y el mal
          funcionaminto sean minimizados.
         
   c) Medios (usb/cd) usados  en los sistemas de confianza de la TSA deben ser
          manejados de forma segura para protegerlo de daños, robo, acceso
          inautorizado y obsolescencia.
         
          NOTE 1: todo miembro del personal con responsabilidades directivas
          es responsable por la planificacion y la implementacion efectiva de
          la politica de sellado de tiempo y practicas asociadas como se
          documenta en la declaracion de practicas de la TSA.


   d) Procedimientos deben ser establecidos e implementados por todos los
          roles administrativos y de confianza que impactan sobre la
          provision del servicio de sellado de tiempo.


   Manejo de medios y Seguridad


   e) Todos los medios deben ser manejados de forma segura en concordancia
          con los requerisitos del esquema de clasificacion de informacion
          (ver 7.4.2). Medios conteniendo datos sensitivos deben ser eliminados
          de forma segura cuando ya no se necesite.        


   Planificacion del Sistema (System Planning)


   f) La demanda de capacidad debe ser monitoreada y las proyecciones
          a futuro de requirimientos de capacidad hechas para asegurar
          adecuado poder de procesamiento y almacenamiento.
         
   Reporte y Respuesta a Incidentes


   g) La TSA debe actuar de manera oportina y coordinada en orden de
          responder rapidamente a incidentes y limitar el impacto de las
          brechas de seguridad. Todo incidente deve ser reportado tan pronto
          como sea posible despues de ocurrido.


   Los controles siguiente deben ser aplicados a la gestion del
   sellado de tiempo:


   Procedimientos de Operaciones y Responsabilidades
  
   h) Oeraciones de Seguridad de la TSA deben estar separadas de otras
          operaciones.


          NOTE 2: Operaciones de seguridad de la TSA incluyen las siguientes
         resoponsabilidades:


             -  Procediminetos operacionales y responsabilidades.
             -  planificacion de sistemas de seguridad y aceptacion.
             -  proteccion de software malicioso;
             -  Servicio de limpieza;
             -  administracion de redes;
             -  moniotreo activo de auditorias, analisis de eventos y
                seguimiento;
             -  manejo de medios y seguridad;
             -  intercambio de datos y software.
   Estas operaciones deben ser manejadas por personal de confianza, pero,
   puede de momento ser realizadas por no especialistas, personal de
   operaciones (bajo supervision), como se define en la apropiada politica
   de seguridad, y documentos de roles y responsabilidades.
  
7.4.6.  Administración del sistema de control de acceso


   La TSA debe asegurara que el acceso a los sistemas es limitado
   a un número reducido y autorizado de personas.


   En particular(general):


   a)Controles (ej fireewalls) deben ser implementados para proteger
   los domionios internos de acceso inahutoriazado, incluyendo acceso
   por los suscriotores y las terceras partes confiantes.
  
   NOTE 1: Firewalls deben ser tambien configruados para prevenir todos
   los protocolos y accesos no requeridos para la operacion de la TSA.


   b) La TSA debera garantizar una admninistracion efectiva de usuarios
          (esto incluye operadores, administradores y autitores) acceso
          para mantener la seguridad de los sistemas, incluyendo gestion de
          cuentas de usuarios, audotria y modificaciones o remocion de accesos.


   c) The TSA shall ensure that access to information and application
          system functions is restricted in accordance with the access
          control policy and that the TSA system provides sufficient
          computer security controls for the separation of trusted roles
          identified in TSA's practices, including the separation of
          security administrator and operation functions.  Particularly, use
          of system utility programs is restricted and tightly controlled.
         
          La TSA debe garantizar el acceso a la informacion y << ACA QUEDEEEE >>>


   d) TSA personnel shall be properly identified and authenticated
          before using critical applications related to time-stamping.


   e) TSA personnel shall be accountable for their activities, for
          example by retaining event logs (see section 7.4.10).


   The following additional controls shall be applied to time-stamping
   management:


   f) The TSA shall ensure that local network components (e.g., routers)
   are kept in a physically secure environment and that their
   configurations are periodically audited for compliance with the
   requirements specified by the TSA.


   g) Continuous monitoring and alarm facilities shall be provided to
   enable the TSA to detect, register and react in a timely manner upon
   any unauthorized and/or irregular attempts to access its resources.


   NOTE 2: This may use, for example, an intrusion detection system,
   access control monitoring and alarm facilities.


7.4.7.  Trustworthy Systems Deployment and Maintenance


   The TSA shall use trustworthy systems and products that are protected
   against modification.


   NOTE: The risk analysis carried out on the TSA's services (see
   section 7.1.1) should identify its critical services requiring
   trustworthy systems and the levels of assurance required.






   In particular:


   a) An analysis of security requirements shall be carried out at the
          design and requirements specification stage of any systems
          development project undertaken by the TSA or on behalf of the TSA
          to ensure that security is built into IT systems.


   b) Change control procedures shall be applied for releases,
          modifications and emergency software fixes of any operational
          software.


7.4.8.  Compromise of TSA Services


   The TSA shall ensure in the case of events which affect the security
   of the TSA's services, including compromise of TSU's private signing
   keys or detected loss of calibration, that relevant information is
   made available to subscribers and relying parties.


   In particular:


   a) The TSA's disaster recovery plan shall address the compromise or
          suspected compromise of TSU's private signing keys or loss of
          calibration of a TSU clock, which may have affected time-stamp
          tokens which have been issued.


   b) In the case of a compromise, or suspected compromise or loss of
          calibration the TSA shall make available to all subscribers and
          relying parties a description of compromise that occurred.


   c) In the case of compromise to a TSU's operation (e.g., TSU key
          compromise), suspected compromise or loss of calibration the TSU
          shall not issue time-stamp tokens until steps are taken to recover
          from the compromise


   d) In case of major compromise of the TSA's operation or loss of
          calibration, wherever possible, the TSA shall make available to
          all subscribers and relying parties information which may be used
          to identify the time-stamp tokens which may have been affected,
          unless this breaches the privacy of the TSAs users or the security
          of the TSA services.


          NOTE:  In case the private key does become compromised, an audit
          trail of all tokens generated by the TSA may provide a means to
          discriminate between genuine and false backdated tokens.  Two
          time-stamp tokens from two different TSAs may be another way to
          address this issue.










Pinkas, et al.                   Informational                         [Page 28]


RFC 3628           Requirements for Time-Stamping Authorities  November 2003




7.4.9.  TSA Termination


   The TSA shall ensure that potential disruptions to subscribers and
   relying parties are minimized as a result of the cessation of the
   TSA's time-stamping services, and in particular ensure continued
   maintenance of information required to verify the correctness of
   time-stamp tokens.


   In particular:


   a) Before the TSA terminates its time-stamping services the following
          procedures shall be executed as a minimum:


          -  the TSA shall make available to all subscribers and relying
             parties information concerning its termination;


          -  TSA shall terminate authorization of all subcontractors to act
             on behalf of the TSA in carrying out any functions relating to
             the process of issuing time-stamp tokens;


          -  the TSA shall transfer obligations to a reliable party for
             maintaining event log and audit archives (see section 7.4.10)
             necessary to demonstrate the correct operation of the TSA for a
             reasonable period;


          -  the TSA shall maintain or transfer to a reliable party its
             obligations to make available its public key or its
             certificates to relying parties for a reasonable period;


          -  TSU private keys, including backup copies, shall be destroyed
             in a manner such that the private keys cannot be retrieved.


   b) The TSA shall have an arrangement to cover the costs to fulfill
          these minimum requirements in case the TSA becomes bankrupt or for
          other reasons is unable to cover the costs by itself.


   c) The TSA shall state in its practices the provisions made for
          termination of service.  This shall include:


          - notification of affected entities;
          - transferring the TSA obligations to other parties.


   d) The TSA shall take steps to have the TSU's certificates revoked.


7.4.10.  Compliance with Legal Requirements


   La TSA debe garantizar cumplimiento con los requerimientos legales.


   En particular:


          La TSA debe garantizar que los requerimientos de Directivas Europeas
          de protección de datos [Dir 95/46/EC], se cumple mediante
          legislación nacional.
         
  
   b) Se adoptarán las medidas técnicas y organizativas adecuadas
          contra el tratamiento no autorizado o ilegal de los datos personales y
          contra la pérdida accidental o la destrucción o daño a datos personales.
         
   c) La información aportada por los usuarios a la TSA será
          completamente protegida de divulgación menos con su consentimiento
          o por orden judicial u otro requisito legal.
         

7.4.11.  Registro de Información concerniente a las operaciones del Servicio de Sellado de Tiempo


        La TSA se asegurará de que toda la información pertinente sobre la
        funcionamiento de los servicios de sellado de tiempo se registra
        durante un período definido de tiempo, en particular para el propósito
        de proporcionar evidencia de la efectos de los procedimientos legales.




   En particular:


   General
  
   a) Los eventos y datos especificos que se van a registrar será
          documentado por la TSA.


   b) La confidencialidad y la integridad de los registros actuales
          y archivados referente a la operación de los servicios de
          sellado de tiempo será mantenido.


   c) Los registros relativos a la gestión de servicios de sellado
          de tiempo deberá archivarse por completo y de forma
          confidencial de acuerdo con prácticas comerciales de divulgacion.


   d) Los registros relativos a la gestión de servicios de sellado
          de tiempo deberá estar disponible si se requiere para los
          fines de proporcionar evidencia de la operación correcta de
          los servicios de sellado de tiempo a los efectos de los
          procedimientos judiciales.


   e) La hora exacta de eventos significantes del entorno de la TSA,
          de la gestión de claves y sincronización de reloj, se registrarán.


   f) Los registros relativos a los servicios de sellado de tiempo, se mantendran
          por un período de tiempo, después de la expiración de la validez de la clave
          de firma de la TSU, según corresponda. Para proporcionar evidencia legal
          necesaria y según lo notificado en la declaración de divulgación de la TSA
          (ver sección 7.1.2).


   g) Los eventos serán registrados un modo que no pueden ser fácilmente
          borrado o destruido (excepto si se transfieren de forma fiable a medios
          de largo plazo) dentro del período de tiempo que se requiere que sean
          mantenidos.
         
          NOTA: Estos pueden ser resguardados, por ejemplo, mediante el uso de
          medios de sólo escritura, un registro de cada medio extraíble
          utilizado y la uso de copias de seguridad fuera del sitio.
           
        h) Cualquier información registrada sobre los suscriptores será
           confidencial, excepto cuando el acuerdo es obtenido por
           publicaciones del suscriptor.
          
   Administracion de la clave de la TSU


   i) Los registros relativos a todos los eventos relacionados
          con el ciclo de vida de las claves TSU serán registrados


   j) Los registros relativos a todos los eventos relacionados
          con el ciclo de vida de los certificados TSU (en su caso)
          serán registrados


   Sincronizacion del Reloj


   k) Los registros relativos a todos los eventos relacionados
          con la sincronización del reloj de una TSU a UTC serán
          registrados. Esto incluirá información relativa a la
          recalibración o la sincronización de los relojes normales
          utilizar en sellado de tiempo.
         
   l) Los registros relativos a todos los eventos relacionados
          con la detección de pérdida de sincronización serán
          registrados.
         
         
7.5.  Organizational


  
   La TSA se asegurará de que su organización es confiable.


   En particular, que:


   a) Políticas y procedimientos bajo los cuales opera la
          TSA deberán ser no discriminatorios.


   b) La TSA hará que sus servicios sean accesibles para todos
          los solicitantes cuyas actividades están comprendidas en
          su ámbito declarado de funcionamiento y que se comprometen
          a cumplir con sus obligaciones según lo especificado en la
          declaración de divulgación de la TSA.


   c) La TSA es una persona jurídica de acuerdo a la legislación nacional.


   d) La TSA tiene un sistema o sistemas de gestión de seguridad de la
          calidad y la información adecuada para los servicios de sellado
          de tiempo que está proporcionando.


   e) La TSA cuenta con mecanismos adecuados para asumir las
          responsabilidades derivadas de sus operaciones y / o actividades


  
   f) Tiene la estabilidad financiera y los recursos necesarios para
          operar en conformidad con esta política.


          NOTA 1: Esto incluye los requisitos para la terminación de la
          TSA identificado en la sección 7.4.9.


   g) Se emplea un número suficiente de personal que tiene la educacion
          necesaria, formación, conocimientos técnicos y experiencia relacionada
          al tipo, variedad y volumen de trabajo necesario para proporcionar
          el servicio de sellado de tiempo.
         
          NOTA 2: El personal empleado por una TSA incluyen personal individual
          contractualmente comprometidos al desempeñar funciones de apoyo a la
          Los servicios de la TSA de sellado de tiempo. El personal que puedan
          estar involucrados solamente en el seguimiento de los servicios de la
          TSA no tiene que ser el personal de TSA.


  
   h) Se cuenta con políticas y procedimientos para la resolución de quejas
          y disputas recibidas de los clientes o de otras partes de la
          provisión de los servicios de sellado de tiempo o cualquier otro asunto
          relacionado.


   i) Tiene un acuerdo debidamente documentado y relacion contractual
          en el lugar donde el aprovisionamiento de los servicios implica
          subcontratación, tercerización u otros acuerdos de terceros.


8.  Consideraciones de Seguridad


   Al verificar tokens de sello de tiempo es necesario para el verificador
   asegurarse que el certificado de la TSU es confiable y no esta revocado.
   Esto significa que la seguridad, depende de la seguridad de la CA que ha
   emitido el certificado de la TSU, tanto para la emision del certificado y
   proporcionar información precisa del estado de revocación de dicho
   certificado.


   Cuando un sello de tiempo es verificado como válido en un punto dado
   del tiempo, esto no quiere decir que necesariamente permancera válido
   después. Cada vez, que un token de sello de tiempo se verifica durante
   el período de validez del certificado de TSU, este debe ser verificado
   nuevamente contra la información de estado de revocación mas reciente,
   ya que en caso de compromiso de una clave privada de la TSU, todos los
   tokens de sello de tiempo generadas por esta TSU pierde su validez.
   Anexo C proporciona orientación acerca de la verificación a largo plazo
   de tokens de sello de tiempo.
   En la aplicación de sellado de tiempo en aplicaciones, consideraciones
   de seguridad también deben tomadas en la aplicaciones. En particular,
   cuando la aplicación de sellos de tiempo, es preciso asegurar que la
   integridad de los datos se mantiene antes de aplicar el sello de tiempo.
   El solicitante debe realmente segurarse que el valor hash incluido
   en el token de sello de tiempo coincide con el hash de los datos.


9.  Acknowledgments


   The development of this document was supported by ETSI and the
   European Commission.  Special thanks are due to Franco Ruggieri for
   his valuable inputs.


10.  References
[a]Ver perfil legal para establecer requerimientos a cumplir, documentación, etc.
[b]chequear
[c]ACA QUEDE !!!