Tabla de contenido
Publicidad
certificates). Para los certificados CA la extensión keyUsage DEBE marcarse como crítica con un
valor de keyCertSign y cRLSign. Para los certificados CVC la extensión keyUsage DEBE marcarse
como crítica con un valor de digitalSignature y keyEncipherment. Los certificados de la entidad
final pueden utilizar la extensión keyUsage como se especifica en RFC 3280.
11.3.2.1.3.4
basicConstraints
La extensión basicConstraints DEBE utilizarse para todos los certificados CA y CVC y DEBE
marcarse como crítica. Los valores para cada certificado correspondientes a basicConstraints
DEBEN marcarse de acuerdo con lo especificado en los cuadros de descripción de certificados 11-2
a 11-13.
11.3.2.1.4 Algoritmo de firma
El mecanismo de firma utilizado DEBE ser SHA-1 [FIPS 186-2] con criptación RSA. El OID
específico es 1.2.840.113549.1.1.5.
11.3.2.1.5 SubjectName e IssuerName
Si una cadena no pudiera codificarse como PrintableString DEBE codificarse como UTF8String
(etiqueta [UNIVERSAL 12]).
Al codificar un nombre X.500:
•
Cada RelativeDistinguishedName (RDN) DEBE contener un único elemento del conjunto
de atributos X.500.
•
El orden de los RDN en un nombre X.500 DEBE ser idéntico al orden de presentación en
esta Recomendación.
11.3.2.1.6 serialNumber
El número de serie DEBE ser un entero positivo y único que asigna la CA a cada certificado (es
decir, el nombre del expedidor y el número de serie identifican un certificado único). Las CA
DEBEN exigir que el serialNumber sea un entero no negativo. El fabricante NO DEBERÍA
imponer o suponer una relación entre el número de serie del certificado y el número de serie del
módem al que se expide el certificado.
Dada la singularidad de los requisitos antes señalados, se prevé que los números de serie incluirán
números enteros grandes. Los usuarios de los certificados DEBEN tener la capacidad para manejar
valores de serialNumber de hasta 20 octetos. Los CA conformes NO DEBEN utilizar valores de
serialNumber más largos que 20 octetos.
11.3.2.2 Jerarquías de los certificados de IPCable2Home
Se utilizan tres jerarquías distintas de certificados. La cadena del fabricante se utiliza para
identificar a los fabricantes autorizados; la cadena de verificación de códigos se utiliza para
identificar imágenes de soporte lógico homologado y la cadena de proveedor de servicios se utiliza
para identificar los dispositivos de la red del proveedor de servicios destinados a la autenticación
recíproca en los dispositivos de los abonados.
Las jerarquías de certificados que se describen en esta Recomendación podrán aplicarse a todos los
proyectos de la UIT que necesiten certificados. Cada proyecto puede adoptar esta jerarquía ya que
es posible pasar a una estructura de certificados compartidos más genérica. Además, cada proyecto
puede tener necesidad de realizar ajustes particulares de los requisitos de ese proyecto específico. El
objetivo será crear una PKI que pueda reutilizarse en cada proyecto. Puede haber diferencia en los
certificados de entidad final requeridos en cada proyecto, pero en los casos en los que los
certificados de entidad final se solapan, un certificado de entidad final podría utilizarse para
diversos servicios en la infraestructura de cable. Por ejemplo, IPCablecom requiere un KDC para el
proveedor de servicios e IPCable2Home también lo necesita. Si el proveedor de servicios tiene
124
Rec. UIT-T J.191 (03/2004)
Publicidad
Tabla de contenido
