¿Qué políticas de emisión de OID son adecuadas para las tarjetas inteligentes y los certificados de navegador?

7

Estoy investigando políticas de emisión para SMIME y certificados de navegador con diferentes niveles de seguridad.

A los fines de los certificados S / MIME y Browser, ¿debo usar una política de aseguramiento?

¿Debería aplicarse la política de aseguramiento en el certificado de entidad final o en la CA? ... ambas?

¿Cómo debo generar mis OID?

Finalmente, asumo que no debería marcar la garantía como crítica, especialmente si uso un OID personalizado.

    
pregunta random65537 04.01.2013 - 22:27
fuente

1 respuesta

6

Lo que Microsoft llama "políticas de emisión" o "garantía" se conocen como Políticas de certificado en X.509 (ver sección 4.2.1.4). Una política de certificado se define como tal:

  

En un certificado de entidad final, estos términos de información de política indican      La política bajo la cual se ha emitido el certificado y la      Fines para los que puede utilizarse el certificado. En un certificado de CA,      estos términos de información de política limitan el conjunto de políticas para      Rutas de certificación que incluyen este certificado.

La idea completa de un OID es identificar un "objeto" de forma única y sin ambigüedades (lo que realmente puede ser cualquier cosa, incluyendo conceptos abstractos) en una jerarquía mundial de nombres. Como tal, el OID generado aleatoriamente anula totalmente el propósito y no puede ser aprobado. En el caso de las políticas de certificado, el OID debe "apuntar" a una política específica, es decir, un documento que define las condiciones bajo las cuales se emitió el certificado y para qué se puede usar. Debe obtener un subárbol OID: cualquier organización puede obtener su propio subárbol de la IANA (es gratis y permanente). Luego, asigna el OID en ese subárbol de la forma que crea conveniente.

Dicho esto, las políticas de certificados tienen sentido como parte del proceso de validación de certificados descrito en sección 6 de RFC 5280 (ver en particular el paso (a) de 6.1.2, (d), (e) y (f) de 6.1.3, y el paso (g) de 6.1.5). El proceso de validación calcula el conjunto de políticas de certificado que son válidas para toda la ruta , es decir, que aparecen en cada certificado en la ruta. Hay varias sutilezas, en particular con respecto al comodín especial anyPolicy (que es 2.5.29.32.0, que Microsoft llama "Todos los números") y las asignaciones de políticas. Sin embargo, si uno de los certificados de CA en la ruta no tiene ninguna extensión Certificate Policies , entonces el vallid_policy_tree será NULL , es decir, todo se vuelve en nada. La ruta del certificado será validada "genéricamente" pero no saldrá ninguna política específicamente identificada.

La triste verdad es que muchos CA usan certificados de la manera en que Microsoft lo promueve, es decir, completamente equivocado con respecto a lo que se suponía que debían hacer; en su lugar, utilizan las políticas de certificado como un tipo de comentario elegante que el software ignorará constantemente (las políticas se pueden adjuntar a calificadores , que puede ser texto simple o una URL que apunta a algo que puede o no ser legible documento).

Debido a que las políticas de certificados se usan de manera tan indebida, no es útil hacer que la extensión sea crítica. En la práctica, agrega la extensión con una URL que apunta a una Declaración de práctica de certificación como un archivo PDF, que en Al menos demuestra que eres serio con respecto a tu negocio de CA, hasta el punto de que estás dispuesto a complacer a algunos de ellos. Consulte RFC 3647 para obtener orientación sobre cómo escribir un CPS.

    
respondido por el Thomas Pornin 05.01.2013 - 00:06
fuente