Index: maquetacion/capitulo5/capitulo5.tex
===================================================================
--- maquetacion/capitulo5/capitulo5.tex	(revision aab7301bee5f6691988ce7f773b7252047018d8d)
+++ maquetacion/capitulo5/capitulo5.tex	(revision d61ff5c322fa4021ca5277199b0dbf8772eee388)
@@ -1,4 +1,8 @@
-\chapter{Certificaci\'on Electr\'onica}
+%\chapter{Certificaci\'on Electr\'onica}
+
+\chapter{Desarrollo de una aplicaci\'on para Gesti\'on de una Autoridad de Certificaci\'on Ra\'iz bajo Est\'andar X.509 utilizando Software Libre}
+
 \label{capitulo5}
+
 \chapterauthors{V. Bravo y A. Araujo
 \chapteraffil{Fundación Centro Nacional de Desarrollo e Investigación en Tecnologías Libres}
@@ -6,13 +10,15 @@
 
 
-La gestión de certificados electrónicos de una Infraestructura
-de Clave Pública (ICP) para establecer identidades digitales se conoce como 
-Certificación Electrónica. Entre los procesos de gestión están la generación,
-almacenamiento y publicación de certificados, así como la publicación de información
-y consulta del estado de vigencia y validez de los mismos.
-
-En la sección \ref{subsubsection:certificadosElectronicos} se presentó el 
-certificado electrónico como un documento electrónico que permite establecer
-la identidad digital de personas y/o dispositivos. 
+% Desarrollo de una aplicación para Gestión de una Autoridad de Certificación Raíz bajo Estándar X.509 utilizando Software Libre
+
+% La gestión de certificados electrónicos de una Infraestructura
+% de Clave Pública (ICP) para establecer identidades digitales se conoce como 
+% Certificación Electrónica. Entre los procesos de gestión están la generación,
+% almacenamiento y publicación de certificados, así como la publicación de información
+% y consulta del estado de vigencia y validez de los mismos.
+% 
+% En la sección \ref{subsubsection:certificadosElectronicos} se presentó el 
+% certificado electrónico como un documento electrónico que permite establecer
+% la identidad digital de personas y/o dispositivos. 
 
 
@@ -27,13 +33,12 @@
 seguridad física y lógica, de la clave privada que permite la generación de estos certificados. 
 
-%Este trabajo muestra el proceso de desarrollo de una aplicación para gestionar el
-En este capítulo se describe el proceso de desarrollo de una aplicación para gestionar 
-una Autoridad de Certificación Raíz utilizando  bibliotecas, herramientas, compiladores, 
+Este trabajo muestra el proceso de desarrollo de una aplicación para gestionar 
+una Autoridad de Certificación Raíz utilizando bibliotecas, herramientas, compiladores, 
 sistemas operativos y licencias compatibles con los principios del software libre. 
 En primer lugar, se determinan los requisitos a ser satisfechos en función de una 
 descripción general de las funciones y características de una Autoridad de 
-Certificación; posteriormente, se dise~nan funcionalidades y se especifican 
-requisitos, con el objetivo de producir  una visión formal de los procesos a 
-automatizar. Se dedica una sección de este capítulo a la implementación que consiste
+Certificación; posteriormente, se diseñan funcionalidades y se especifican 
+requisitos, con el objetivo de producir una visión formal de los procesos a 
+automatizar. Se dedica una sección a la implementación que consiste
 en la codificación en un lenguaje de programación, de los procesos previstos en las 
 etapas anteriores, como también, de la incorporación de mecanismos fuertes de 
@@ -49,6 +54,23 @@
 
 %\begin{abstract}
-%A Certification Authority Root (CA Root) is a component which role is to represent the highest confidence point in a hierarchical structure denominated Public Key Infrastructure (PKI). A PKI provides people, IP addresses and Web domains with digital certificates under X.509 standard, offering logic security and legal entailment to transactions performed on the internet by the certificate’s owner. Confidence resides in private key protection through strong physical and logical security schemes, so these schemes allow the certificate emission. This work shows the development process of a CA root management application. For this development it's used libraries, tools, compilers, operating systems and licenses compatible with the principles of free software. In first place, the requirements to satisfy are determined based on a general description of a CA's functions and characteristics; subsequently, functionalities are designed and requirements are specified in order to produce a formal vision of the processes 
-%to automate. A section is dedicated to the implementation, this consists on codification in a programming language of the processes forseen in the previous stages, like also, of the incorporation of strong mechanisms of validation of identity of users, registry of events, actions signature by application's administrators, and connections specification with specialized hardware, like smart cards. Finally, application display and configuration are shown, it involves its installation in a safe environment (vault or data center) and CA Root connection with other components of the infrastructure.
+%A Certification Authority Root (CA Root) is a component which role is to represent the highest 
+% confidence point in a hierarchical structure denominated Public Key Infrastructure (PKI). 
+% A PKI provides people, IP addresses and Web domains with digital certificates under X.509 
+% standard, offering logic security and legal entailment to transactions performed on the 
+% internet by the certificate’s owner. Confidence resides in private key protection through 
+% strong physical and logical security schemes, so these schemes allow the certificate emission. 
+% This work shows the development process of a CA root management application. For this development 
+% it's used libraries, tools, compilers, operating systems and licenses compatible with the 
+% principles of free software. In first place, the requirements to satisfy are determined 
+% based on a general description of a CA's functions and characteristics; subsequently, 
+% functionalities are designed and requirements are specified in order to produce a formal 
+% vision of the processes 
+%to automate. A section is dedicated to the implementation, this consists on codification 
+% in a programming language of the processes forseen in the previous stages, like also, 
+% of the incorporation of strong mechanisms of validation of identity of users, registry
+% of events, actions signature by application's administrators, and connections 
+% specification with specialized hardware, like smart cards. Finally, application display 
+% and configuration are shown, it involves its installation in a safe environment 
+% (vault or data center) and CA Root connection with other components of the infrastructure.
 %\end{abstract}
 
@@ -59,6 +81,6 @@
 \section{Introducción}
 
-\label{sec:intro}La disponibilidad de Internet como medio digital seguro permite 
-que cualquier persona, empresa, institución, o administración realice transacciones 
+\label{sec:intro}La disponibilidad de Internet como medio digital %seguro permite 
+permite que cualquier persona, empresa, institución, o administración realice transacciones 
 gubernamentales, comerciales o personales en la mayoría de los casos, tal cual, 
 como se realizarían en una oficina o espacio físico de forma presencial. Dado este 
@@ -86,5 +108,5 @@
 
 Cuando se traslada el concepto de identidad al medio informático, se habla de 
-identidad digital, y se hace necesario contar credenciales traducibles a 
+identidad digital, y se hace necesario contar con credenciales traducibles a 
 información binaria. Por otro lado, la criptografía, por sí misma no proporciona este 
 concepto: es el uso de una infraestructura computacional que utiliza algoritmos 
@@ -103,5 +125,5 @@
 proceso desarrollo de la aplicación de gestión, y que están vinculados con los 
 principios del software libre y los requisitos muy particulares del ambiente 
-de despliegue, subrayan los objetivos propuestos en este capítulo. %de este trabajo.
+de despliegue, subrayan los objetivos propuestos de este trabajo.
 
 \section{Marco Teórico}
@@ -131,5 +153,5 @@
 Igual que para la disponibilidad, los usuarios pueden ser personas, procesos o 
 programas. Para evitar que nadie no autorizado pueda tener acceso a la información 
-transferida y que recorre la Red se utilizan técnicas de cifrado o codificación de 
+transferida y que recorre la red se utilizan técnicas de cifrado o codificación de 
 datos. Hay que mantener una cierta coherencia para determinar cuál es el grado de 
 confidencialidad de la información que se está manejando, para así evitar un esfuerzo 
@@ -141,16 +163,16 @@
 Mediante una firma electrónica se codifican los mensajes a transferir, de forma que una 
 función, denominada hash \cite{ACE:03}, calcula un resumen de dicho mensaje y se 
-le a~nade. La validación de la integridad del mensaje se realiza aplicándole al original la 
-misma función y comparando el resultado con el resumen que se a~nadió al final cuando 
+le añade. La validación de la integridad del mensaje se realiza aplicándole al original la 
+misma función y comparando el resultado con el resumen que se añadió al final cuando 
 se calculó por primera vez antes de enviarlo.
 Mantener la integridad es importante para verificar que en el tiempo de viaje por 
-la Red de la información entre el sitio emisor y receptor ningún agente externo o 
+la red de la información entre el sitio emisor y receptor ningún agente externo o 
 extra\~no ha modificado el mensaje.
 
 \subsection{Criptografía}
-La criptografía  es la ciencia o arte información utilizando técnicas matemáticas 
+La criptografía  es la ciencia o arte de ocultar información utilizando técnicas matemáticas 
 que hagan posible el intercambio de mensajes de manera que sólo puedan ser leídos 
 por las personas o usuarios autorizados \cite{STAL:03}. La criptografía ha tomado 
-gran importancia en los últimos a~nos, ya que es posible transformar las 
+gran importancia en los últimos años, ya que es posible transformar las 
 ``técnicas matemáticas'' en algoritmos que pueden ser comprendidos por una computadora.  
 Se puede clasificar la criptografía en dos tipos, según el tipo de clave que se utilice:
@@ -186,10 +208,11 @@
 conoce como certificado autofirmado.
 Dado que los certificados son información pública y lo que se desea es que todos 
-tengan acceso a ellos, pueden hacerse copias del certificado de acuerdo sea necesario. 
+tengan acceso a ellos, pueden hacerse copias del certificado %de acuerdo sea necesario. 
+para su distribución.
 Los certificados electrónicos permiten varias cosas, entre ellas se pueden citar que los 
-usuarios pueden a~nadir firmas electrónicas a los formularios en línea; que los 
+usuarios pueden añadir firmas electrónicas a los formularios en línea; que los 
 destinatarios pueden comprobar la autenticidad del correo electrónico confidencial; 
-que los compradores pueden estar seguros de que un website es legítimo; y por último, 
-controla el acceso a bancos y comercios online, así como los intranets y extranets.
+que los compradores pueden estar seguros de que un sitio web es legítimo; y por último, 
+controla el acceso a bancos y comercios en línea, así como las intranets y extranets.
 
 \subsection{Estándar X.509}
@@ -197,5 +220,5 @@
 
 X.509 y X.500 fueron originalmente dise\~nados a mediados de los a\~nos 80, antes 
-del enorme crecimiento de usuarios en Internet. Es por esto por lo que se 
+del enorme crecimiento de usuarios en la Internet. Es por esto por lo que se 
 dise\~naron para operar en un ambiente donde sólo los computadores se interconectaban 
 intermitentemente entre ellos. En las versiones  1 y 2 de X.509 se utiliza una 
@@ -215,5 +238,6 @@
 incluso incluir dentro de elemento físico, como una tarjeta inteligente. 
 Los certificados en el formato X.509 v3 contienen datos del sujeto, 
-como su nombre, dirección, correo electrónico, etc. (Ver Fig. \ref{fig:estandarx509})
+como su nombre, dirección, correo electrónico, etc. La figura \ref{fig:estandarx509}
+muestra un bosquejo de la especificación del estándar X.509 versión 3.
 
 En la versión 3 de X.509, no hace falta aplicar restricciones sobre la estructura 
@@ -264,5 +288,5 @@
  tener la seguridad de que el fichero que reciben o se descargan, proviene exclusivamente 
  de una empresa determinada. Con ello se evitan los problemas causados por la 
- suplantación de personalidad y la distribución de objetos da\~ninos o perjudiciales 
+ suplantación de identidad y la distribución de objetos da\~ninos o perjudiciales 
  bajo esta supuesta identidad. Cualquier modificación (por ejemplo: inclusión de un 
  troyano o infección de un virus) sobre el software original lo invalidará, con lo que el 
@@ -278,8 +302,8 @@
 permite diseñar sistemas a través de  modelos, que se componen de un conjunto 
 de símbolos y diagramas en donde se plasma las ideas de funcionalidad. 
-El UML fue creado por Grady Booch, James Rumbaugh e Ivar Jacobson en el a~no 
+El UML fue creado por Grady Booch, James Rumbaugh e Ivar Jacobson en el año 
 1997\cite{SCHM:03},\cite{BOOC:99} y \cite{MULL:97}. Cada diagrama tiene fines distintos 
 dentro del proceso de desarrollo, su finalidad es presentar diversas perspectivas 
-de un sistema. La clave está en organizar el proceso de dise~no de tal forma que los analistas, 
+de un sistema. La clave está en organizar el proceso de diseño de tal forma que los analistas, 
 clientes, desarrolladores y otras personas involucradas en el desarrollo del modelo 
 lo comprendan y convengan con él. Los diagramas que componen el lenguaje son:
@@ -296,6 +320,5 @@
 \end{itemize}
 
-%En este trabajo se utilizaron esencialmente los diagramas de clases, los diagramas de
-En este capítulo se utilizaron esencialmente los diagramas de clases, los diagramas de 
+En este trabajo se utilizaron esencialmente los diagramas de clases, los diagramas de
 casos de uso y los diagramas de actividades, que se describen brevemente a continuación:
 
@@ -322,5 +345,5 @@
 por siempre; 2) Libertad de estudiarlo y adaptarlo a nuestras necesidades; 
 3) Libertad de redistribuirlo a cualquiera, logrando ayudar a un amigo o vecino; 
-y por último 4)la  Libertad de mejorar el programa y publicar las mejoras.
+y por último 4) la Libertad de mejorar el programa y publicar las mejoras.
 
 Las libertades antes expuestas, proveen  muchos beneficios  a los usuarios finales. 
@@ -359,5 +382,5 @@
 \item  Autoridad de Certificación (AC): es el nodo central de la infraestructura, 
 se encarga de los procedimientos  de firma, renovación  y revocación de 
-certificados digitales. El procedimiento de firma  de certificados utiliza 
+certificados electrónicos. El procedimiento de firma  de certificados utiliza 
 la clave privada de la AC.
 \item Interfaz con los clientes (PUB): es el nodo  que brinda toda la información 
@@ -370,6 +393,6 @@
 Los nodos de una ICP pueden ordenarse según diversos modelos.  El más utilizado es 
 el modelo jerárquico, que presenta una raíz y nodos hijos que distribuyen los 
-certificados a los clientes o entidades finales (Ver Fig. \ref{fig:jerarquia}). 
-Se muestra un ejemplo de modelo de jerarquía de una ICP de cuatro niveles, 
+certificados a los clientes o entidades finales. En la figura \ref{fig:jerarquia} 
+se muestra un ejemplo de modelo de jerarquía de una ICP de cuatro niveles, 
 que se encuentra en el tercer nivel del modelo, que certifica a los usuarios.
 
@@ -381,5 +404,5 @@
 \end{figure}
 
-Este modelo de establecimiento de relaciones de confianza, es necesaria entre 
+Este modelo de establecimiento de relaciones de confianza, es necesario entre 
 múltiples autoridades de certificación para garantizar que los usuarios 
 (entidades finales) no tengan que depender y confiar en una sola AC, algo que haría 
@@ -394,5 +417,5 @@
 En los párrafos siguientes se discuten los aspectos, procesos y técnicas 
 principales, que se siguen a lo largo del desarrollo de la aplicación (software) 
-de gestión del componente Autoridad Certificadora Raíz.
+de gestión del componente Autoridad de Certificación Raíz.
 
 
@@ -417,5 +440,5 @@
 
 La diferencia de escala de los dos tipos de AC conlleva a que la AC Raíz tenga 
-características particulares, que tienen que ver los niveles y elementos de seguridad
+características particulares, que tienen que ver con los niveles y elementos de seguridad
 tanto físicos como lógicos que deben considerarse en la gestión del componente. 
 Por ejemplo, la desconexión de red del equipo  donde se ejecuta la aplicación de 
@@ -445,9 +468,9 @@
 
 La etapa de dise\~no consiste en elaborar diagramas formales que permitan en la etapa 
-de implementación representar requisitos y procesos de la gestión del componente AC Raíz 
+de implementación la representación de requisitos y procesos de la gestión del componente AC Raíz 
 en un lenguaje de programación.  Para el dise\~no de requisitos se utilizan los diagramas 
-de casos de uso del lenguaje UML, que muestran una primera aproximación las operaciones 
+de casos de uso del lenguaje UML, que muestran una primera aproximación de las operaciones 
 que se deben realizar en relación con las entradas dadas por los usuarios. Los actores 
-(usuarios) del caso de uso principal que se muestra en la Fig. \ref{fig:casodeusoprincipal} 
+(usuarios) del caso de uso principal que se muestra en la figura \ref{fig:casodeusoprincipal} 
 son: el Administrador del componente AC, el Administrador del Componente AR, el Administrador 
 del componente PUB, y el actor PSC, quiénes son los que interactúan con la aplicación.
@@ -462,5 +485,5 @@
 Para el resto de la especificación de requisitos se elaboran casos de uso que modelan 
 las funcionalidades con que debe contar la aplicación. Para cada actor, se especifican 
-el correspondiente diagrama de caso de uso. En la Fig. \ref{fig:casodeusoac} se 
+el correspondiente diagrama de caso de uso. En la figura \ref{fig:casodeusoac} se 
 muestra el caso de uso para el actor del componente AC. Las acciones que realiza 
 este actor son emisión, renovación y revocación de certificados, que conlleva procesos 
@@ -477,5 +500,5 @@
 
 También en esta etapa se construye  el modelo de datos de la aplicación. 
-La Fig. \ref{fig:diagramadeclases} muestra de forma parcial, ya que no se incluyen 
+La figura \ref{fig:diagramadeclases} muestra de forma parcial, ya que no se incluyen 
 los atributos,  el diagrama de clases que explica el modelo de datos. Se consideran 
 como objetos persistentes del sistema a elementos como usuarios, clientes, 
@@ -492,8 +515,8 @@
 
 Para modelar la secuencia de acciones que se realizan para cada caso de uso se 
-utilizan los diagramas de actividades. La Fig. \ref{fig:diagramaactividades} 
+utilizan los diagramas de actividades. La figura \ref{fig:diagramaactividades} 
 muestra el diagrama de actividades general para el caso de uso  ``Emisión de 
 certificados''' del actor Administrador del componente AC. Para este conjunto de 
-actividades participan cuatro (4) actores: Administrador del PSC, quién entrega los 
+actividades participan cuatro (4) actores: Administrador del PSC, quien entrega los 
 recaudos necesarios para que se le firme su solicitud, el Administrador de la AR, 
 quién es el encargado de chequear los recaudos entregados por el PSC, el Administrador 
@@ -506,5 +529,5 @@
 \centering
 \includegraphics[width=8cm]{imagenes/diagramaactividades.png}
-\caption{Diagrama de actividades}
+\caption{Diagrama de actividades para el caso de uso ``Emisión de Cerificados``}
 \label{fig:diagramaactividades}
 \end{figure}
@@ -515,6 +538,6 @@
 
 En esta etapa se utiliza como insumo los diagramas de casos de uso, diagrama 
-de clases y actividades, generados en la etapa de  dise~no. Se traduce  el 
-diagrama de clases al que se hace referencia en la Fig. \ref{fig:diagramaactividades} 
+de clases y actividades, generados en la etapa de  diseño. Se traduce  el 
+diagrama de clases al que se hace referencia en la figura \ref{fig:diagramaactividades} 
 en un modelo de datos relacional, y se genera un script SQL que genera el mapa de 
 tablas relacional, donde las tablas representan relaciones tales como usuarios, 
@@ -528,16 +551,16 @@
 
 
-Haciendo uso de las ventajas que trae el uso de software libre (Sección \ref{sec:softlibre}), 
+Haciendo uso de las ventajas que trae el uso de software libre, descritos en \ref{sec:softlibre}, 
 se implementa la aplicación utilizando la mayor cantidad de líneas de códigos 
 disponibles en los repositorios y proyectos de la comunidad, de tal manera que 
-satisfagan los requisitos y funcionalidades planteadas en la etapa de dise~no. 
+satisfagan los requisitos y funcionalidades planteadas en la etapa de diseño. 
 En este sentido, se utiliza el código fuente del  proyecto XCA \cite{XCA:03}, 
-desarrollado por Christian Hohnst\"{a}dt,  que tiene como objetivo proveer  una
+desarrollado por Christian Hohnst\"{a}dt, que tiene como objetivo proveer  una
 aplicación escrita  en el lenguaje de programación C++\cite{STRO:02} y la 
 biblioteca Trolltech Qt\cite{BLAN:06}, que cumpla con el estándar X.509. La aplicación 
 satisface los requisitos básicos para la gestión del componente de gestión de AC Raíz, 
-esto es, los diagramas UML de la etapa de dise~no calzan con un gran conjunto de requisitos 
+esto es, los diagramas UML de la etapa de diseño calzan con un gran conjunto de requisitos 
 satisfechos en el proyecto XCA, esto ocurre debido a que este trabajo comparte 
-objetivos con dicho proyecto; por ejemplo, para el caso de uso de la Fig. \ref{fig:casodeusoac}, 
+objetivos con dicho proyecto; por ejemplo, para el caso de uso de la figura \ref{fig:casodeusoac}, 
 donde el actor debe ejecutar tres acciones: emitir, renovar y revocar certificados, 
 la aplicación XCA incorpora estas tres actividades, pero se hace necesario adaptar 
@@ -545,14 +568,14 @@
 
 Es importante recalcar, que XCA no sastiface todos los requisitos documentados en la 
-etapa de dise~no. En respuesta a este hecho, se realiza un proceso de completación de 
-funcionalidades. En este sentido, se incorporan características a la aplicación acorde 
-con la especificaciones de dise~no,  entre las cuáles se enumeran:
+etapa de diseño. En respuesta a este hecho, se realiza un proceso de incorporación de 
+funcionalidades. En este sentido, se agregan características a la aplicación acorde 
+con la especificaciones de diseño, entre las cuáles se enumeran:
 \begin{itemize}
  \item La incorporación de un sub-sistema de seguridad para acceso a los activos de 
  información que gestiona la aplicación,  que incluya aspectos de autenticación y 
  autorización de usuarios,  como lo es  la validación de credenciales a través del 
- uso de tarjetas inteligentes, el registro y firma digital  de las acciones realizadas 
+ uso de tarjetas inteligentes, el registro y firma electrónica de las acciones realizadas 
  por los usuarios dentro de la aplicación. 
-En La fig \ref{fig:registro} se muestra la característica de registro de acciones. 
+En la figura \ref{fig:registro} se muestra la característica de registro de acciones. 
 La ventana a la derecha muestra los detalles de la acción seleccionada en la lista, 
 se incluyen datos importantes como nombre de la cuenta de usuario, fecha, hora, y 
@@ -578,12 +601,12 @@
 la codificación y creación de la aplicación de gestión del componente AC Raíz.  
 Los tipos de tecnologías que deben seleccionarse son: bibliotecas para construir 
-la interfaz hombre-máquina (HMI), motor criptográfico,  conexiones con hardware, 
+la interfaz hombre-máquina (HMI por sus siglas en inglés), motor criptográfico,  conexiones con hardware, 
 interfaces con repositorio de datos y algoritmos de cálculo criptográfico más utilizados.
 
 
 Como criptosistema se utiliza OpenSSL version 0.9.8 \cite{VIEG:2002}, que provee 
-de un conjunto de  funciones criptográficas apegadas al estándar X.509. . Para la 
-construcción de interfaces hombre-máquina y  uso de algoritmos generales se 
-selecciona la biblioteca Trolltech Qt. Como  interfaz para el uso de tarjetas 
+un conjunto de funciones criptográficas apegadas al estándar X.509. Para la 
+construcción de interfaces hombre-máquina y uso de algoritmos generales se 
+selecciona la biblioteca Qt. Como interfaz para el uso de tarjetas 
 inteligentes se utilizo el estándar PKCS11, también conocido como Cryptoki, que 
 especifica una forma para interactuar con este hardware criptográfico\cite{NIC:03}.
@@ -609,9 +632,9 @@
 más complejos formados por las unidades revisadas en las pruebas unitarias. 
 Las pruebas unitarias y de integración  presentan la ventajas que son automatizables, 
-y por lo tanto, se cuenta como herramientas de software para llevarlas a cabo.
+y por lo tanto, se cuenta con herramientas de software para llevarlas a cabo.
 
 
 El segundo objetivo, es que se satisfagan los requisitos  plasmados en la etapa 
-de dise~no, y que se extraen  de los diagramas UML , es decir, la aplicación 
+de diseño, y que se extraen  de los diagramas UML , es decir, la aplicación 
 debe cumplir con las características necesarias para resolver el problema de 
 gestión de una AC Raíz. En este sentido, se toma una estrategia basada en 
@@ -619,5 +642,5 @@
 de la comunidad  chequear el progreso en el proyecto. Los prototipos son 
 chequeados por los usuarios y  la modificación de requisitos y notificación de 
-errores son notificados en un sistema web de chequeo y seguimiento \cite{TRAC:07}.
+errores son notificados en un sistema web de chequeo y seguimiento\cite{TRAC:07}.
 
 También se habilita un sistema de control de versiones de licencia libre 
@@ -626,5 +649,5 @@
 versión de los programas fuentes.
 
-Debido a que la aplicación de gestión de AC Raiz debe ser parte de una 
+Debido a que la aplicación de gestión de AC Raíz debe ser parte de una 
 infraestructura, es necesario realizar pruebas en condiciones similares a la 
 configuración final de ésta; por ello se simula la configuración de producción que 
@@ -643,8 +666,9 @@
 restringido por llaves y controles biométricos, y el flujo de información digital 
 hacia adentro y afuera de la bóveda debe ser realizado a través de dispositivos 
-de memoria secundaria con seguridad incorporada, tal como un lapiz usb (pendrive)
-con bloqueo por contrase~na, como se muestra en la figura.  También es necesario 
-la habilitación de servidores para la validación de los periodos de vigencia de 
-los certificados (OSCP), y para la generación de solicitudes de firma de certificados, 
+de memoria secundaria con seguridad incorporada, tal como una memoria usb (pendrive)
+con bloqueo por contraseña, como se muestra en la figura \ref{fig:arquitecturapsc}. 
+También es necesario la habilitación de servidores para la validación de los períodos de vigencia de 
+los certificados a través del protocolo de estado de certificado en línea (OCSP por sus siglas en inglés), 
+y para la generación de solicitudes de firma de certificados, 
 donde las entidades finales o usuarios consignan los recaudos.
 
@@ -662,19 +686,19 @@
 de tarjetas inteligentes, inicialización  de HSM, y copias de seguridad.
 
-\section{Lecciones aprendidas}
+\section{Conclusiones}
 
 La puesta en marcha de una AC Raíz supone obligatoriamente contar con una 
 aplicación  que gestione este componente de la infraestructura. En este sentido, 
-éste capítulo mostró el proceso de desarrollo de una aplicación que respondiera 
+éste trabajo mostró el proceso de desarrollo de una aplicación que respondiera 
 a los requisitos particulares de gestión, determinados por el rol de confianza 
-raíz y última que debe representar la Autoridad.  En función de ello, la 
-aplicación tiene un alto grado de especialización, ya que  cuenta con un  
+raíz que debe representar la Autoridad de Certificación. En función de ello, la 
+aplicación tiene un alto grado de especialización, ya que cuenta con un  
 mercado relativo de pocos usuarios, si se compara con el mercado de los sistemas
 de información o aplicaciones de ofimática, y su operación se realiza en 
-condiciones estandándares y específicas. A pesar de este hecho, para la 
+condiciones estándares y específicas. A pesar de este hecho, para la 
 construcción de la aplicación se integraron varios proyectos disponibles en los
-repositorios de software libre, que permitió disponer de un criptosistema 
+repositorios de software libre, lo que permitió disponer de un criptosistema 
 estándar y suficientemente completo para cumplir con los requisitos descritos 
-en la etapa de dise~no. La criptografía se utiliza como herramienta para 
+en la etapa de diseño. La criptografía se utiliza como herramienta para 
 otorgar las tres propiedades (Confidencialidad, Integridad y Disponibilidad) 
 de la seguridad informática a los datos que gestiona la aplicación, y en virtud 
@@ -683,7 +707,7 @@
 con los estándares aceptados a nivel mundial.  
 
-En la etapa de dise~no, los diagramas de casos de uso y actividades sirvieron 
+En la etapa de diseño, los diagramas de casos de uso y actividades sirvieron 
 para obtener una visión formal de los requisitos y de los procesos con los que 
-cumplir la aplicación. Estos documentos de dise~no  en el lenguaje UML, permitieron 
+cumplir la aplicación. Estos documentos de diseño  en el lenguaje UML, permitieron 
 alcanzar de manera más rápida y certera los objetivos que son coincidentes con la 
 gestión real de una AC Raíz. 
@@ -692,5 +716,5 @@
 gestionados por la aplicación sean compatibles con el esquema de seguridad basado 
 en un tercero de confianza, y aceptado por gran cantidad de aplicaciones y sitios 
-de comercio y transacciones seguras en internet. 
+de comercio electrónico y transacciones seguras en internet. 
 
 Para la tarea de eliminación de fallas las técnicas como la colaboración utilizando 
@@ -740,9 +764,69 @@
 almacenar con un alto nivel de seguridad claves privadas.
 
-%\bibliography{BibACRaizArticulo}
+%\bibliography{referenciasCapitulo5}
 %\bibliographystyle{plain}
 
 
-
+% bibliografia
+\begin{thebibliography}{}
+
+\bibitem{NIC:03}
+R. Nichols and P. C. Lekkas, "Seguridad para comunicaciones inal{\'a}mbricas". McGraw-Hill, Mexico, 2003.
+
+\bibitem{STAL:03}
+William Stallings, "Fundamentos de Seguridad de Redes. Aplicaciones y Est{\'a}ndares", Prentice Hall, España, 2003. 
+
+\bibitem{NASH:02}
+Nash Duane and Joseph Brink, "PKI: Infraestructura de clave p{\'u}blica", McGraw-Hill,. Mexico, 2002.
+
+\bibitem{ACE:03}
+Vicente Aceituno Canal, "Seguridad de la información", Noriega Editores, Mexico, 2003.
+
+\bibitem{SCHM:03}
+Joseph Schmuller, "Aprendiendo UML en 24 horas", Prentice Hall, Mexico, 2003.
+
+\bibitem{BOOC:99}
+G., Booch, "UML Lenguaje Unificado de Modelado", Addison Wesley, 1999.
+
+
+\bibitem{MULL:97}
+Alain Pierre-Muller, "Modelado de objetos con UML", Eyrolles, Barcelona, España, 1997.
+
+
+\bibitem{FSF:07}
+Free Software Definition, http://www.fsf.org/licensing/essays/free-sw.html, 2007.
+
+
+\bibitem{SARW:03} 
+Sarwar, Koretsky, "El libro de Linux", Pearson, Prentice Hall, Madrid, España, 2003.
+
+\bibitem{KURT:01}
+Kurt Wall et al, "Programación en Linux", Prentice Hall, Madrid, España, 2001.
+
+
+\bibitem{XCA:03}
+Christian Hohnst\"{a}dt, XCA, una interfaz gr\'afica para OpenSSL, Clave p\'ublicas y privadas,
+certificados, solicitudes y listas de revocación. http://sourceforge.net/projects/xca/.
+
+\bibitem{STRO:02}
+Bjarne Stroustrup, "El lenguaje de programación C++", Addison Wesley, Madrid, España, 2002.
+
+\bibitem{BLAN:06}
+James Blanchette and Mark Summerfield, "C++ GUI Programming with Qt 4", Prentice Hall, Massachusetts, USA, 2006.
+
+\bibitem{VIEG:2002}
+John Viega and Matt Messier and Pravir Chandra, "Network Security with OpenSSL", O'Really, 2002.
+
+\bibitem{PRESS:05}
+Roger S. Pressman, "Ingenier'ia del software. Un enfoque práctico", Mc Graw-Hill, Mexico 2005.
+
+\bibitem{TRAC:07}
+TRAC web-based software project management, http://trac.edgewall.org/, 2007.
+
+\bibitem{PILA:04}
+C. Michael Pilato and Ben Collins-Sussman and Brian W. Fitzpatrick, "Version Control with Subversion ", O'Really, 2004.
+
+
+\end{thebibliography}
 
 
@@ -786,6 +870,24 @@
 % 
 % %\begin{abstract}
-% A Certification Authority Root (CA Root) is a component which role is to represent the highest confidence point in a hierarchical structure denominated Public Key Infrastructure (PKI). A PKI provides people, IP addresses and Web domains with digital certificates under X.509 standard, offering logic security and legal entailment to transactions performed on the internet by the certificate’s owner. Confidence resides in private key protection through strong physical and logical security schemes, so these schemes allow the certificate emission. This work shows the development process of a CA root management application. For this development it's used libraries, tools, compilers, operating systems and licenses compatible with the principles of free software. In first place, the requirements to satisfy are determined based on a general description of a CA's functions and characteristics; subsequently, functionalities are designed and requirements are specified in order to produce a formal vision of the processes 
-% to automate. A section is dedicated to the implementation, this consists on codification in a programming language of the processes forseen in the previous stages, like also, of the incorporation of strong mechanisms of validation of identity of users, registry of events, actions signature by application's administrators, and connections specification with specialized hardware, like smart cards. Finally, application display and configuration are shown, it involves its installation in a safe environment (vault or data center) and CA Root connection with other components of the infrastructure.
+% A Certification Authority Root (CA Root) is a component which role is to represent the 
+% highest confidence point in a hierarchical structure denominated Public Key Infrastructure (PKI). 
+% A PKI provides people, IP addresses and Web domains with digital certificates under X.509 
+% standard, offering logic security and legal entailment to transactions performed on the 
+% internet by the certificate’s owner. Confidence resides in private key protection through 
+% strong physical and logical security schemes, so these schemes allow the certificate emission. 
+% This work shows the development process of a CA root management application. For this development 
+% it's used libraries, tools, compilers, operating systems and licenses compatible with the 
+% principles of free software. In first place, the requirements to satisfy are determined based 
+% on a general description of a CA's functions and characteristics; subsequently, functionalities 
+% are designed and requirements are specified in order to produce a formal vision of the 
+%processes 
+% to automate. A section is dedicated to the implementation, this consists on codification in a 
+% programming language of the processes forseen in the previous stages, like also, 
+% of the incorporation of strong mechanisms of validation of identity of users, 
+% registry of events, actions signature by application's administrators, and 
+% connections specification with specialized hardware, like smart cards. 
+% Finally, application display and configuration are shown, it involves its 
+% installation in a safe environment (vault or data center) and CA Root connection 
+% with other components of the infrastructure.
 % %\end{abstract}
 % 
