MXPA05000696A - Sistema y metodo para la transmision, almacenamiento y recuperacion de documentos autenticados. - Google Patents

Abstract

Se describe el Servicio de Estado de Certificado que es configurable, dirigido y capaz de recuperar el estado de cualquier Autoridad de Certificacion (CA) aprobada. El CSS se puede usar por un Servicio de Custodia de Confianza (TCU) y sistemas comparables o aplicaciones cuyos papeles son la validacion del derecho de un individuo para realizar una accion de requisito, la autenticidad de los objetos de informacion electronica presentados y el estado de los certificados de autenticacion usados en los procesos de la verificacion de la firma digital y la autenticacion del usuario. La verificacion de validez sobre los certificados de autenticacion se realiza interrogando a una CA que expide. Tradicionalmente, para crear una Infraestructura de Clave Publica (PKI) necesaria para validar los certificados, se forman relaciones complejas mediante una certificacion cruzada entre las CAs o mediante el uso de puentes PKI. El problema de interoperabilidad de la PKI y la CA se consigna desde un punto de vista diferente, con un enfoque en el establecimiento de un ambiente de confianza adecuado para la creacion, ejecucion, mantenimiento, transferencia, recuperacion, y destruccion de los objetos de informacion originales, electronicos, que tambien pueden ser registros transferibles (la propiedad puede cambiar de manos). Un TCU esta ocupado solo con un conjunto conocido de "CAs aprobadas" aunque puede soportar una multitud de ambientes de negocios, y dentro de ese grupo de CAs, solo con aquellos certificados que estan asociados con las cuentas del usuario de TCU. No se requiere la construccion de relaciones de confianza PKI/CA pues el CSS logra un ambiente de confianza o seguridad interrogando solo a las CAs aprobadas y manteniendo las memorias asociadas de estados de certificados validos.

Description

SE, SI, S , TR), OA PI patent (BP, BJ, CF, CG, Cl, CM, DK. EE. ES. El. ER. GB. GR. HU. IE. IT. LU. MC. ??_. PT. GA , GN. GQ. GW. M L, M«, NE. S , TD. TG). RO. SE. Si. SK. TR). OAPI patent (BF. BJ. CE CG. Cl. CM. GA. GN. GQ. GW. ML MR. NE. SN. TD. TG) Dcclaratlons uoder RuJe 4-17: as lo ihe applicam 's emiil meiu lo clatm ilie priority of the — as lo applicam ' s emitlemem lo pply for and be granled carlicr applicatlon (R Ls 4. I 7(iit)) for all destgnations a pate.nl (Rule 4.17(H)) for [he following dcsign lions AE~ — as lo lite applicam 's eniiüemeni lo claim ¡lie prioriry of the AO. AL AM. AT. AU. AZ BA. BB. BG. BR. ??. BZ. CA. eortier apphcation {Rule , ] 7(ni)) for all designaiions C . CN. CO. CR. CU. CZ DE. DK. DM. DZ EC. EE. ES. El. GB. GD. GE. GH. GM. HR. HU. ID. 1L IN. JS. JP. KE. KG. KP. KR. KZ. LC. LK. LR. LS. LT. W. L MA. MD. PubU&lied: MG. MK. MN. MW. MX. MZ NI. NO. NZ OM. PG. PH. 'tlluyul tnic.mati naJ sear h repon and lo be rvpublished PL PT. RO. RU. SC. SO SE. SG. SK. SL 5X 77. TM. TN. upon receipt of thal rnpnn TR. TT. TZ, UA. UG, u ve. v. ru. Zi. ZM. ZW. ????? patent (GH. GM. ICE. LS. MW. MZ SD. SL SZ TZ UG. For rwO'lener cedes artd oilw.r refr.r lo the "Gutd- ZM. ZW). Eurasian pair.ru (AM ?? BY. KG. KZ MD. RU. ance Noltts on Cades and Ahhrmiiations" appen a the eg TJ. TM). Euivpcan pateta (??. BE. BG. CH. CT. CZ DE. ning of ta h regular is ue of the PCT Gazene. 01-?4/05 VIE 10:15 l e TX/RX S154] ©006 SISTEMA Y METODO PARA LA TRANSMISIÓN, ALMACENAMIENTO Y RECUPERACIÓN DE DOCUMENTOS AUTENTICADOS CAMPO DE LA INVENCIÓN La invención de los solicitantes se refiere a sistemas y métodos para proporcionar una cadena verificable de evidencias y seguridad para la creación, ejecución, mantenimiento, transferencia, recuperación y destrucción de objetos de información original electrónica, tales como documentos Electrónicos Originales™. ANTECEDENTES DE LA INVENCIÓN Esta invención usa ventajosamente el Servicio de Custodia de Confianza de los solicitantes que contiene los registros electrónicos y los papeles del sistema como una bóveda virtual al validar el derecho de un individuo para llevar a cabo una acción requerida, la autenticidad de los objetos de información electrónica enviados, y el estado de los certificados de autentificación usados en la verificación de firmas digitales y los procesos de autentificación del usuario. Tales TCUs y las operaciones se describen en la Patente Norteamericana No. 5,615,268; No. 5,748,738; No. 6,237,096; y No . 6,367,013. La siguiente lista de abreviaturas se usa en esta descripción: Abreviaturas CA Autoridad de Certificaciones CRL Lista de Revocación de Certificados CSS Servicio de Estado de Certificado HTML Lenguaje de Composición de Hipertexto ID Identificación IETF Fuerza de Tarea en Ingeniería de Internet I U Unión de Telecomunicaciones Internacionales LDAP Protocolo Ligero de Acceso a Directorios OCSP Protocolo del Estado de la Certificación en Línea, Protocolo del Estado de la Certificación en Línea de Clave Pública de Internet IETF-RFC X.- OCSP, Junio 1999. PIN Número de Identificación Personal PKCS Estándares Criptográficos de Clave Pública PKI Infraestructura de Clave Pública KIX Infraestructura de Clave Pública (X.509) S/MIME Extensiones de Correo de Internet de Múltiples Propósitos, Seguros SCVP Protocolo de Validación Simple de la certificación, Draft-IETF-PKIX-SCVP-06 de Julio del 2000 SSL Nivel de Conector de Seguridad TCU Servicio de Custodia de Confianza UETA Acto de Transacciones Electrónicas Uniformes XML Lenguaje de Composición ampliable Las Firmas Electrónicas de la legislación de Estados Unidos del Acta de Comercio Global y Nacional (ESIGN) , establece las leyes modeladas después del UETA redactada por la Conferencia Nacional de Comisionados sobre las Leyes Uniformes del Estado y aprobadas y recomendadas para su promulgación en 1999, proporciona la seguridad del estado o situación legal para los objetos de información firmados electrónicamente (documentos electrónicos) las cuales ha generado el gobierno, formar un banco de una actividad de comercio electrónico dirigida a materializar la eficiencia y la economía de estas transacciones potencialmente en su totalidad electrónicas. La PKI y la CA son los elementos base de la tecnología de la firma digital usada al crear los registros de la fuente electrónica. Una PKI es una colección de CAs donde se establece la confianza entre los usuarios y las organizaciones creando ya sea una relación jerárquica entre las CAs o a través de una certificación cruzada entre CAs cooperativas. Una CA se faculta para emitir los certificación de autenticación que enlaza la identidad de un individuo o entidad a su o sus claves públicas (verificación) donde sólo se da acceso al individuo a la clave privada de examinacion de la autenticidad de datos (firma) . En el momento de esta solicitud, los certificados normalmente se adaptan al estándar de certificaciones ITU X.509 y se firman digitalmente a si mismos mediante la CA emisora. Tales certificados se representan en la Fig. 10 de la Patente Norteamericana No. 6,237,096, por ejemplo, que se cita y se incorpora arriba. Estos certificados de autenticación contienen un número de serie, información de identificación del sujeto (usuario) y el la entidad emisora (CA) , el periodo de valides de la certificación (fecha y hora antes y después de la cual no puede ser usada) , la clave pública de los objetivos o materia, y la información del algoritmo criptográfico necesaria para crear y verificar las firmas digitales. Para crear una firma digital, un objeto de información se somete a un proceso hash (procesamiento que utiliza una función criptográfica de sentido único que puede detectar tan poco como una alteración de bitio en el objeto) y el proceso hash se cifra entonces usando la clave privada (secreta) del individuo. La verificación de la forma digital se logra invirtiendo este proceso. La firma digital se descifra usando la. clave pública del individuo recuperada desde su certificado de autenticación y el resultado se compara con un re-hash del objeto de información original. Estos procesos pueden variar cuando se usan diferentes algoritmos de firmado digital. Las firmas digitales son sólo tan seguras como la confianza que existe entre las partes transmisoras, y las CAs emisoras; y el nivel de aseguramiento alcanzado por los controles físicos, las practicas y los procedimientos implementados por las CAs. El propósito de la tecnología de PKI es crear y mantener un ambiente tanto seguro y confiable para las partes comunicativas. Tales partes confían en la PKI para establecer la identidad de los usuarios y notificarlas cuando el certificado de un usuario no es ya viable. Los certificados se revocan cuando un individuo deja una organización, cuando se emite un certificado de reemplazo, o cuando se pierde, se roba o compromete la clave de firmado. Los vendedores reportan el estado de certificado usando una amplia variedad de métodos. Estos diferentes métodos hacen más difícil a los usuarios obtener el estado de certificado de otros usuarios. La formación de una relación de confianza y la interoperatividad está dictada por el certificado de la PKI y las políticas de seguridad y sus refuerzos. La política de la certificación determina el nivel de validación personal (es decir, el proceso para la propiedad de la información de solicitud de la certificación y la identidad del receptor del certificado pretendido) requerido (por ejemplo, dos formas de trazar el ID, verificar el crédito) para obtener la aprobación para la emisión de una certificación. Las políticas de seguridad imponen los controles físicos, de procedimiento y del proceso necesarios para soportar el ambiente de aplicación. Existen dos modelos prevalentes para crear y organizar las CAs . El primero es un modelo jerárquico de CA que se parece a un árbol invertido cuya partes superior es la CA de raíz. La CA raíz firma sus certificados de las CAs subordinadas . Estas CAs firman entonces sus certificados de las CAs subordinadas, y si sucesivamente. Estas relaciones crean cadenas de certificaciones que forman las ramas del árbol . Dos CAs prueban que existe relación entre ellas "andando" sus cadenas de certificaciones respectivas hasta que se alcanza un nodo común. Las CAs pueden estar agrupadas y asociadas con uno o más canales, verticales de la industria, organizaciones o empresas de distribución de servicios. En el segundo modelo, se crea una CA para una sola empresa y se proporcionan los servicios de la CA a una o más entidades dentro de esa empresa. Una CA de empresa normalmente no tiene ninguna relación de confianza preestablecida con ninguna CA de otra empresa. Debe tomarse una acción explícita para permitir la interoperatividad, en forma de una certificación cruzada de la CA, por medio de la cual dos o más CAs que están de acuerdo en confiar una de la otra, firman la certificación una de la otra y usan estas certificaciones. certificadas de manera cruzada durante la verificación de la forma digital. Las certificaciones emitidas por una CA pueden ser validadas entonces por la otra CA certificada de manera cruzada y sus usuarios. Las CAs revocan las certificaciones cuando, entre otras razones, la información contenida en la misma se vuelve inválida, cuando la clave privada del usuario llega a estar comprometida o cuando es necesario terminar los privilegios de aplicación de un usuario en base a la certificación. Las CAs no pueden simplemente eliminar o recuperar una certificación de su dueño se esta ya en posesión del propietario. En lugar de ello, el certificado se marca como"revocado" en la base de datos de la CA, y se pública el estado de certificado. Los usuarios de la PKI pueden entonces enterarse de la validez de un certificado solicitando el estado de la certificación a partir de la CA emisora o la depositaría (directorio) del estado identificado. Un primer método usado para reportar el estado de la certificación era por medio de la publicación de una lista de certificaciones de la CA revocados, conocida como una CRL. Las CRLs son descargadas por las aplicaciones y las partes retransmisoras, para determinar si una certificación de usuario particular ha sido revocada y por extensión si esa firma digital del usuario es aun valida o no. Con el transcurso del tiempo, las CRLs se hicieron más largas, incurriendo tanto en la sobrecarga de comunicaciones como en el procesamiento de datos. Una deficiencia adicional de esta técnica es que las CRLs se publican frecuentemente a intervalos frecuentes (por ejemplo, una vez o dos veces al día) . Por esta razón, las CRLs se encuentran frecuentemente intermediariamente desactualizadas después de la publicación. Los certificados revocados se retiran de las CRLs sólo después de la expiración del certificado. Un puente de PKI es un método para proporcionar la interoperatividad entre las CAs coordinando la distribución de las CRLs. Tal puente es un lugar de depósito de la CRL central que en efecto une un grupo de CAs que están de acuerdo en aceptar mutuamente los certificados y las políticas de seguridad de las otras. Todas las CAs envían sus CRLs al puente. Esto permite la validación centralizada de los certificados de cualquier individuo o entidad. Si el certificado no ha sido revocado previamente, entonces se considera aun valido. La desventaja más grande para los puentes de PKI es que estos deben ser alcanzables por cualquier CA o usuario que retransmite sobre el puente para el estado de certificado. Los requerimientos de ancho de banda, computación, y almacenamiento pueden ser costosos . Un método más reciente para obtener el estado de certificado es el IETF OCSP, el cual hace una consulta directa a la base de datos que puede proporcionar el estado de certificado en tiempo real. Sin embargo, algunos vendedores han implementado contestadores de OCSP basados en las CRLs . El estado de certificado reportado por este tipo de responder es sólo tan puntual como las CRLs en las cuales se basa. Los intentos para lograr un estado de certificado en tiempo real, tales como el IETF SCVP continúan en desarrollo. En la época de esta invención, la mezclado y correspondencia de los métodos de verificación del estado no habla sido práctico en un ambiente PKI abierto. Cualquier técnica para la validación de certificado es una decisión todo o nada para la CA que emite los certificados. Todos los usuarios a quienes se les han emitido los certificados por una de las CAs miembros son válidos/habilitados a menos que su certificado haya sido suspendido o revocado o haya espirado. El tema común para controlar la participación es si un certificado logra ser emitido. La emisión está gobernada por las políticas de certificación y seguridad y las reglas de negocios. El ambiente de confianza puede variar desde completamente abierto, en donde a cualquiera capaz de pagar el precio de la admisión se le emite un certificado, a cerrado o limitado, requiriendo la membresía en una empresa o comunidad de interés. En cualquier caso, las políticas de certificación y/o de seguridad gobiernan o controlan si se permite la interoperabilidad. La invención de los solicitantes aborda el problema de la interoperabilidad de la PKI y la CA desde un punto de vista totalmente diferente de aquellos descritos arriba. El enfoque de los solicitantes es .establecer un ambiente de confianza adecuado para la creación, ejecución, mantenimiento, transferencia, recuperación, y destrucción de objetos de información originales que pueden ser también registros transferibles (la propiedad puede cambiar de mano) . Para materializar estos objetivos, el sistema que controla una copia electrónica del original o autorizada debe hacer posible identificar el original de cualquier copia del mismo. Como los originales en papel, puede haber sólo un original. Los ejemplos de registros transferibles son los instrumentos y certificados electrónicos negociables. Un registro electrónico original puede ser cualquier registro fuente, ya sea que califique como un registro transferible o no. La transferencia de registros electrónicos originales entre sistemas puede tener lugar usando métodos que garanticen que sólo exista un original . Esta invención crea un registro electrónico original poniendo la custodia de ese registro en manos de una parte de confianza independiente o TCU operada para el beneficio del propietario del registro. Es necesario crear un ambiente de confianza, pero no es suficiente para mantener los registros electrónicos fuente. Para los propósitos de esta invención, se crea un ambiente de confianza mediante la formación de una comunidad de interés que tiene una membresía cerrada o limitada y donde la identidad de los miembros eventuales, las organizaciones y sus usuarios se aseguran usando procedimientos de validación apropiados que controlan el otorgamiento de la admisión a la comunidad. Además, la organización de un individuo, la participación, el papel, y los atributos se definen en el momento del alistamiento con la TCU. Los individuos deben ser identificados de manera única al sistema y en su certificado de autenticación. Además, debe ser posible remover los individuos y organizaciones de la comunidad y hacer esta acción conocida para los otros miembros de la comunidad. Los métodos tradicionales para la interoperatividad de las CA no logran adecuadamente estos objetivos. La validación como mínimo requiere que una organización y/o un individuo esté patrocinado por un miembro conocido de la comunidad. Además, una calificación similar a Dun y Bradstreet para las organizaciones o una verificación de crédito similar a Equifax para los individuos, o un historial de crédito y pagos equivalente pueden ser utilizados para evaluar aceptablemente a los socios de negocios, clientes y usuarios potenciales. Tanto la organización de la validación y sus usuarios patrocinados deben ser considerados confiables antes que se permita el alistamiento en la TCU. Después que una organización acepta los términos contractuales que definen la membresía, debe otorgarse a sus individuos patrocinados un identificador y contraseña únicos que les permitirán acceder a al TCU. Una vez que un individuo se enlista con uno o más TCUs, estos pueden ser nombrados como un participante de una transacción por el propietario de esa transacción y se les otorga el acceso especifico a todos o un subgrupo identificado de registros fuente en base a su identidad, papel, y/o responsabilidad. Para facilitar la identificación y autenticación y para permitir que tengan lugar las transacciones en una forma totalmente electrónica, un subconjunto seleccionado de esta información de identificación se incluye en el certificado de autenticación del participante. El certificado de autenticación enlaza la identidad del usuario con su clave pública usada para validar las firmas digitales generadas usando su clave privada de firma de coincidencia o correspondencia. Un certificado o política de seguridad localiza los requerimientos de prueba de identidad (por ejemplo, dos formas de trazar la ID, verificación de crédito, introducción personal) necesarios antes de emitir un certificado. Este certificado se enlazará a una cuenta del TCU del usuario si se requiere por la autoridad de firmado digital . El enlace incluye un subgrupo de elementos de datos del certificado que identifican únicamente al usuario (por ejemplo, la ID del certificado, el nombre de la CA emisora, el nombre común del usuario) . Una vez asociado con una cuenta de usuario, el certificado puede ser usado en conjunción con su firma digital para dar la prueba de identidad necesaria para permitir un conjunto predeterminado de acciones autorizadas y verificar la firma digital del usuario sobre los objetos de información enviados. Esto es especialmente cierto cuando el propietario o el agente del propietario que controla un conjunto de registros electrónicos instruye al TCU para transferir la propiedad (es decir, una transacción interna) y/o para transferir la custodia (es decir, una transacción externa) de los registros electrónicos a otro TCU. Como se describió antes, los certificados de autenticación y la criptografía de clave pública se usan para apoyar tanto la autenticación del usuario y la verificación de la firma digital . El certificado se firma digitalmente mediante la CA emisora, un proceso mediante el cual se sella la identidad del receptor con su clave pública. La CA se asegura al emitir un certificado, que el individuo identificado en el certificado es el poseedor de la clave privada coincidente usada para firmar digitalmente los objetos de información o fragmentos de la misma. Esta invención difiere de otras soluciones de comercio electrónico basadas en PKI dado que la PKI se visualiza sólo como el habilitante y no es la única base del ambiente de confianza. El patrocinio, el contracto para la membresía, y alistamiento son los factores principales. Aunque el certificado y el uso de la criptografía de clave pública se visualizan como la tecnología de habilitación, los certificados debe identificar y ser relacionados únicamente a usuarios específicos antes que estos puedan ser enlazados a la cuenta de TCU de ese usuario. Cuando se emplean los certificados, la cuenta puede ser activada solamente una vez que se completa este enlazamiento entre el certificado y la cuenta del usuario. Este enlazamiento puede ser tan simple como agregar el ID del certificado y la GA emisora a la información de la cuenta de usuario o puede usarse otra información transmitida por el certificado, por ejemplo, los componentes del nombre distintivo del usuario (véase el estándar ITU X.509). La información de enlazamiento puede ser transmitida en una forma de alistamiento o extraída directamente del certificado por medio de la política de seguridad del sistema de TCU. Una verificación de correspondencia puede ser usada para asegurar que la descripción de usuario en el certificado corresponde al de los datos de alistamiento siempre que se use el certificado. El certificado de usuario se forma por la CA emisora y su integridad y autenticidad se validan usando el certificado de la CA emisora y la clave pública. El conjunto colectivo de componentes usados para la identificación debe ser probablemente único. Una vez que se logra este enlazamiento de la cuenta de TCU y el certificado de usuario, el TCU necesita sólo conocer donde ir para verificar el estado de certificado. En los ambientes céntricos de CA, una sola PKI , certificación cruzada, o creación de puentes de PKI (un sistema complejo que lleva a cabo la verificación del estado de certificado cuando se usan numerosos productos del vendedor por numerosas CAs) se requiere para la interoperatividad. El elemento común es que todos los certificados son de igual valor. Los certificados que pueden transmitir diferentes niveles de confianza y aplicaciones en un ambiente abierto deben tener la habilidad para interpretar y usar estos niveles de confianza en forma distinta. Esta filosofía puede ser caracterizada como "construimos caminos que usted tomara a cualquier parte que quiera ir" . Los usuarios se vetan tras el alistamiento de la CA usando una variedad de criterios (por ejemplo, una verificación de crédito, medios de pago, costo del certificado) . Un TCU, por el contrario, tiene que ver sólo con un grupo conocido de "CAs aprobadas" y dentro de ese grupo, sólo aquellos certificados que se asocian con sus cuentas de usuario. Cualquier otro certificado se ignorará. Esta filosofía puede ser caracterizada como "los únicos caminos que estarán abiertos para usted serán aquellos necesarios para conducir su negocio" . Los usuarios se vetan dos veces, una vez para satisfacer la política de certificado de la CA y una segunda vez para probar que existe un negocio necesario para que estos sean enlistados con µ? TCU. Las reglas de negocios implementadas por el TCU pueden ajusfar los certificados que se emiten a los diferentes niveles de confianza. BREVE DESCRIPCIÓN DE LA INVENCIÓN A la fecha, todos los servicios que reportan el estado de certificado usan un sólo medio para reportar el estado de certificado, sean CRLs, OCSP, LDAP, etc. Esta invención difiere en que permite la interoperabilidad con cualquier CA o P I para el propósito de recuperar y reportar el estado de certificado. Para la mayor parte, también reduce la confianza sobre la conectividad continua en tiempo real entre los sistemas o TCUs y los elementos que reportan el estado de certificado de la CA, ocultando el estado de certificado. En un aspecto de la invención de los solicitantes, un método para proporcionar un CSS para verificar la validez de los cerificados de autenticación emitidos por las CAs respectivas, incluye las etapas de, identificar la información necesaria para recuperar un estado de un certificado de autenticación desde una CA emisora que emite el certificado de autenticación, configurar un conector en base a la información identificada, para comunicarse con la CA emisora; comunicarse con la CA emisora de acuerdo al conector configurado; y recuperar el estado de certificado de autenticación. La CA emisora y el conector se diseñan sobre una lista de CAs aprobadas en un almacén de configuración. Una fecha y hora locales pueden ser verificadas en cuanto a si estas caen dentro de un periodo de validación indicado en el certificado de autenticación. La CA emisora puede ser incluida en la lista de CAs aprobadas, vetando y aprobando la CA emisora de acuerdo a las reglas de negocios predeterminadas, y si la CA emisora se veta y no se aprueba, la CA emisora puede ser designada en una lista de CAs no aprobadas en el almacén de configuración. La validación y la aprobación la CA emisora puede incluir registrar una representación de un certificado de autenticación de confianza con el CSS y agregar al menos la representación, el estado y un elemento de datos a una memoria de caché local . Un conector se configura entonces para recuperar el estado agregados cuando se consulta el certificado de autentificación de confianza. La comunicación con las CAs emisoras puede hacerse también de acuerdo a una secuencia de conectores . El método puede incluir además verificar una memoria caché local en cuanto al estado, y si se encuentra el estado en la memoria caché local y la fecha y hora locales están dentro del periodo de validez, recuperar el estado desde la memoria caché local . Si no se encuentra el estado en la memoria caché local o si la fecha y hora locales no están dentro del periodo de validez, el CSS establece una sesión de comunicación con un componente que reporta el estado de certificado de la CA emisora, crea una solicitud del estado de certificado de acuerdo al conector configurado, recupera el estado desde el componente que reporta el estado de certificado, cierra la sesión de comunicación con el componente que reporta el estado de certificado, y agrega al menos la identificación del certificado de autenticación, el estado, y el tiempo de vida a la memoria caché local. El estado de certificado puede ser indicado por una CRL, y de acuerdo a un programa de publicación de la CA emisora, el CSS recupera la CRL desde un componente que reporte el estado de certificado listado en el almacén de configuración, el CSS limpia una memoria caché local asociada con la CA emisora, y el CSS determina el estado de certificado de autenticación desde la CRL y almacena el estado en la memoria caché asociada con la CA emisora. El estado de certificado puede ser indicado también por una Lista de Revocación de Certificados Delta ("CRL"), y tras la notificación por la CA emisora de que se encuentra disponible una CRL, el CSS recupera la CRL de un componente de reporte del estado de certificado listado en el almacén de configuración; si la CRL es una CRL completa, entonces el CSS limpia una memoria caché asociada con la CA emisora, determina el estado a partir de la CRL, y almacena el estado en la memoria caché; y si la CRL sólo contiene los cambios que ocurren después de la publicación de una CRL completa, el CSS determina el estado a partir de la CRL, y almacena el estado en la memoria caché. En otro aspecto de la invención del solicitante, un método para recuperar un estado de un certificado de autenticación emitido por una CA emisora en respuesta a una consulta de un TCU a un CSS para validar el estado de certificado de autenticación incluye las etapas de localizar y reportar el estado, si el estado está presente y actualizado en una memoria caché del CSS; y de lo contrario, llevar a cabo las etapas para obtener un tipo del estado y el método de recuperación desde un almacén de configuración del CSS ; si el tipo de estado es la CRL y el estado no se encuentra en la memoria caché, ¦ entonces reportar el estado como valido; si el tipo de estado no es la CRL, entonces crear una solicitud del estado de certificado de acuerdo al · tipo del estado; establecer una sesión de comunicación con la CA emisora; recuperar el estado desde un componente de reporte del estado de la CA emisora, usando el método de recuperación obtenido y terminar la sesión de comunicación; interpretar el estado recuperado; asociar con el estado recuperado interpretado, un valor de tiempo de vida que representa un periodo especificado por una política del CSS para el tipo de estado; agregar al menos los valores de identificación, estado, y el tiempo de vida a la memoria caché, y reportar el estado a la TCU en respuesta a la consulta. En aun otro aspecto de la invención de los Solicitantes, un CSS para proporcionar indicaciones del estado correctas y puntuales de los certificados de autenticación emitidos por las CAs emisoras incluye proporcionar un estado de certificado de autenticación como se indica por una CRL cuando la CA que emite el certificado usa CRLs para indicar el estado. Por otro lado, se proporciona el estado como se indica por una memoria caché cuando la 'memoria caché incluye el estado y un elemento de datos del tiempo de vida no está excedido. Si el elemento de datos del tiempo de vida está excedido, el estado se limpia de la memoria caché, y el estado se solicita y recupera usando un protocolo de reporte del estado de certificado en tiempo real cuando el estado no está en la memoria caché. Al menos el •elemento de datos de la identificación, el estado, y el tiempo de vida del certificado se agrega a la memoria caché, y el estado recuperado se proporciona. El elemento de datos de contador de uso del estado puede ser agregado a la memoria caché e incrementado o restado cada vez que se verifica el estado de certificado. Si el elemento de datos del contador de uso del estado pasa de un umbral, entonces se proporciona el estado y se limpia la memoria caché con respecto al estado. Un elemento de datos del estado accesado al final se puede agregar también a la memoria caché, y el elemento de datos del estado accesado al final en conjunción con el elemento de datos del contador de uso del estado permite la determinación de un nivel de actividad del estado de certificado. Cuando se hace una solicitud al CSS para recuperar un estado de un nuevo certificado y la memoria caché ha alcanzado un límite del tamaño del búfer asignado, el CSS registra la memoria caché por un elemento de datos accesado en último lugar indicando una fecha antigua y limpia la entrada respectiva de la memoria caché; y el CSS recupera entonces el estado requerido, lo coloca en la memoria caché, y proporciona el estado requerido. En otro aspecto de la invención de los Solicitantes, un método para ejecutar una transacción entre una primera parte y una segunda parte transfiriendo el control de un objeto de información autenticado que tiene un rastro de evidencia verificable incluye recuperar desde un lugar de depósito un objeto de información autenticado que incluye un primer bloque de firma digital que tiene una firma digital de una parte que envía y un primer certificado de autenticación que relaciona al menos una identidad y una clave criptográfica con la parte que envia, ejecutar el objeto de información autenticado, recuperado por la segunda parte, incluyendo en el objeto de información autenticada, recuperada, el bloque de la firma digital de la segunda parte, y transmitir el objeto de información autenticada, recuperado a un TCU. El TCU verifica las formas digitales y valida los certificados de autenticación asociados con las firmas digitales mediante al menos la recuperación del estado de los certificados de autenticación desde el CSS. El TCU rechaza un bloque de firma digital si la firma digital respectiva o el estado de certificado de autenticación respectivo ha expirado o está revocado, y si al menos un bloque de firma en el objeto de información no se rechaza, el TCU anexa el bloque de firma digital del TCU y un indicador de fecha y hora al objeto de información y toma el control del objeto en representación de la primera parte . BREVE DESCRIPCIÓN DE LOS DIBUJOS Las varias características y ventajas de la invención de los Solicitantes se volverán aparentes mediante la lectura de esta descripción en conjunción con los dibujos, en los cuales: La Figura 1 ilustra un proceso de validación del objeto de información electrónica del TCU que emplea el CSS; La Figura 2 ilustra el procesamiento CSS de fondo por medio del cual las CRLs y CRLs · se agregan al almacén del estado de certificado,- La Figura 3 ilustra el almacenamiento en caché separado de las CRLs analizadas sintácticamente, las respuestas de OCSP, y el estado derivados de los métodos de reporte del estado de certificado; La Figura 4 ilustra una sintaxis extensible para un bloque de firma que contiene los elementos de datos ejemplares donde una firma digital esta siendo aplicada a los fragmentos del objeto de información y los datos vinculados (atributos autenticados) ; La Figura 5 ilustra la interacción del TCU con un CSS y la recuperación por el CSS del estado de certificado vía la red internacional desde las CAs miembros y del extraños ; La Figura 6 ilustra un proceso de alistamiento de los usuarios del TCU que termina en una etapa de verificación del estado de certificado, en donde la validación de la firma digital demuestra el alistamiento exitoso; La Figura 7 ilustra el proceso de alistamiento del usuario del TCU en donde una CA del exterior emitió el certificado del usuario, terminando en una etapa de verificación del estado del certificado, en donde la validación de la firma digital demuestra el alistamiento exitoso; y La figura 8 representa un ejemplo de arrendamiento de automóviles que muestra como puede ser utilizado un CSS en el comercio electrónico. DESCRIPCIÓN DETALLADA DE LA INVENCIÓN La verificación del estado de certificado es un elemento crítico para un sistema o la aceptación del TCU de cualquier presentación de objetos de información electrónica. Para que una presentación sea aceptada, el estado de certificado debe ser reportado como válido. La averiguación en cuanto al estado de certificado requiere normalmente que tengan lugar comunicaciones entre el TCU y la fuente del estado de certificado. La frecuencia de estas comunicaciones crecerá en proporción con el número de presentaciones de la TCU.

La verificación del estado de certificado puede ser un requerimiento en tiempo real y las averiguaciones del estado se llevan a cabo sobre cada presentación. Sin embargo, el estado no puede ser actualizado en tiempo real como es el caso con las C Ls . Todas las CRLs se publican a intervalos específicos, normalmente una vez o dos veces al día. La recuperación de la CRL y el análisis sintáctico repetido pueden tener un impacto negativo sobre el desempeño del sistema. Esta invención reduce significativamente los requerimientos computacionales y de comunicación directos, descargando la mayoría del trabajo un CSS . Un sólo protocolo del estado de certificado se implementa entre el TCU y el CSS. Este protocolo del estado puede tener atributos similares al IETF OCSP, que permiten a una aplicación consultar a una CA en cuanto al estado de un sólo certificado y por lo tanto minimizan la sobrecarga de procesamiento. El CSS se proporciona con y mantiene suficiente información sobre la ubicación, los medios de comunicación y del estado del procesamiento del estado del certificado para cada CA con la que necesite interoperar. El CSS hace posible por o tanto estabilizar y optimizar el diseño de aplicaciones. El CSS analiza sintácticamente y carga en el caché ventajosamente el estado de certificado para' minimizar el tiempo de respuesta del estado para una consulta del estado a la TCU. El CSS elimina por lo tato la necesidad de algunas de las formas tradicionales de interoperatividad de PKI . La recuperación de compromisos potenciales se eleva en gran medida ya que una cuenta de usuario del TCU puede ser desactivada fácilmente o un grupo de usuarios eliminados removiendo la CA de la lista del CSS de las CAs aprobadas. Uso de los Certificados de Autenticación: Después del registro dentro del TCU puede pedirse a un participante que se autentifique a si mismo a través del uso de criptografía de clave pública y su certificado de autenticación. Tal autenticación puede estar asociada con el establecimiento de una sesión segura, la solicitudes por servicios del TCU o el firmado digital y la presentación de un objeto de información electrónico. Antes que cualquiera pueda interactuar con un TCU, deben ser satisfechas cuatro condiciones 1) primero debe estar enlistados como un usuario del sistema, 2) deben haber sido publicado y estar en posesión de un par de claves públicas y su certificado de autentificación correspondientes si se le han asignado más que el acceso de sólo lectura, 3) los certificados deben ser emitidos por una CA aprobada, y 4) el certificado del usuario no debe haber expirado o ser reportado como inactivo o revocado. Esta última condición requiere que el TCU dirija una consulta a la CA emisora para recuperar el estado de certificado. Puesto que existe una amplia variedad de estándares e implementaciones de CA para reportar el estado de certificado, esto no es una tarea fácil o simple. Como se establece en la sección de antecedentes de la invención, normalmente alguna forma de interoperabilidad de PKI se requiere cuando se involucran múltiples CAs o P Is. Esta invención elimina esta necesidad creando un Servicio de Estado del Certificado. La certificación cruzada de las CA o construcción de puentes es innecesaria ya que el único conocimiento necesario para el CSS es la lista de CAs emisoras aprobadas, sus dirección IP o los similares, y sus medios para reportar el estado de certificado. Para recuperar el estado de certificado, un conector o módulo de programa se define para cada método de estado de certificado. Cada certificado de autenticación contiene tanto el campo del sujeto (usuario) y de la emisora (CA) . El campo de la emisora se usa para dirigir una consulta del TCU al CSS que verifica entonces su caché en cuanto a la presencia del estado de certificado. Si está presente el estado en el caché del CSS, se regresa al TCU. Si el estado no está presente, el CSS activará una orden para que el conector apropiado recupere el estado de certificado. Cualquier número de métodos se usaran para reportar y recuperar el estado de certificado: LDAP, OCSP, CRL, etc.

Para llevar a cabo cualquier acción del TCU, el usuario primero debe registrarse en un TCU. una vez que tiene éxito, el usuario puede crear o seleccionar una transacción si se les otorgó tal autoridad. Si estos tienen la autorización para enviar objetos de información electrónica, pueden hacerlo ahora. Tras la recepción de un objeto de información electrónica, el TCU lleva a cabo las etapas de validación de la firma electrónica necesarias. Se constituirá una consulta del estado de certificado y e enviará al CSS. Si se regresa un estado válido, el TCU aceptará y almacenará el envió como la copia autorizada, de lo contrario será rechazada. Procesamiento de la Firma Digital y Verificación del Estado de Certificado: Las firmas digitales pueden ser aplicadas a uno o más fragmentos de información o el contenido total de un objeto de información. Las firmas digitales pueden pertenecer a las partes de la transacción o a los agentes permiten que la transacción logre un estado o estatus dentro del contexto de un proceso de negocios . Las firmas digitales pueden ser aplicadas de hecho a la información adicional relacionada con la tarea que se lleva a cabo. Uno de tales ejemplos podría ser la notación del registro del condado sobre una propiedad traspasada. Otro podría ser la aplicación de la firma a la parte que atestigua la autenticidad de los objetos de información que se envían a un TCU. En este último caso, se dice que el remitente envuelve o sella el objeto de información en la medida en que su firma digital se aplica al contenido completo, previniendo cualquier modificación subsecuente . Siempre que se aplica una firma digital, se solicita al firmante afirmar su intento para estar comprometido por su firma digital. Esta acción de consigna, que se requiere por la legislación reciente, puede tomar forma de un texto leíble en una ventana desplegable o pantalla desplegable, y puede requerir la invocación de un botón gráfico y/o conectarse a un señal criptográfica que es también una clave criptográfica y el almacén del certificado. La demostración actual de dicho disposición para comprometerse es a través del uso de una aplicación de confianza que computa la firma digital del usuario usando el contenido seleccionado y la combina con su certificado de autenticación a la forma de un bloque de firma. El bloque de firma puede contener también elementos de datos autenticados y no autenticados. Los elementos de datos autenticados se incluyen en el computo de la firma digital (por ejemplo, la fecha-hora locales) y pueden ser considerados protegidos por la firma digital (integridad) . Los elementos de datos no autenticados se agregan después del computo de la firma y no están protegidos. La Figura 4 muestra una sintaxis de muestra que contiene los elementos de datos y el diseño de un bloque de firma. Este no deberá ser interpretado literalmente ya que sólo se considera ser un ejemplo ilustrativo . El objeto de información y cualquiera de los bloques de firmas pueden ser colocados ventajosamente en un envoltorio (S/MIME) o en etiquetas en la sintaxis de información extensible (XML, HTML, XHTML) por conveniencia de manejo y para facilitar el procesamiento de la información. Esta estructura de datos se envía entonces al TCU para la validación. De manera inversa, el (los) bloque (s) de firma pueden ser enviados independientemente al TCU para ser anexados al registro de la fuente actual la cual nunca abandona el TCU. En el último caso, cada bloque de firma se valida por separado. El proceso para la validación de la firma digital difiere en la hora del envío o presentación, del que se lleva a cabo después. Una validación de cuatro etapas se lleva a cabo la primera vez que el TCU ve una firma digital: 1) verifica la firma digital, un proceso que provee que el contenido protegido por la firma digital no ha sido alterado durante la transmisión; 2) verificar que la hora actual del TCU cae dentro del periodo de validez permisible del certificado de autenticación del individuo ("ni antes", "ni después") ; 3) solicita y recupera el estado de certificado desde la CA emisora, el punto de distribución de la CRL, u otra fuente aprobada . del estado de certificado usando el CSS asignado localmente; 4) valida que la información de la cuenta de usuario del TCU está de acuerdo con la transmitida en el certificado y que la acción requerida está autorizada en la base de datos de reglas del TCU. Para un remitente del objeto de información, el proceso agrega una etapa adicional . Esta quinta etapa verifica que la identidad del remitente corresponde con la de la parte quien estableció la sesión actual con el TCU. Si todas las pruebas son exitosas, se permite la acción y/o se acepta el objeto de información y se guarda por el TCU en representación de su propietario. Si alguna de las etapas falla, se inicia el remedio. Después de esta verificación inicial del estado de certificado, el ambiente de confianza del TCU mantiene la autenticidad y la integridad de todos los objetos de información contenidos . o' se anticipa que ningún estado de certificado adicional será necesario a menos que se envíe una nueva versión del documento. Dos aspectos de estas invención difieren del curso .normal de la implementación de la PKI . El primero es que esta invención se basa en la existencia de una aplicación, a saber, el TCU (o cualquier aplicación que requiere la validación del estado de certificado) y su habilidad para crear y mantener registros de la fuente electrónica original. El segundo que es la "CA emisora" sólo necesita ser identificada como que obra de. acuerdo con las políticas que gobiernan el ambiente de confianza y que ni la certificación cruzada de la CA ni la creación de puentes de PKI se requieren. La justificación necesaria para la inclusión de la "CA emisora" es una relación de negocios documentada. Durante el proceso de alistamiento del TCU, se crea una cuenta de usuario que hace referencia a la información del certificado específica que en efecto enlaza-la cuenta de usuario con el certificado de autenticación del usuario . Uso del TCU: Típicamente una vez que la organización acepta utilizar los servicios de un TCU, se garantiza el control sobre el acceso a las transacciones de esa organización a los agentes de esa organización. Los agentes de la organización identifican entonces un grupo de individuos a quienes apoderaran para llevar a cabo las acciones seleccionadas con respecto a las transacciones de la organización. Todas las acciones requieren que el usuario tenga una cuenta con el TCU, que la cuenta este activada, y que el- usuario tenga una identidad del registro de conexión y sea capaz de proporciona una contraseña apropiada o responder a una frase de desafío.

Además, cada transacción, la cual se compone de un grupo de registros de la fuente electrónica original de versiones, tiene un grupo de autorizaciones que controlan el acceso del usuario a las diferentes etapas en el proceso del negocio. Esto se ejemplifica por el -otorgamiento y remoción de los derechos a los registros de la transacción cuando la transacción procede a través del curso normal del negocio, es decir, desde el principio a la retención o destrucción permanente. Si se permite, sólo se requiere la conexión al TCU para visualizar un registro electrónico de la fuente. Sin embargo, cualquier acción de nivel de los sistemas o la introducción o cambio de un registro electrónico fuente requiere que el individuo ya sea autentifique a si mismo usando criptografía de clave pública o aplicado su firma digital y el certificado de autenticación. En todos los casos, la identidad del individuo debe ser validada. Cuando se emplean las firmas digitales esto conlleva: 1) que el usuario tenga las autorizaciones de acceso apropiadas, 2) desencriptar la firma digital y verificar que los contenidos sobre los cuales el proceso hash subyacente o el extracto del mensaje han sido aplicados no han sido alterados, 3) verificar que la hora de envío cae dentro del periodo de validez del certificado, y 4) verificar que el certificado del usuario es aun válido.

La verificación del estado del certificado requiere que la CA emisora o un respondedor del estado de certificado sean requeridos o cuestionados. Puesto que esta etapa debe ser tomada con cada acción autenticada o envío del registro electrónico fuente, el ancho de banda de comunicaciones puede volverse excesivo y existe el potencial por retardos, recargos de trabajo, y rechazos debidos a respuestas del estado no contestadas o lentas . Esta invención trata estos y otros aspectos de seguridad para la operación de un TCU y asegura la validez de todas las partes que interactuan con el TCU. En el ambiente altamente asegurado en el cual se opera el TCU, la verificación del estado de certificado es necesaria sólo cuando se solicita un servicio por un usuario calificado. Para los objetos de información, el estado de certificado sólo necesita ser verificado en el momento del envío. Si se determina que todas las firmas digitales son validas, el objeto de información se considera autentico después de eso. Las practicas y métodos de seguridad y de procedimiento están en su sitio en el TCU para prevenir acciones maliciosas y fallas de equipo que resultan en alteraciones no autorizadas o pérdidas de documentos . Cada envío resulta en la creación de una nueva versión de un registro electrónico fuente. El TCU se carga con los conocimientos de manutención en lo que se refiere a cual es la última versión del registro fuente. Esta versión puede ser identificada como el original electrónico y como un registro transíerible . El TCU demuestra su asunción del control de un registro fuente original agregando un sello de fecha-hora confiable al registro fuente y después aplicando si firma digital y anexando su certificado. Un envoltorio puede ser aplicado al registro fuente para seguridad y conveniencia del procesamiento. Aunque este proceso de versionado crea un rastro de evidencia autenticado autónomo y custodia, separa los registros de auditoria redundantes se mantienen para corroboración. El CSS de los Solicitantes soluciones las limitaciones descritas que persisten hoy en día con las PKI y el comercio electrónico. La información fuente requerida para obtener el estado del certificado desde las CAs miembros se registra con el CSS cuando estas se crean. La información fuente para las CAs externas aprobadas puede ser introducida durante el proceso de alistamiento de los usuarios. Se requiere la información de recuperaron del CSS por cada fuente de estado del certificado. Existen varios tipos de fuentes del estado de cerificado y se requiere que el CSS tenga un conector o método por cada tipo registrado. Un método usado por algunas CAs para transmitir el estado de certificado es la CRL, la cual incluye una lista de certificados revocados y la razón de su revocación, el emisor de la CRL, cuando se pública la CRL, y cuando será publicada la siguiente' versión de la CRL. Cada CRL se firma por la CA emisora o un formante designado para asegurar su integridad y autenticidad. Los certificados se remueven de la CRL una vez que se ha excedido su periodo de validez . Cuando se usan las CRLs, el CSS recupera la última rendición de la CRL desde el punto de distribución de la CA, por ejemplo un perfil X.509 v2 CRL (IETF RFC2459, enero 99) valida su firma, la analiza sintácticamente, y crea un caché para almacenar los resultados, el CSS usa un intervalo de publicación de la CRL de la CA para controlar cuando lleva a cabo la siguiente descarga de la CRL. Cada CRL contiene un campo de valides que se configura normalmente para permitir alguna libertad de acción al llevar a cabo las descargas. Esto permite la congestión de las comunicaciones y el tiempo de reposo de la CA, y forzara al CSS a requerir las acciones remedíales si se excede este intervalo. Y el remedio puede incluir la revalidación de cualquier envío que este asociado con un certificado revocado recién agregado. Cada nueva CRL reemplaza la CRL cargada previamente. La excepción a esta regla es para la procesión de CRLs delta. Los contenidos de la CRLs delta se anexan a los contenidos actuales del caché . El CRL BaseCRLNumber se refiere a la CRL completa más reciente publicada. Las CRLs delta se publican a intervalos más cortos (minutos, horas) y sólo cuando ha ocurrido la revocación de un certificado desde la última CRL completa. El CSS es responsable de recuperar las CRLs y las CRL delta en base al intervalo de publicación o la notificación y no excede el intervalo establecido en la política de seguridad del TCU. Un segundo método usado por las CAs para distribuir el estado de certificado es el OCSP. Cuando se usa el OCSP el CSS consulta al respondedor de OCSP cuando se le solicita el estado del certificado. Las respuestas del OCSP se firman para garantizar su integridad y autenticidad. El CSS analiza sintácticamente la respuesta del OCSP y agrega los detalles del certificado y el estado a otro caché. Una bandera de tiempo de vida, determinada por la política de seguridad del TCU local, se incluye con y determina cuando la entrada será removida del caché. Esta característica tiene como meta minimizar la sobrecarga de las comunicaciones cuando varios objetos de información deberán ser cargados por la misma parte/entidad al TCU en un intervalo corto. La bandera de tiempo de vida usualmente será significativamente más corta (por ejemplo, 5 minutos) que el intervalo normal de publicación de la CRL (dos veces al día, diariamente) . El CSS puede verificar otra vez el estado del certificado, si se procesaron más de un objeto de información, antes de purgar el estado del certificado del caché, para asegurarse de que no ha ocurrido la revocación del certificado. Si ha ocurrido la revocación del certificado durante el intervalo de tiempo de vida, entonces el punto de contacto de la organización propietaria debe ser notificado. Existen varios otros métodos de consulta, pero no se describirán por brevedad. Sea entendido que cada una de estas requerirá un conector y potencialmente un caché separado cuando se utilizan. La Figura 1 muestra el flujo del proceso para crear un original electrónico. Para propósitos de descripción, se asume que el objeto de información es un contracto de ventas. Una copia (no ejecutada) del objeto de información electrónica se recupera desde el TCU o desde un sistema de preparación de documentos y se firma digitalmente u holográficamente (escritura a mano) por las partes apropiadas. Habiendo inspeccionado el proceso de ejecución, el agente del propietario usa una aplicación de confianza para firmar digitalmente y envolver el objeto de información y lo envía al CU. Habiendo creado previamente, ejecutado o recuperado el documento electrónico, un remitente lo firma digitalmente y envía lo envía al TCU como en la etapa 101. En este proceso de sellado electrónico se forma un envoltorio que contiene el contenido firmado y el (los) bloque (s) de firma que contienen además la (las) firma (s) digitales y el (los) certificados del remitente y cualquier otro firmante. Existen cinco procesos representados en la Figura 1: (1) la acción cuando se encuentra una firma (s) digital (es) invalidas y/o revocadas, (2) la verificación del estado del certificado cuando se guarda en caché localmente el estado, (3) verificación del estado de certificado cuando el estado de certificado tiene que ser recuperado, (4) la recuperación y procesamiento de la CRL, y (5) creación de un original electrónico cuando se determina que el documento sellado electrónicamente es autentico. En la etapa 103 el TCU" recibe el documento sellado electrónicamente. En la etapa 105 el TCU valida que el remitente tiene la autoridad para agregar el documento electrónico a una cuenta y/o transacción seleccionada. En la etapa 107, el TCU verifica criptográficamente cualquier firma digital incluida en el documento electrónico envuelto electrónicamente. La clave pública, encontrada en el certificado de autenticación X.509, se usa durante el proceso de verificación. En la etapa 109, se extrae el periodo de validez del certificado desde el certificado de autenticación del firmante, y en la etapa 111, se confronta el periodo de validez contra la fecha y la hora actuales. Si alguna de las pruebas antes mencionadas falla, se rechaza el envío en la etapa 113 y puede ser enviado una aprobación negativa en la etapa 114. La acción se registra en la etapa 117.

Si todas las pruebas resultan exitosas, entonces el estado de certificado para cada cerificado contenido dentro del envoltorio se solicita desde un CSS en la etapa 119. En las etapas 121 y 123, se verifica el estado de certificado para ver si está presente en un almacén de estado de certificado. En la etapa 125, se recupera el estado de certificado, y se verifica la validez del certificado en la etapa 127. Si se encuentra cualquier certificado invalido por alguna razón, se rechaza el envío en la etapa 113, puede ser enviada una aprobación negativa en la etapa 115, y la acción se registra en la etapa 117. Se espera que el remitente busque el remedio. Si en la etapa 127 se determina que todas las firmas digitales y los certificados son válidos para el envío o presentación, entonces en la etapa 129 el CTU aplica otro envoltorio que incluye un sello de fecha-hora y el bloque de la firma digital del TCU. El TCU asume entonces el control del envío como un registro original electrónico en representación del propietario del registro. En la etapa 131, el TCU coloca el original electrónico en el almacenamiento persistente protegido, en la etapa 133, el TCU envía una aprobación positiva, y en la etapa 117) el TCU registra las acciones recién completadas . Si en la etapa 123 se determina que el estado del certificado no está presente en el almacén de estado de certificado, entonces el CSS en la etapa 135 recupera el campo de la CA emisora desde el certificado bajo prueba. En la etapa 137, el CSS verifica para ver que la CA emisora está en la lista de CA aprobadas, la cual puede ser mantenida y acezada por un Almacén de Conectores de CA en la etapa 139. Si la CA no está listada, entonces se regresa un estado invalido y el proceso reinicia en la etapa 125 y procede a través de las etapas 127, 113, 115, y 117, resultado en el rechazo del envío y la transmisión de una aceptación negativa y la entrada del registro. Si la CA emisora se encuentra en la lista de CA aprobadas en la etapa 137 y en la etapa 141 se determina que el mecanismo de reporte del estado de certificado es una CRL, entonces se regresa una indicación de estado válido en la etapa 125. Si la CA es conocida y el estado no está presente para el certificado objetivo, pero el mecanismo de estado es una CRL, entonces puede ser sumido que el estado del certificado es válido, siempre que exista una CRL y este actualizada para la CA. El proceso procede entonces a través de las etapas 127, 129, 131, 133 y 117, resultando en la creación de un original electrónico, la transmisión de una aprobación positiva, y una entrada del registro para las acciones recién completadas. Si en la etapa 141 se determina que el mecanismo de reporte del estado del certificado no es una CRL, entonces se usa el conector de información obtenido en la etapa 137 para averiguar el mecanismo de reporte del estado de certificado. Contenido en la descripción del conector se encuentra toda la información sobre la configuración necesaria para averiguar el depósito del estado de certificado adecuado, sea una CA, un directorio, o cualquier otro tipo de depósito del estado del certificado. Los almacenes de estado asociados con las etapas 145, 147, 149, y 151 (es decir, respectivamente un directorio de LDAP, un respondedor de OCSP, una base de datos, y un servidor) son ejemplos de tales depósitos. En respuesta a una consulta en la etapa 134, uno de estos responde con la información del estado de certificado, y el estado se agrega al almacén del estado de certificado en la etapa 153. Tras la adición en la etapa 153, el proceso de in-store del estado del certificado reinicia en la etapa 121 y continua a través de las etapas 123, 125, y 127 a una conclusión donde ya sea se acepta el envío (etapas 129, 131, 133, 117) o se rechaza (etapas 113, 115, 117) . Las CRLs se publican en la etapa 155 a intervalos predeterminados y en la etapa 157 como sea necesario cuando se reporta un compromiso sospechoso y la política requiere una respuesta intermedia. Este proceso se describe además en la Figura 2.

Si la CA se conoce y el estado no está presente, y el mecanismo de estado es diferente a una CRL, el Servicio de Estado de Certificado selecciona un conector y averigua el mecanismo de estado del certificado (etapa 143) . El conector contiene la información necesaria que hacer posible la recuperación e interpretación del estado, cualquiera de las fuentes del estado de certificado en tiempo real representadas en las etapas 145-151 responderán a una consulta del estado de certificado con el estado actual, pero este proceso no se limita sólo a esas fuentes. Se recibe el estado y se agrega al almacén del Estado del Certificado en la etapa 153. Cuando se agrega el estado, se genera una respuesta y se regresa la acción a al etapa 123, con el procesamiento del estado reiniciando en la etapa 125 y llevado al término como se describe previamente. Con referencia ahora a la Figura 2 , el CSS lleva a cabo la recuperación de la CRL como un proceso de respaldo. Una CRL contiene una lista de todos los certificados revocados o suspendidos hasta la fecha y hora actuales que estas más allá del periodo de validación contenido en el certificado. Los certificados suspendidos se tratan como si hubieran sido revocados, pero estos pueden ser restablecidos lo cual resulta en su remoción de la CRL. Los certificados revocados no pueden ser recuperados .

En la etapa 155, un administrador de la CA configura la CA para publicar las CRLs a intervalos predeterminados. En la etapa 157, el administrador de la CA puede también publicar una CRL Delta como está dictado por la política . de certificados o seguridad local. El administrador de la CA o la CA enviará la notificación sobre la publicación de una CRL Delta. Una CRL Delta puede ser generada cuando quiera que se revoque o suspenda un certificado durante el intervalo entre las publicaciones de las CRLs completas. Las CRLs Deltas pueden contener una lista completa de las CRLs revocadas. En la etapa 201, las CRLs y las CRL Delta se publican en un depósito o directorio de CRL. En la etapa 203, la CSS recupera el programa de publicación de la CRL o la notificación de la CRL Delta, y la etapa 205 representa un cronometro usado para la recuperación programada. El cronometro también permite la recuperación en base al campo de "próxima actualización" contenido en todas las CRLs. En la etapa 207, se recupera la CRL o la CRL Delta desde el depósito de CRL. En la etapa 209, se analiza sintácticamente' la CRL o la CRL Delta antes de ser agregada en la etapa 153 a un caché o lista apropiada en el almacén de Estado del Certificado en la etapa 121 o el directorio en base al programa establecido o tras la notificación. El análisis sintáctico de las CRLs permite la administración más fácil y el la sobrecarga reducida en la búsqueda de las entradas a la CRL. Las etapas 119, 123, 125, 135, 137, y 141 del CSS se ilustran en la Figura 2 para amplitud, y se implementan como se describe en conexión con la Figura 1. Con referencia ahora a la Figura 3, el Almacén de Estado de Certificado contiene un número de caches que contienen el estado de certificado de diferentes mecanismos de reporte . Los caches (cinco de los cuales se representan en la Figura 3) pueden correlacionar a las CAs individuales (los caches 301, 303) o colecciones de CAs (caches 307, 309) . Para el estado reportado en tiempo real, el estado permanece en el caché hasta que se necesita el espacio (por ejemplo, los usados menos frecuentemente) o en base a un requerimiento de la política (por ejemplo, mantener sólo algunos un intervalo de tiempo especificado) . El estado se purga normalmente una vez que se excede en criterio. El propósito de los cachés es guardar el estado de certificado por un periodo dictado por la política, reduciéndose por esa razón la sobrecarga de las comunicaciones requerido durante la recuperación del estado de certificado y la CRL. El CSS puede por lo tanto crear puentes entre las pausas de comunicación. Las CRLs pueden ser analizadas sintácticamente y los estados de certificados revocados individuales se colocan en un caché para reducir el sobrecarga computacional que resulta ciando la CRL tiene que ser verificada repetidamente. Esto se representa por los caches 305, 307. Los contenidos del caché se reemplazan siempre que se recupera una nueva CRL. Con referencia ahora a la Figura 4, se muestra una sintaxis de ejemplo que representa algunos de los elementos de datos más importantes que necesitan ser incluidos en un bloque de firma digital. La Figura 4 es un ejemplos de forma libre de los elementos de datos que constituyen una fiema digital donde se aplica la firma a múltiples fragmentos de mensaje y un sello de fecha/hora. Este ejemplo se considera ser ilustrativo de la sintaxis que puede ser usada para un bloque de firma digital . Puede ser notado que el elemento de datos <CumulativeHashValue> se aplica a los HashValues de uno o más fragmentos del contenido total y cualquier Dato Autenticado. La Figura 5 representa una arquitectura de comunicaciones seguras que muestra los bloques de construcción que soportan el Servicio de Estado de Certificado. La figura muestra la interacción entre tres CAs, el CSS, y el CTU. El CSS se coloca preferiblemente residente en el TCU para garantizar alta . disponibilidad. Su propósito primario es proporcionar al TCU con una interfaz común y para asegurar la provisión puntual y segura de la información del estado de certificado. Su propósito secundario es asegurar un nivel garantizado de calidad del servicio administrando el sobrecarga de comunicaciones y computacionales requerido para mantener la información de estado del certificado. Como se observa en la Figura 5, el servidor de CSS y el TCU, con un ruteador y centro de comunicaciones adecuados, se disponen ventajosamente, detrás de un cortafuegos de comunicaciones. El ruteador y el centro de comunicaciones dirigen la información al CSS y el TCU como sea apropiado. Algo de esta información comprende envíos de Sellos electrónicos que se dirigen al TCU como se describe arriba, a través de una red tal como la Red Internacional, desde una Aplicación Cliente Usuario. También se representan las comunicaciones de la TCU vía el OCSP. La Figura 5 también representa tres CAs en diferentes -ambientes detrás de cortafuegos de comunicaciones respectivos.-Una Empresa de CA pudiera comprender un servidor que se interconecta con un CA de la Industria de Arrendamientos encerrada por las líneas discontinuas. Una PKI Foránea o Responder pudiera comprender un servidor que se interconecta con las entidades tales como una PKI, CA, y el responder del estado de certificado. Una PKI de Miembros Jerárquicos puede incluir un servidor que interconecta las entidades tales como un V3 LDAP para las CRLs y el estado de certificado, una CA Raíz, y las CAs para las industrias de prestamos hipotecarios y de arrendamientos, pretamizas, agentes de cierre, y aseguradoras de títulos . Las Figuras 6 y 7 representan el uso del Servicio de Estado de Certificado durante el proceso de alistamiento del usuario (el subscriptor o entidad) tanto para las CAs miembros y las CAs externas, respectivamente. Una CA miembro es una que deposita es confiable para emitir certificados de usuario. Las CAs externas son aquellas operadas por entidades por fuera y necesitan ser aprobadas antes que sus cerificados sean usados en conjunción con las actividades del TCU. La autorización de la identidad necesita ser implementada rigurosamente por todas las CAs o delegada a agentes de la organización. Un requerimiento adicional es que un certificado de usuario necesita estar asociado directamente o autorizado para usarse con una o más cuentas de las organizaciones subscriptoras antes que el TCU puede otorgar el acceso a ese usuario. Una vez que esto se logra, el TCU aceptara la firma digital del usuario y confiará en el CSS para certificar la validación del estado del certificado. En la Figura 6, el proceso de alistamiento del TCU comienza en la etapa 601, con la recepción por un, administrador/agente de la organización de la información de alistamiento del usuario desde un patrocinador. En la etapa 603, este administrador/agente se carga con la validación de la autoridad del patrocinador para hacer la solicitud. Los patrocinadores normalmente sólo dan el control sobre sus propias cuentas. En la etapa 605, el administrador/agente enlista al usuario con el TCU, configurando la cuenta de un usuario. En la etapa 607, el administrador/agente puede entonces asignar privilegios de transacción al usuario. Los privilegios de transacción pueden incluir las habilidades para enviar, aplicar una versión, transferir, etc., originales electrónicos y otros registros fuente. En la etapa 609, un ficha criptográfica (mecanismo de firmado digital) se inicia, y en la etapa 611, se genera un par de clave públicas sobre el ficha. En la etapa 613, se crea la solicitud del certificado y en la etapa 615, se envía la solicitud a la CA de la organización. En la etapa 617m se recupera el certificado y se coloca en el ficha. En la etapa 619, se pega o asocia el certificado con la cuenta de TCU del usuario . En la etapa 621, se valida la identidad del usuario, por ejemplo, haciéndose presente en persona al administrador/agente de la organización quien puede validar personalmente la identidad del usuario. Normalmente, al menos se requieren dos formas de identificación. Debido a que la participación del usuario está patrocinada, esto debería ser suficiente, excepto para las transacciones con valor elevado cuando alguien conocido por el administrador/agente puede ser consultado para garantizar la identidad del usuario. En la etapa 623, se pide al usuario firmar un acuerdo de contrato por medio del cual el usuario acepta que el uso de la firma digital es obligatorio. En la etapa 625, se da al usuario un manual de usuario de la aplicación y cualquier instrucción que se considere necesaria. En las etapas 627 y 629 se proporciona al usuario con las IDs de conexión, las contraseñas temporales, y el ficha criptográfico. En la etapa 631, el usuario se registra en el sistema y en la etapa 633, envia un documento de prueba al TCU. en la etapa 635, el TCU valida la firma digital del usuario y lo certifica. En la etapa 637, el CTU consulta al CSS para certificar la información del estado, en la etapa 639, el TCU recibe el estado y procede por consiguiente. Si el estado del certificado recuperado es válido, se completa el alistamiento en la etapa 641, y el usuario es capaz de acceder y usar el TCU. Si el estado del certificado es invalido, termina el alistamiento en la etapa 643, y el administrador/agente determina la causa del error e instituye el remedio, lo cual puede involucrar repetir alguna o todas las etapas del proceso de alistamiento. El proceso confiable resumido en la Figura 6 asegura que el enlistado esta capacitado completamente a la perfección.

En la Figura 7 , se permite al usuario usar un ficha criptográfica publicada previamente por una CA externa si se satisfacen las condiciones dictadas por la política. Como se describe arriba, se siguen las etapas de alistamiento 601 a la 607. Las etapas 621 a la 627 de verificación de la identidad del usuario y contrato se siguen también como se describe arriba . Debido a que el usuario ya tiene un ficha, el proceso se desvía desde el descrito en la Figura 6. En la etapa 701, el usuario coloca el ficha en un lector compatible y se conecta. En la etapa 703, una aplicación del administrador recupera el certificado del usuario desde la ficha. En la etapa 705m se muestra la información del certificado y se obtiene la información de identificación de la CA emisora. La información de la CA se usa en la etapa 707 para verificar que la CA está en la lista aprobada. Si la CA no está en la lista aprobada, se proporciona la información de la CA al administrador del TCU en la etapa 709, y el administrador verifica con una Autoridad de políticas de Aplicación en la etapa 117 en cuanto al permiso para continuar el alistamiento. Sólo la autoridad de políticas de Aplicación puede autorizar agregar una CA externa a la lista aprobada. Si se rechaza el permiso en la etapa 713, el alistamiento termina en la etapa 649 dando al usuario tres opciones. Una es solicitar una ficha emitida por una CA miembro. Otra opción es solicitar una revisión de la decisión de rechazar la CA. La tercera opción es solicitar los nombres de las CAs externas aprobadas previamente. Si la CA emisora se aprueba pero no en la lista en la etapa 713, en la etapa 715 el administrador agrega la CA y la información del conector a la lista aprobada, configurando la CSS para recuperar el estado del certificado desde la CA. En la etapa 619, el certificado del usuario se enlaza o asocia con la cuenta de usuario recién creada. Como en la Figura 6, y las etapas 631 a la 639, se solicita al usuario hacer un envió de prueba al TCU para validar que la cuenta ha sido establecida correctamente y que el usuario puede acceder al TCU. Si el CSS regresa información del estado valida, entonces el alistamiento se completa en la etapa 641. Si el CSS regresa un estado inválido, entonces el administrador determina la causa del error y instituye el remedio, lo cual puede involucrar repetir algunas o todas las etapas del proceso descritas arriba. La causa más probable de falla puede relacionarse con que el CSS sea capaz de alcanzar y recuperar correctamente el estado del certificado desde la CA externa. La CSS juega un papel vital al validar que el certificado del usuario y la CA emisora están ambas autorizadas para accede un TCU u otro sistema, Si se remueve una CA emisora de la lista aprobada y se eliminan sus datos de configuración del conector, se niega a todos los usuarios asociados el acceso ulterior al TCU. Se deberá entender que el CSS puede trabajar con otras aplicaciones que requieren el estado de certificado, incluyendo las aplicaciones y sistemas que requieren inter-trabajar con múltiples PKIs y CAs . Por ejemplo, otro uso del CSS es proporcionar el estado de certificados de autenticación de confianza, incluyendo los certificados auto-f rmados , cuando existe un acuerdo entre el cliente que busca los servicios y el operador de la aplicación. Una representación del certificado de confianza (por ejemplo, PEM, el ID del certificado, la firma digital aplicada) , se guardan en caché por el CSS', y el estado se averigua usando un conector del certificado de confianza. Esto permite a la aplicación tener un solo medio del estado del certificado independientemente de si el certificado fue auto-firmado por una CA. Este método de certificado de confianza puede ser usado cuando se usa un pequeño grupo de certificados controlado por una comunidad en lugar de consultar la CA o CAs de la comunidad. Por lo tanto, se apreciará que los términos "CA y "CA emisora" como se usan en esta solicitud, abarcan tal emisora aceptada de certificados auto-firmados así como a las CAs convencionales . Además, el CSS puede usar una combinación de conectores para recuperar el estado del certificado. Al menos un conector puede ser "virtual" , tal como el recién descrito para usarse con los certificados de confianza. El CSS invoca los conectores en un orden predeterminado, por e emplo, en ' secuencia hasta que se requiera el estado del certificado. Este método permite la creación de una jerarquía de las fuentes del estado (por ejemplo, las más confiables, a las menos confiables) . La figura 8 representa el ejemplo del arrendamiento de automóviles que muestra como el CSS se utiliza en el comercio electrónico. El comerciante de automóviles o el representante del comerciante, llamado de aquí en adelante el comerciante por simplicidad, emitió un certificado de autenticación por una CA Automotriz, la cual se representa como una computadora. El arrendatario del automóvil, quien puede ser presentado como el distribuidor de carros, emitió un certificado de autenticación respectivo mediante una CA Bancaria. Un arrendador remoto emitió un certificado de autenticación respectivo mediante una CA financiera. Alternativamente, ya sea el arrendatario o el arrendador pueden haber creado un certificado auto-firmado, el cual registra el comerciante con la aplicación de arrendamiento y el CSS, por ejemplo, debido a que el arrendatario es un cliente regular del comerciante. Como se explica en esta solicitud, el CSS recupera y reporta el estado para estos y otros certificados usando cualquier medio de reporte del estado de certificado que utilice un protocolo de reporte del estado aprobado. En la Figura 8, se asume que la CA Automotriz y la CA Financiera usan OCSP, que la CA bancaria usa una C L, y que el comerciante y los arrendatarios tienen algunas formas de fichas (por ejemplo, PKC#11, PKC#12 , almacén de claves del buscador, etc.) que contienen sus certificados y medios de firmado criptográfico, se apreciara que la Figura 8 es sólo un ejemplo de la ejecución de una transacción; más o menos las CAs pueden ser conectadas como sea necesario con las comunicaciones como sea necesario para la transacción particular . En la etapa 801 el comerciante ya sea origina el contrato de arrendamiento o lo recupera desde una aplicación de arrendamiento, tal como un programa de computadora que corre localmente en a distribuidora o remotamente en un sitio remoto, por ejemplo, en un Servidor de Aplicaciones. En la etapa 803, el comerciante instrumenta la ejecución del arrendamiento por el arrendatario y el arrendador. El comerciante puede ser mostrado tanto para el arrendatario local y el arrendador remoto en este momento, y el comerciante puede ser visitado para responder cualquier pregunta y hacer correcciones si es necesario. El comerciante puede arreglarse para mostrar el arrendamiento al arrendador proporcionando un URL (localizador de recursos uniforme) al arrendador que permite al arrendador revisar y ejecutar el arrendamiento, con la versión ejecutada regresada al comerciante. Después del firmado local por el arrendador y el comerciante, por ejemplo, con una pe tableta que captura la firma digital del arrendatario en el arrendamiento, y el firmado remoto por el arrendador, se trasmite el arrendamiento (etapa 805) a una Bóveda electrónica, la cual se muestra en comunicación con el Servidor de la Aplicación, el firmado digital por el arrendador y el comerciante es ventajosamente dinámico, con el Servidor de Aplicación que actualiza las pantallas aplicando un indicador de "firmado digitalmente por" a l (las) imagen (es) mostradas. -Las firmas digitales reales preferiblemente no se muestran. Se reconocerá que el Servidor de la Aplicación y la Bóveda electrónica Asociada pueden ser usados por el comerciante para escenificar el contrato para el firmado remoto por el arrendador. En las etapas 807 a la 811, el arrendador recupera el arrendamiento desde la bóveda, acepta los términos del arrendamiento firmándolo digitalmente, y regresa su versión firmada digitalmente a la bóveda. Las etapas 807 a la 811 ilustran tanto el procesamiento de colaboración multi-sitios y de transacción asincrónica.

En las etapas 813 a la 817, el (los) documento (s) (el contrato de arrendamiento) se verifican en cuanto a las firmas digitales, y si se encuentra alguna, se verifican las firmas digitales y se validan los certificados de autenticación respectivos, en la etapa 817, se verifica la hora local para asegurase que cae dentro del (de los) periodo (s) de validez del (de los) certificado (s) , y en la etapa 819, se consulta el CSS en cuanto el estado del (de los) certificado (s) . En respuesta en la etapa 821, el CSS verifica primero su memoria caché local o el almacén de datos en cuanto al estado de certificado, y si está presente un estado de certificado, y actualizado, el CSS regresa el estado de certificado como "activo" en la etapa 827. En la etapa 823, si no está presente el estado de certificado no actualizado, el CSSS consulta la , CA emisora usando el tipo de conector creado para este propósito. En la etapa 825 la CA emisora, por ejemplo, la CA Bancaria , o sus medios de reporte del estado (por ejemplo, un directorio) regresa el estado al CSS, preferiblemente usando el mismo conector, y en la etapa 827, el CSS reporta el estado del certificado consultado de vuelta al Servidor de la Aplicación. Asumiendo que todas las firmas digitales y los certificados se verifican y validan, probando que el documento electrónico es auténtico, el Servidor de la aplicación asume el control del documento electrónico y lo salva en la bóveda electrónica como una nueva versión en la etapa 829. Por lo tanto, se observará que, con las características apropiadas, el Servidor de la Aplicación y la Bóveda electrónica cooperan como un TCU. En la etapa 831, la nueva versión se designa como una copia autorizada, un Original Electrónico que puede ser un registro transferible, anexando un sello de fecha-hora y aplicando la firma digital del TCU al documento. Siempre y cuando al menos una firma digital en un documento sea válida, esta etapa toma lugar. En la etapa 833, si alguna firma digital o certificado falla en pasar todas las pruebas, el comerciante es alertado de buscar el remedio, el cual involucra típicamente en repetir las etapas 801 a la 829 hasta que se apliquen firmas digitales de reemplazo validas. El proceso del remedio no puede ser completado si el estado de un certificado firmado se revoca o expira hasta que un nuevo certificado y el material criptográfico se emitan. Se deberá entender que un objeto de información, tal como un contrato de arrendamiento para un automóvil, puede estar presente en una forma electrónica, por ejemplo, XML, PDF, PKCS#7, S/MIME, etc., que permita la colocación y detección de firmas electrónicas y previene la modificación no autorizada. Muchas de estas formas pueden ser consideradas como envoltorios o cubiertas que proporcionan seguridad para la información incluida. Se entenderá también que el CSS puede ser usado para verificar el estado de los certificados independientemente del uso de la clave. Tales certificados incluyen, pero no se limitan a, aquellos para los cuales el uso primario no es la identificación y la autenticación, por ejemplo, acuerdos /intercambios de clave, firmado de certificados, firmado de CRL, encriptación de la clave, encriptación de datos, sólo encriptación, sólo decriptación, y nivel de conectores seguros (SSL) . Por consiguiente se entenderá que cuando se usa en esta solicitud, el término "certificado de autenticación" abarca de manera general tales certificados que no se usan para la identificación. Además, el conector del CSS puede ventajosamente incrustar más de una verificación del estado de certificado en una sola comunicación. Entre otras cosas, esta capacidad puede ser usada al validar algunos o todos de una cadena de certificados y certificados de CA, por ejemplo, una jerarquía de CAs desde una CA Raiz hasta una CA emisora. Esto proporciona una seguridad adicional de que todas las CAs en la vía del certificado son aun validas. Esta solicitud ha descrito un método para configurar un Servicio del Estado de Certificado (CSS) que incluye las etapas de, determinar la información de configuración necesaria para recuperar el estado de certificado para una CA emisora requerida, identificar un conector compatible con una técnica de búsqueda del estado de certificado usada para recuperar el estado de certificado desde la CA emisora, configurar el conector con los parámetros de configuración y comunicaciones específicos para el conector seleccionado y la CA emisora, y establecer una correlación del CSS entre la CA emisora y el conector. La designación de la CA y el conector se agrega a una lista de CAs aprobadas en un almacén de configuración. Un método para ejecutar una transacción transfiriendo objetos de información autenticados que tienen rastros de evidencia verificable respectivos incluye la etapa de recuperar, por una primera parte desde un depósito de confianza, un objeto de información autenticado. El objeto de información autenticado incluye una primera firma digital de la parte remitente, un primer certificado que relaciona al menos una identidad y una clave criptográfica para la parte remitente, una fecha y hora confiables, una firma digital del depósito de confianza, un certificado que relaciona al menos la identidad y la clave criptográfica con el depósito .de confianza; la firma digital y el certificado de la parte remitente que han sido validados por el deposito de confianza al atestiguar el envío para la autenticidad del objeto de información; y el objeto de información autenticado que ha sido puesto en almacenamiento como un objeto de información original electrónico puesto bajo el control del depósito de confianza. El método de ejecución de la transacción incluye las etapas de solicitar a cualquier entidad firmante a comprometerse al uso de estar comprometido por su firma digital antes del acto de firmado, la ejecución de dicho objeto de información por cualquier parte, consiste de la inclusión de al menos la firma digital y el certificado de autenticación de la parte firmante, crear un bloque de forma que contiene al menos la firma digital y el certificado de autenticación de la parte firmante, asociar el bloque de firma con el objeto de información, repetir las etapas de ejecución previas cuando múltiples entidades firman el objeto de información y/o el envoltorio, y transmitir el objeto de información y/o el envoltorio firmados digitalmente a un TCU. el TCU verifica cada firma digital y valida cada certificado de autenticación asociado y recupera el estado desde el GSS . Los bloques de firma se rechazan si la firma digital del firmante no se verifica o un certificado de autenticación del firmante ha expirado o se reporta que ha sido revocado. El rechazo de cualquier bloque de firma resulta en una solicitud en cuanto al reemplazo del bloque de firma o el inicio del remedio. Si se determina que al menos un bloque de firma es valido, el TCU anexa su propio bloque de firma, conteniendo también la fecha y hora confiables, al objeto de información objetivo. Creando un original electrónico el cual guarda y controla en representación del propietario. Crear un bloque de firma digital puede incluir las etapas de computar uno o más procesos hash del contenido para los uno o más fragmentos del objeto de información o para el objeto de información completo, computar un proceso hash sobre el uno o más procesos hash del contenido y cualquiera de los datos anexados, tales como la fecha y hora locales, el fundamento de la firma, o una instrucción, encriptar el proceso hash computado usando la clave privada de la parte firmante, formando por ello la firma digital del firmante, y colocar la firma digital del firmante en el bloque de firma junto con el certificado de autenticación del firmante. Si los datos anexados incluyen una fecha y hora locales, crear un bloque de firma digital puede incluir además las etapas de, ya sea mostrar la fecha y hora locales, pedir a un firmante afirmar que la fecha y hora con correctas, y corregir la fecha y hora ya sea si son incorrectas, o confiar en una fecha y hora del sistema si estas son establecidas por el servicio de horario de confianza y la fecha y hora se protegen de la manipulación indebida. La fecha y hora locales pueden ser verificadas para asegurarse de que son exactas y que caen dentro del periodo de validez del certificado de autenticación del usuario y que la fecha y hora locales no están ni antes ni después de las fechas y horas especificadas por el periodo de validez. El remedio de una firma digital que falla la verificación requiere que la firma digital sea recomputada y el bloque de la firma sea retransmitido. Remediar una violación del periodo de validez del certificado de autenticación incluye notificar que el certificado del usuario ha expirado y debe ser renovado y notificar al propietario de la transacción que la transacción está incompleta. La ubicación de uno o más bloques de firma y la información contenida en los mismos se específica mediante al menos una etiqueta de firma. Una o más firmas y fechas escritas a mano y se digitalizan y se usan para la ejecución del objeto de información, y la ubicación de las firmas y fechas se específica mediante el manos una etiqueta de firma. Uno o más bloques de firma pueden ser enviados al TCU por separado junto con la designación de las etiquetas de firma correspondientes y el TCU valida cada bloque de firma enviado independientemente o como un grupo. Si ya .sea la etapa de verificación de la firma digital o de validación del certificado de autenticación falla, el TCU rechaza el bloque de firma y puede solicitar el remedio, y si la etapa de validación del bloque de firma tiene éxito, el TCU coloca el bloque de firma en la etiqueta indicada. Para enviar los bloques de firma por separado, el TCU puede agregar una fecha y hora confiables para a cada bloque de firma. De acuerdo a las reglas de negocios, el TCU anexa su propio bloque de firma que contiene una fecha y hora confiables en un envoltorio que abarca los campos del objeto de información objetivo y el bloque de firma insertado, creando por ello un objeto de información original electrónico. Los bloques de firmas de usuarios múltiples pueden ser agregadas dentro de un envoltorio, y . los envoltorios pueden ser aplicados recursivamente para implementar otros negocios y procesos de seguridad. El TCU puede validar la (las) firma (s) digital (es) ) y el (los) certificado (s) de autenticación presentes en un bloque (s) de firma que deberá/n estar contenidos dentro o deberá/n ser agregados al contenido de un objeto de información original electrónico verificando en la base de datos de reglas de negocios que la entidad firmante identificada por el certificado de autenticación tiene la autoridad para llevar a cabo la acción requerida, verificar la firma digital de la entidad firmante, verificar que el periodo de validez del certificado se sobrepone a la fecha y hora confiables, verificar que la fecha y la hora locales transmitidas caen dentro de la desviación permisible con la fecha y hora del TCU, y verificar el estado de certificado usando un CSS . Si alguna de estas etapas resulta en una salida inválida o falsa, la firma digital se considera inválida, se prohibe la acción requerida y se busca el remedio; de lo contrario, la firma digital se considera válida y se permite la acción requerida. El registro de una CA emisora con el CSS puede incluir las etapas de validar y aprobar la CA emisora para su inclusión en la · base de conocimiento del CSSS como "autorizada" en base a las reglas de negocios de la industria u organización y las políticas del sistema. Si la etapa de validación falla, la CA emisora se agrega al almacén de configuración del CSS como "no autorizada" y/o termina el registro de la CA; de lo contrario, la CA emisora se agrega como "autorizada" , y los parámetros de comunicación (dirección IP, clave y certificado de SSL) y el método usado para reportar el estado de certificado (OCSP, CRL, LDAP) se agregan, al almacén de configuración del CSS, y el conector para interpretar el estado de certificado se agrega si no se ha implementado ya. De esta manera, el CSS permite la interoperatividad entre un sistema o TCU y un grupo diverso de contestadores del estado de certificado.

La verificación del estado de cerificado emplea ventajosamente un CSS para establecer las comunicaciones, recuperar y guardar en el caché el estado de certificado desde las CAs que emiten el certificado aprobadas. Cuando el CSS recibe la consulta del estado de certificado desde un sistema o TCU, el CSS verifica primero su caché local para ver si está presente el estado de certificado y si se encuentra y está dentro del intervalo de tiempo de vida, regresa el estado, si el estado de certificado no está presente o está fuera del intervalo de tiempo de vida, entonces el CSS recupera el estado solicitando primero la información de conexión desde su almacén de configuración. El CSS establece entonces una sesión de comunicación con el componente de reporte del estado de certificado identificado en su almacén de configuración. El CSS crea una solicitud del estado de certificado a través del método contenido en el almacén de configuración del CSS, y el CSS recupera el estado de certificado desde el componente de reporte del estado de certificado y cierra la sesión con el componente. El CSS agrega al menos la ID del certificado, el estado de certificado y tiempo de vida a su caché y regresa el estado de certificado al sistema solicitante o TCU. El reporte del estado de certificado puede estar basado en un C L, y el procesamiento de la CRL. De acuerdo al programa de publicación de la CA, el CSS recupera la CRL desde el componente de reporte del estado de certificado listado en el almacén de configuración del CSS. El CSS limpia su memoria caché asociada con la CA emisora, analiza sintácticamente el estado de certificado desde la CRL, y coloca el estado de certificado en su caché asociado con la CA emisora. Tras la notificación por una CA emisora de que está disponible una CRL, el CSS puede recuperar la CRL desde el componente de reporte del estado de certificado listado en el almacén de configuración del CSS. Cuando se requiere por los estándares que la CRL sea una CRL completa, entonces la CSS limpia la caché asociado con la CA emisora, analiza sintácticamente la CRL, y coloca el estado de certificado y la información relacionada en el caché asociado con la CA emisora. Cuando la CRL contiene sólo los cambios que ocurren después de la publicación de una CRL completa, el CSS analiza sintácticamente el estado del certificado desde la CRL y coloca el estado de certificado y la información relacionada en el caché asociado con la CA emisora. Usar el CSS para obtener el estado de certificado que permite a un usuario; sistema o TCU usar un sólo medio para obtener el estado de certificado puede incluir las etapas de consultar al CSS en cuanto al estado de un certificado de autenticación presente en un bloque de firma en un objeto de información, donde la consulta del estado puede usar un medio único (por ejemplo, OCSP) , traducir la consulta del estado a una forma requerida por la CA emisora, y recuperar y/o reportar el estado de certificado. Si el estado de certificado está revocado, el bloque de firma no se usa y se solicita el remedio, si la firma digital verifica y certifica que el estado es valido, se agrega el bloque de firma al objeto de información original electrónico. El TCU puede consultar al CSS para validar un estado de certificado de autenticación del firmante localizado y reportando el estado de certificado si el estado está presente y actualizado en el almacén de caché/datos del CSS, y obteniendo el tipo y el medio para recuperar el estado del certificado desde el almacén de configuración del CSS . Si el método de estado del certificado particular es una CRL y el estado del certificado especificado no se encuentra en el caché de la CA emisora en el CSS, entonces el CSS reporta el-estado del certificado como válido. Si el método del estado del certificado no es una CRL, entonces el CSS crea una solicitud del estado del certificado a través del método contenido en el almacén de configuración del CSS, y establece las comunicaciones apropiadas con la CA emisora'. El CSS recupera el estado desde el componente de reporte del estado usando el método de verificación del estado del certificado identificado y cierra la sesión de comunicación. El CSS analiza sintácticamente o interpreta el estado del certificado recuperado asocia un valor de tiempo de vida igual al periodo especificado por el tipo del estado y establecido en la política del CSS, y agrega al menos los valores de ID, estado, y tiempo de vida del certificado al caché del estado del certificado de la CA emisora. El CSS regresa entonces el estado del certificado al sistema solicitante. Un método para alistar usuarios en un sistema o TCU donde se emite el certificado por una CA emisora aprobada que es conocida por el CSS incluye validar el usuario utilizando los procedimientos y criterios de membresía establecidos, introducir la información de alistamiento del usuario que ya ha sido firmado por un patrocinador aprobado de la organización, y crear y enviar una solicitud de certificado al la CA emisora identificada. El certificado de autenticación del usuario se recupera, emite y coloca en una ficha para su entrega. La firma digital, la verificación de la firma digital, y la verificación del estado de certificado se llevan a cabo para asegurase que el proceso de generación de la clave pública y de emisión del certificado fueron completadas correctamente. Se pide al usuario que firme el acuerdo de aceptación del usuario que compromete al usuario a dar el mismo peso al uso de la firma digital como al que estos dan al uso de su firma manuscrita, se entrega la ficha al usuario y se activa la cuenta del sistema del usuario o el TCU. Un método para alistar o inscribir usuarios en un sistema o TCU donde el usuario ya tiene un certificado emitido por una CA que no se conoce previamente por un CSS puede incluir consultar la ficha del usuario en cuanto al certificado de autenticación del usuario y obtener la información del usuario, y consultar la base de conocimientos del CSS para ver si la CA emisora está contenida en la misma. Si no, se contacta el administrador de la política industrial o la organización para determinar si o no la CA emisora satisface las reglas del sistema para la inclusión de la CA. Cuando la CA emisora se considera "no autorizada", termina el registro, y cuando la CA emisora se considera "autorizada", el alistamiento o inscripción procede como se describe arriba. Una porción de los contenidos del certificado e autenticación del usuario puede ser usada para enlazar el certificado a una cuenta de usuario, aprobando después al usuario para el acceso al sistema o TCU, introducir la información de alistamiento del usuario, insertando la ficha del usuario, que contiene su certificado de autenticación, en un lector local de fichas, recuperar y mostrar los contenidos del certificado, habiendo afirmado el usuario que los contenidos son correctos, y agregar los campos seleccionados al los datos de alistamiento del usuario del sistema o TCU que se extraen desde el certificado, tales como la ID del certificado, un subgrupo de nombres distintivos del usuario u otra información de identificación transmitida en las extensiones del certificado (por ejemplo, subjectAIName) . Los datos extraídos pueden estar especificados en la política del sistema o TCU de modo que la extracción y entrada de datos puede ser automatizada. Un método por medio del cual un remitente de un objeto de información garantiza la autenticidad de un objeto de información enviado incluye la etapa de anexar el bloque de firma del remitente a un objeto de información y/o envoltorio y transmitirlo a un sistema o TCU. si falla la validación del bloque de firma, el TCU solicita la retransmisión o el remedio, y si el bloque la validación del bloque de firma tiene éxito, el TCU verifica entonces que la identidad del remitente corresponde a la del iniciador de la sesión de comunicación, rechazando el envío si el iniciador y el remitente son diferentes. Si todas las verificaciones tienen éxito, el TCU agrega su bloque de firma al envío, creando un objeto de información electrónica original. Un método en un CSS para mantener el estado del certificado exacto y puntual para el medio de reporte de estado del certificado en tiempo real que emplea un elemento de tiempo de vida incluye esas etapas . Su se usa un método de estado de CRL, entonces el CSS reporta el estado, si el estado del certificado está en el caché y el elemento de datos de tiempo de vida no está excedido, entonces el CSS reporta el estado. si el elemento de datos de tiempo de vida está excedido, el CSS limpia la entrada del estado del certificado del caché de la CA emisora. Si se recupera el estado usando un medio de reporte del certificado en tiempo real (por ejemplo, OCSP, consulta LDAP, etc) y el estado no está en el caché, el estado del certificado se solicita, recupera y reporta. El CSS agrega entonces al menos la ID del certificado, el estado del certificado y el tiempo de vida a su caché y regresa el estado del certificado al sistema o TCU solicitante. Un elemento de datos de contador de usuario del estado del certificado puede ser agregado a una entrada de estado del certificado en el caché de la CA emisora del CSS, .y el contador de usuario del estado puede ser incrementado o restado cada vez que se verifica el estado del certificado. Si el contador de usuario del estado del certificado pasa de un umbral establecido por la política del CSS, entonces el estado del certificado puede ser reportado, pero el CSS limpia entonces la entrada del estado del certificado del caché de la CA emisora. Si el estado del certificado regresado por el CSS es invalido o revocado, entonces el sistema o TCU registra y/o reporta el error al remitente y/o el propietario de la transacción, y se prohibe la acción requerida y se busca el remedio. Por el contrario, la firma digital se considera válida y se permite la acción solicitada. Un elemento de datos del estado accesado al final puede ser agregado y usado en conjunción con el contador de usuario para determinar el nivel de actividad del estado del certificado. Un proceso de respaldo puede original que el CSS recupere automáticamente el estado del certificado actualizado y establezca nuevos elementos de datos de tiempo de vida y contador de usuario cuando se cumple un criterio en la política del CSS. Esta pre-búsqueda puede ser activada para acortar el tiempo promedio entre la solicitud por el estado del certificado del sistema o TCU y la respuesta del CSS. Si se hace una solicitud al CSS para recuperar el estado del certificado para un nuevo certificado y el caché de la CA emisora ha alcanzado su límite de tamaño del búfer asignado, el elemento de datos del estado de certificado accesado al último puede ser agregado a la entrada del estado del certificado en el caché de la CA emisora del CSS. El CSS busca el caché de la CA emisora pro el elemento de datos del último acce4so para la fecha más antigua (menos frecuentemente usada) y limpia esa entrada. El CSS recupera entonces el estado del certificado solicitado, lo coloca en la posición liberada en el caché de la CA emisora y reporta el estado al sistema o TCU, el cual actúa de acuerdo a la política. Un método de verificación del estado en un CSS distribuido incluye la coordinación entre los CSSs si se introduce una nueva CA emisora, establecer estradas en todas las bases de conocimiento del CSS si otro CSS tiene la responsabilidad primaria para consultar una CA emisora, consultar otros CSSs en lugar de una CA emisora, para reducir las comunicaciones entre los CSS y las CAs emisoras, sincronizar y guardar en caché los estados de certificados localmente si los sistemas locales tienen una concentración densa de solicitudes de estados de certificado contra una CA emisora, y compartir o transferir la responsabilidad de la consulta si otros CSS tienen una actividad mas densa con una CA emisora dada que la CSS primaria original. Excluir un grupo de usuarios asociados con una CA emisora cambiando la referencia de la CA emisora en una base de conocimiento del CSS a "no aprobada" puede hacerse solicitando que la aprobación para la CA emisora sea retirada, revisando la solicitud sobre el mérito y determinando si una acción es necesaria, y si se determina que por alguna razón la CA emisora debe ser inhabilitada, entonces cambiando el estado de la CA en la base de conocimiento del CSS a "no aprobada" . Cualquier solicitud subsecuente en cuanto al estado de un certificado emitido por una CA listada como "no aprobada" resulta en el que el CSS regresa un estado de fallo. Un método para re-habilítar un grupo de usuarios inhabilitados estableciendo previamente una referencia de la CA emisora a "no aprobada" puede hacerse solicitando que se otorgue la aprobación para re-habilitar la CA emisora, revisando la solicitud sobre el mérito y determinando si es necesaria alguna acción, y si se determina que la CA debe ser re-habilitada, entonces cambiando el estado de la CA emisora en una base de conocimiento del CSS a "aprobada" . El CSS procesa las solicitudes en cuanto al estado del certificado para las CAs emisoras reinstaladas como lo haría con cualquier otra CA "aprobada" . La comunicación con los componentes de reporte del estado puede ser establecida creando un aparato modular y reutilizable para cada protocolo de estado del certificado usado para localizar, solicitar y recuperar tal información, usando una versión del aparato que es compatible con todas las CAs y contestadores que entienden un protocolo de estado del certificado particular, y que tienen una versión del aparato para cada protocolo de reporte de estado del certificado que está en uso. El aparato se diseña de modo que es fácilmente adaptable para soportar los protocolos de reporte del estado de certificado futuros . Ejecutar una transacción en la cual el remitente es un primer TCU y el envío es para transferir la custodia de uno o más originales electrónicos a un segundo TCU puede incluir, que el propietario de la transacción haya instruido al primer TCU para transferir' la custodia de uno o más documentos originales electrónicos a un segundo TCU. El propietario de la transacción instruye al segundo TCU para transferir la custodia de uno o más documentos electrónicos digitales, y el propietario proporciona al primer TCU con un manifiesto que identifica cuales originales electrónicos deberán ser transferidos al segundo TCU. El primer TCU establece las comunicaciones con el segundo TCU, e identifica el propósito de sus acciones para el segundo TCU. El primer TCU o el propietario pueden transmitir el manifiesto al segundo TCU, de modo que es capaz de determinar cuando ha sido completada la transferencia o custodia. El primer TCU transfiere cada original electrónico identificado al segundo TCU, el cual usa el CSS para asegurarse que la firma digital del primer TCU en cada original electrónico transferido es valida y que los originales electrónicos están inalterados. Si algunas de las firmas digitales del primer TCU son invalidas, entonces el segundo TCU notifica al primer TCU y busca el remedio (por ejemplo, pide al primer TCU volver a firmar usando el certificado de autenticación actual) . Si el primer TCU es incapaz de cumplir, el TCU registra el evento y notifica el propietario de la transacción que la transferencia solicitada de la custodia ha fallado, por el contrario, el segundo TCU crea un nuevo envoltorio por cada objeto de información transferido exitosamente, agregando un sello de fecha-hora y su bloque de firma. El segundo TCU notifica al primer TCU de cada transferencia exitosa, y tras la terminación, el primer TCU puede, a la discreción del propietario, ya sea marcar o retener las copias de manera tal que estas no pueden ser consideradas originales, o puede destruir todas las copias que existen de los objetos de información transferidos. El proceso se repite hasta que todos los originales electrónicos identificados se transfieren. De esta manera, el segundo TCU se vuelve el custodio de los registros transferidos que son las copias autorizadas. El segundo TCU puede anexar una fecha y hora confiables, firmar digitalmente, envolver y almacenar el manifiesto para hacerlo un elemento independiente del proceso de custodia. Al ejecutar una transacción, las instrucciones del propietario puede establecer también que tome lugar la transferencia de la propiedad, y la transferencia de la documentación de propiedad puede ser colocada ya sea en el primero o el segundo TCU. El TCU responsable válida la autenticidad de la transferencia de los documentos de propiedad verificando todas las firmas digitales, verifica los periodos de validez, y utiliza el CSS para verificar el estado del certificado . El TCU puede anexar entonces la fecha y hora confiables, y firma digitalmente, envuelve y almacena ahora estos objetos de información electrónicos originales, los cuales se agregan al manifiesto. Cuando estos originales electrónicos se colocan en el primer TCU, la transferencia de la propiedad se implementa antes de la transferencia de la custodia, y el manifiesto de iniciación se vuelve parte del proceso de propiedad. Algunos de los registros transferidos pueden ser simples objetos de información electrónica y no sólo originales electrónicos . El CSS puede usar cualquier protocolo de estado del certificado apropiado para comunicarse con un sistema o TCU Esta invención puede ser incorporada en muchas diferentes formas sin apartarse de su carácter esencias, y por lo tanto las modalidades descritas arriba deben ser consideradas ilustrativas, no restrictivas, en todos aspectos. Se enfatiza que los términos "comprende" y "que comprende" , cuando se usan en esta descripción y en las siguientes reivindicaciones, se consideran como especificando la presencia de las características establecidas sin imposibilitar la presencia de una o más características adicionales. El ámbito pretendido de la invención se establece mediante las siguientes reivindicaciones, en lugar que por la descripción precedente, y todas las variaciones que caen dentro del ámbito de las reivindicaciones se consideran estar abarcadas en las mismas.

Claims (33)

1. 80
2. REIVINDICACIONES 1. Un método para proporcionar un Servicio de Estado de Certificado ("CSS"), para verificar la validez de los certificados de autenticación emitidos por las Autoridades de Certif cación ("CAs") respectivas, caracterizado porque comprende las etapa de : identificar la información necesaria para recuperar un estado de un certificado de autenticación desde una CA emisora que emite el certificado de autenticación; configurar un conector en base a la información identificada para la comunicación con la CA emisora; comunicarse con la CA emisora de acuerdo al conector configurado cuando se consulta el estado del certificado de autenticación; y recuperar el estado del certificado de autenticación; en donde la CA emisora y el conector se designan en una lista de CAs aprobadas en un almacén de configuración. 2. El método de la reivindicación 1, caracterizado porque, se verifican una fecha y hora en cuanto a si estas caen dentro de un periodo de validez indicado en el certificado de autenticación.
3. 3. El método de la reivindicación 1, caracterizado porque, la CA emisora se incluye en la lista de CAs aprobadas validando y probando la CA emisora de acuerdo a las reglas de 81 negocios predeterminadas, y si la CA emisora está validada y no aprobada, la CA emisora se designa en una lista de CAs no aprobadas en el almacén de configuración.
4. 4. El método de la reivindicación 3, caracterizado porque, la validación y aprobación de la CA emisora incluye registrar una representación de un certificado de autentificación de confianza con el.CSS y agregar la menos la representación, el estado y el elemento de datos de tiempo de vida a una memoria de caché local, y se configura un conector para recuperar el estado agregado cuando se consulta el estado del certificado de autenticación dé confianza.
5. 5. El método de la reivindicación 2, caracterizado porque que comprende además las etapas de verificar una memoria caché local en cuanto al estado, y si se encuentra el estado en la memoria de caché local, y la fecha y hora están dentro del periodo de validez, recuperar el estado desde la memoria de caché local, en donde si no se encuentra el estado en la memoria de caché local o si la fecha y hora local no están dentro del periodo de validez, el CSS establece una sesión de comunicación con un componente de reporte del estado del certificado de la CA emisora, crea una solicitud del estado del certificado de acuerdo al conector configurado, recupera el estado desde el componente de reporte del estado del certificado, cierra la sesión de comunicación con el 82 componente de reporte del estado del certificado, y agrega al menos la identificación del certificado de autenticación, y el tiempo de vida a la memoria de caché local .
6. 6. El método de la reivindicación 1, caracterizado porque, el estado de certificado se indica mediante una Lista de Revocación de Certificados (CRL) de acuerdo a un programa de publicación de la CA emisora, el CSS recupera el CRL desde un componente de registro del estado del certificado listado en el almacén de configuración, el CSS limpia una memoria caché asociada con la CA emisora, y el CSS determina el estado del certificado de autenticación a partir de la CRL y almacena el estado en la memoria caché asociada con la CA emisora.
7. 7. El método de la reivindicación 1, caracterizado porque, el estado del certificado está indicado por una Lista de Revocación de Certificados Delta ("CRL"); tras la notificación por la CA emisora de que se encuentra disponible una CRL, el CSS recupera la CRL desde un componente de reporte del estado del certificado listado en el almacén de configuración; si la CRL es una CRL completa, entonces el CSS limpia una memoria caché asociada con la CA emisora, determina el estado del CRL, y almacena el estado en la memoria caché; y si la CRL contiene sólo los cambios que ocurren después de la publicación de una CRL completa, el CSS determina el estado a partir de la CRL, y almacena el estado en la memoria caché. 83
8. 8. El método de la reivindicación 1, caracterizado porque, la etapa de comunicación incluye comunicarse de acuerdo a una secuencia de conectores.
9. 9. El método de la reivindicación 1, caracterizado porque, un conector incrusta más de una verificación del estado del- certificado en una sola etapa de comunicación.
10. 10. El método de la reivindicación 1, caracterizado porque, el certificado de autentificación no se usa para la identificación .
11. 11. Un método para recuperar un estado de un certificado de autenticación emitido por una autoridad de Certificación emisora ("CA") en respuesta a una consulta desde un Servicio de Custodia de Confianza ("TCU") a un Servicio del Estado del Certificado ("CSS") para validar el estado del certificado de autenticación, caracterizado porque comprende las etapas de : localizar y reportar el estado si el estado está presente y actualizado en una memoria caché del CSS; por el contrario, llevar a cabo las etapas de: obtener un tipo del estado y el método de recuperación desde un almacén de configuración del CSS; si el tipo de estado es una Lista de Revocación · de · Certificados ("CRL") y el estado no se encuentra en la memoria caché, entonces reportar el estado como válido; si el tipo del estado no es una CRL, entonces crear una 84 solicitud del estado del certificado de acuerdo al tipo de estado; establecer una sesión de comunicación con la CA emisora ,- recuperar el estado desde un componente de reporte del estado de la CA emisora usando el método de recuperación obtenido y finalizar la sesión de comunicación; interpretar el estado recuperado; asociar con el estado recuperado interpretado, un valor de tiempo de vida que representa un periodo especificado por una política del CSS para el tipo de estado; agregar al menos la identificación del certificado de autenticación, y los valores de estado, y tiempo de vida a la memoria caché; y reportar el estado al TCU en respuesta a la consulta.
12. 12. El método de la reivindicación 11, caracterizado porque, el CSS utiliza un protocolo de estado del certificado en la sesión de comunicación.
13. 13. El método de la reivindicación 11, caracterizado porque, más de un estado se recupera usando el método de recuperación obtenido.
14. 14. El método de la reivindicación 11, caracterizado porque, el certificado de autenticación no se usa para la identificación.
15. 15. Un servicio de estado del certificado ("CSS") para 85 proporcionar el estado del certificado preciso y puntual de los certificados de autenticación emitidos por las autoridades de certificación (¾CAs") emisoras, caracterizado porque, comprende : proporcionar un estado de un certificado de autenticación como se indica por una lista de evocación de certificados ("CRL") cuando la CA emisora del certificado utiliza CRLs para indicar el estado; por el contrario, proporcionar el estado indicado por una memoria caché cuando la memoria caché incluye un estado y un elemento de datos de tiempo de vida no está excedido; si el elemento de datos de tiempo de vida está excedido, limpiar el estado de la memoria caché; solicitar y recuperar el estado usando un protocolo de reporte del estado del certificado en tiempo real cuando el estado no está en la memoria caché; agregar el menos la identificación del certificado, el estado, y el elemento de datos de tiempo de vida a la memoria caché; y proporcionar el estado recuperado.
16. 16. El CSS de la reivindicación 15, caracterizado porque, un elemento de datos de contador de uso del estado se agrega a la memoria caché; el elemento de datos del contador de uso del estado se incrementa o resta cada vez que se verifica el 86 estado del certificado; y si el elemento de datos del contador de uso del estado pasa de un umbral, entonces el estado se proporciona y la memoria caché se limpia con respecto al estado .
17. 17. El CSS de la reivindicación 16, caracterizado porque, el elemento de datos del estado accesado al último se agrega a la memoria caché, y el elemento de datos del estado accesado al último en conjunción con el elemento de datos de contador de uso del estado permite la determinación de un nivel de actividad del estado del certificado.
18. 18. El CSS de la reivindicación 17, caracterizado porque, cuando se hace una solicitud al CSS para recuperar un estado de un nuevo certificado y la memoria caché ha alcanzado un límite del tamaño del búfer asignado, el CSS investiga la memoria caché por un elemento de datos del estado accesado al último, indicando una fecha más antigua y limpia la entrada respectiva de la memoria caché; y el CSS recupera entonces el estado solicitado, lo coloca en la memoria caché, y proporciona el estado solicitado.
19. 19. Un método para ejecutar una transacción entre una primera parte y una segunda parte transfiriendo en control de un objeto de información autentificado que tiene un rastro de evidencia verificable, caracterizado porque, comprende las etapas de : 87 recuperar un objeto de información autenticado desde un depósito de confianza, en donde el objeto de informaron autenticado incluye un primer bloque de firma digital que comprende una firma digital de una parte remitente y un primer certificado de autenticación que relaciona al menos una identidad y una clave criptográfica con la parte remitente, un indicador de fecha y hora, y un segundo bloque de firma digital que comprende una segundas firma digital del depósito de confianza y un segundo certificado de autenticación que relaciona al menos una identidad y una clave criptográfica con el deposito de confianza; el primer bloque de la firma digital fue validado por el depósito de confianza; y el objeto información autenticado se almacena como un objeto de información original electrónico bajo el control del depósito de confianza; ejecutar el objeto de información autenticado, recuperado por la segunda parte incluyendo en el objeto de información autenticado recuperado un tercer bloque de firma digital que comprende al menos una tercera firma digital y un tercer certificado de autenticación de la segunda parte; y transmitir el objeto de información autenticado recuperado a un servicio de custodia de confianza ("TCU"), 'en donde el TCU verifica las firmas digitales y válida los certificados de autenticación asociados con las firmas 88 digitales incluidas en los objetos de información mediante el menos la recuperación del estado de los certificados de autenticación desde un servicio del estado del certificado ("CSS") proporcionado de acuerdo a la reivindicación 1; la TCU rechaza un bloque de firma digital si no se verifica la firma digital respectiva o el estado del certificado de autenticación respectivo ha expirado o está revocado; y si al menos un bloque de firma en el objeto de información no se rechaza, el TCU anexa el bloque de forma digital del TCU y un indicador de fecha y hora al objeto de información y toma el control del objeto en representación de la primera parte.
20. 20. El método de la reivindicación 19, caracterizado porque, el bloque de la firma incluye al menos un proceso hash de al menos una porción del objeto de información en el cual se incluye el bloque de firma, el al menos un proceso hash se encripta mediante la clave criptográfica del firmante respectivo del bloque, formando por ello una firma digital del firmante, y la firma digital del firmante se incluye en el bloque de firma con el certificado de autenticación del firmante.
21. 21. El método de la reivindicación 20, caracterizado porque, la etapa de ejecución incluye mostrar una fecha y hora locales a la segunda parte, afirmar, por la segunda parte, que la fecha y la hora locales mostradas son correctas, y corregir 89 la fecha y hora locales si cualquiera es incorrecta.
22. 22. El método de la reivindicación 19, caracterizado porque, si el TCU rechaza un bloque de firma digital, el TCU solicita un remedio que requiere que la firma digital sea recomputada y él bloque de la firma sea retransmitido.
23. 23. El método de la reivindicación 19, caracterizado porque, el TCU verifica la fecha y hora locales en cuanto a su exactitud y que estas estén dentro del periodo de validez indicado por el certificado de autenticación de la segunda parte.
24. 24. El método de .la reivindicación 23, caracterizado porque, si la fecha y hora locales no están dentro del periodo de validez indicado por el certificado de autenticación de la segunda parte, el TCU notifica a la segunda parte que el certificado de autenticación se ha rechazado, y a la primera parte que la transacción está incompleta.
25. 25. El método de la reivindicación 19, caracterizado porque, una o más firmas escritas a mano digitalizadas se incluyen en el objeto de información y se específica la colocación de las firmas escritas a mano digitalizadas en una estructura de datos mediante al menos una etiqueta de la firma .
26. 26. El método de la reivindicación 19, caracterizado porque, la colocación de una o mas bloques de firma en una 90 estructura de datos se especifica mediante al menos una etiqueta de la firma.
27. 27. El método de la reivindicación 26, caracterizado porque, uno o mas bloques de firma se transmiten por separado al TCU con las etiquetas de firma respectivas, y el TCU valida los bloques de firma: rechazando un bloque de firma ya sea si la firma digital respectiva no se verifica o el certificado de autenticación respectivo no está validado, y colocando el bloque de la firma de acuerdo a la etiqueta de firma respectiva si el bloque de firma no se ha rechazado, en donde, a los bloques de firma enviados por separado, el TCU agrega una indicación de fecha y hora a cada bloque de firma y anexa de acuerdo a las reglas de negocios el bloque de firma del TCU en un envoltorio que abraca el objeto de información y los bloques de firma colocados.
28. 28. El método de la reivindicación 27, caracterizado porque, el TCU verifica- una firma digital y valida un certificado de autentificación en un bloque de firma: determinando a partir de las reglas de negocios si una parte asociada con el certificado de autenticación tiene autoridad, verificando la firma digital de la parte, verificando que el periodo de validez del certificado de 91 autenticación cubre la fecha y hora actuales del TCU, verificar que la fecha y la hora caen dentro de una desviación permisible de la fecha y hora actuales del TCU, y recuperar el estado del certificado de autenticación desde el CSS, y si algunas de las etapas precedentes resulta en una salida inválida o falsa, la firma digital se considera inválida, la transacción no se ejecuta, por el contrario la firma digital se considera válida y la transacción se ejecuta.
29. 29. El método de la reivindicación 19, caracterizado porque, el CSS proporciona el estado del certificado de autenticación al TCU mediante el menos las etapas de verificar una memoria de caché local por el estado, y si se encuentra el estado en la memoria de caché local y la fecha y la hora locales están dentro del periodo de validez, y recuperar el estado desde la memoria de caché local, si el estado no se encuentra en la memoria de caché local o si la fecha y hora locales no están dentro del periodo de validez, el CSS establece una sesión de comunicación con un componente que reporta el estado del certificado de la CA emisora, crea una solicitud del estado del certificado de acuerdo al conector configurado, recupera el estado desde el componente que reporta el estado del certificado, cierra la sesión de comunicación con el componente que reporta el estado del 92 certificado, y agrega al menos la identificación, el estado, y un elemento de datos del tiempo de vida del certificado de autenticación, a la memoria de caché local.
30. 30. El método de la reivindicación 19, caracterizado porque, la primera parte es un primer TCU y la transacción es para transferir la custodia de uno o mas originales electrónicos al primer TCU desde un segundo TCU, un propietario de la transacción proporciona al segundo TCU con un manifiesto que identifica los originales electrónicos a ser transferidos al primer TCU, el segundo TCU establece la comunicación con el primer TCU e identifica el propósito de estas acciones, el manifiesto se comunica al primer TCU de modo que este es capaz de determinar cuando ha sido completada la transferencia de la custodia, el segundo TCU recupera el estado del certificado del segundo TCU y verifica la firma digital del segundo TCU en cada original electrónico transferido, si alguna de las firmas digitales o certificados del segundo TCU es invalido, entonces el primer TCU notifica al segundo TCU y busca un remedio, si el segundo TCU no proporciona un remedio, el primer TCU notifica al propietario de la transacción que la transferencia de la custodia solicitada ha fallado, por el contrario el segundo TCU crea un nuevo envoltorio para cada objeto de información transferido exitosamente, agrega un sello de fecha-hora y el bloque de 93 firma del primer TCU.
31. 31. El método de la reivindicación 30, caracterizado porque, la transacción es una transferencia de la propiedad en respuesta a una instrucción, la documentación de la transferencia de propiedad se coloca ya sea en la primera TCU o el segundo TCU, el TCU que tiene la documentación de transferencia de la propiedad valida la autenticidad de la documentación de la transferencia de propiedad verificando todas las firmas digitales, certifica los periodos de validez, y usa el · CSS para verificar el estado del certificado de los certificados de autenticación incluidos en la documentación de transferencia de la propiedad, anexa una indicación de fecha y hora, y firma digitalmente, envuelve, y almacena, la documentación de la transferencia de propiedad, la cual se agrega al manifiesto.
32. 32. El método de la reivindicación 19, caracterizado porque, el estado del certificado se indica al CSS mediante una lista de revocación de certificados ("CRL") de acuerdo al programa de publicación de la CA emisora, el CSS recupera la CRL desde un componente que reporta el estado del certificado listado en el almacén de configuración, el CSS limpia una memoria caché asociada con la CA emisora y el CSS determina el estado del certificado de autenticación desde la CRL, y almacena el estado en la memoria caché asociada con la CA 94 emisora .
33. 33. El método de la reivindicación 19, caracterizado porque, el estado del certificado se indica al CSS mediante una lista de revocación de certificados ("CRL"); tras la notificación por la CA emisora que una CRL se encuentra disponible, el CSS recupera la CRL desde un componente que reporta el estado del certificado listado en el almacén de configuración; si la CRL es una CRL completa, entonces el CSS limpia una memoria caché asociada con la CA emisora, determina el estado a partir de la CRL, y almacena el estado en la memoria caché, y si la CRL contiene solo los cambios que ocurren después de la publicación de una CRL completa, el CSS determina el estado a partir de la CRL, y almacena el estado en la memoria caché. 95 RESUMEN DE LA INVENCIÓN Se describe el Servicio de Estado de Certificado que es configurable, dirigido y capaz de recuperar el estado de cualquier Autoridad de Certificación (CA) aprobada. El CSS S"e puede usar por un Servicio de Custodia de Confianza (TCü) y sistemas comparables o aplicaciones cuyos papeles son la validación del derecho de un individuo para realizar una acción de requisito, la autenticidad de los objetos de información electrónica presentados y el estado de los certificados de autenticación- usados en los procesos de la verificación de la firma digital y la autenticación del usuario. La verificación de validez sobre los certificados de autenticación se realiza interrogando a una CA que expide. Tradicionalmente, para crear una Infraestructura de Clave Pública (PKI) necesaria para validar los certificados, se forman relaciones complejas mediante una certificación cruzada entre las CAs o mediante el uso de puentes PKI . El problema de interoperabilidad de la PKI y la CA se consigna desde un punto de vista diferente, con un enfoque en el establecimiento de un ambiente de confianza adecuado para la creación, ejecución, mantenimiento, transferencia, recuperación, y destrucción de los objetos de información originales, electrónicos, que también pueden ser registros transferibles (la propiedad puede cambiar de manos) . Un TCU está ocupado solo con un conjunto 96 conocido de "CAs aprobadas" aunque puede soportar una multitud de ambientes de negocios, y dentro de ese grupo de CAs, solo con aquellos certificados que están asociados con las cuentas del usuario de TCU. No se requiere la construcción de relaciones de confianza PKI/CA pues el CSS logra un ambiente de confianza o seguridad interrogando solo a las CAs aprobadas y manteniendo las memorias asociadas de estados de certificados válidos.