Certificate List “A Ser Assinado”

O campo certificate list a ser assinado, ou TBSCertList, ´e uma sequˆencia de campos obri- gat´orios e opcionais. Os campos obrigat´orios identificam o emissor da LCR, o algoritmo

Ern

an

des

utilizado para assinar a LCR, e a data e o tempo da emiss˜ao da LCR.

Campos adicionais incluem a data e o tempo no qual o emissor da CLR emitir´a a pr´oxima LCR, a lista de certificados revogados, e extens˜oes da LCR. A lista de certificados revogados ´e opcional, para suportar o caso no qual a AC n˜ao possui nenhum certificado, por ela emitido, revogado dentro do per´ıodo de validade. Este perfil requer que os emissores de LCR em conformidade incluam o campo nextUpdate e o n´umero da LCR, e a extens˜ao authority key identifier em todas as LCRs emitidas.

5.1.2.1 Version

Este campo opcional descreve a vers˜ao da LCR codificada. Quando as extens˜oes forem usa- das, como obrigat´orio para este perfil, este campo DEVE estar presente e DEVE especificar a vers˜ao 2 (o valor inteiro utilizado ´e 1).

5.1.2.2 Signature

Este campo cont´em o identificador do algoritmo para o algoritmo utilizado para assinar a LCR. [RFC3279], [RFC4055], e [RFC4491] lista os OIDs para os algoritmos de assinatura mais comuns usados na ICP Internet.

Este campo DEVE conter o mesmo identificador de algoritmo que o campo signatureAlgo- rithm na sequˆencia CertificateList (se¸c˜ao 5.1.1.2).

5.1.2.3 Issuer Name

O campo issuer name identifica a entidade que assinou e emitiu a LCR. A identidade do emissor ´e informada no campo issuer. Formas alternativas de nome tamb´em podem aparecer na extens˜ao issuerAltName (se¸c˜ao 5.2.2). O campo issuer DEVE conter um nome distinto (DN) X.500 n˜ao vazio. O campo issuer ´e definido como um tipo Name do X.501, e DEVE seguir as regras de codifica¸c˜ao para o campo issuer name do certificado (se¸c˜ao 4.1.2.4).

5.1.2.4 This Update

Este campo indica a data de emiss˜ao da LCR. thisUpdate pode ser codificado como UTC- Time ou GeneralizedTime.

Emissores de LCR em conformidade com este perfil DEVEM codificar thisUpdate como UTCTime para datas at´e o ano 2049. Emissores de LCR em conformidade com este perfil DEVEM codificar thisUpdate como GeneralizedTime para datas no ano 2050 para frente. Aplica¸c˜oes em conformidade DEVEM ser capazes de processar datas que estejam codifica- das tanto em UTCTime como em GeneralizedTime.

Quando codificada como UTCTime, thisUpdate DEVE ser especificada e interpretada como definido na se¸c˜ao 4.1.2.5.1. Quando codificadas como GenerelizedTime, thisUpdate DEVE ser especificada e interpretada como definido na se¸c˜ao 4.1.2.5.2.

Ern

an

des

Este campo indica a data na qual a pr´oxima LCR ser´a emitida. A pr´oxima LCR pode ser emitida antes da data indicada. Emissores de LCR DEVERIAM emitir LCRs com o tempo nextUpdate iqual ou maior que todas as LCRs enteriores. nextUpdate pode ser codificado como UTCTime ou GeneralizedTime.

Os emissores de LCR em conformidade DEVEM incluir o campo nextUpdate em todas as LCRs. Note que a sintaxe ASN.1 de TBSCertList descreve este campo como opcional, que esta consistente com a estrutura ASN.1 definida em [X.509]. O comportamento de cli- entes que processam LCRs que omitem o campo nextUpdate n˜ao ´e especificado neste perfil. Emissores de LCR em conformidade com este perfil DEVEM codificar nextUpdate como UTCTime para datas at´e o ano de 2049. Emissores de LCR em conformidade com este perfil DEVEM codificar nextUpdate como GeneralizedTime para datas no ano 2050 e pos- teriores. Aplica¸c˜oes em conformidade DEVEM ser capazes de processar datas que estejam codificadas tanto em UTCTime quanto em GeneralizedTime.

Quando codificadas como UTCTime, nextUpdate DEVE ser especificado e interpretado como definido na se¸c˜ao 4.1.2.5.1. Quando codificada como GeneralizedTime, nextUpdate DEVE ser especificado e interpretado como definido na se¸c˜ao 4.1.2.5.2.

5.1.2.6 Revoked Certificates

Quando n˜ao existirem certificados revogados, a lista de certificados revogados DEVE estar ausente. De outra forma, os certificados revogados s˜ao listados pelos seus n´umeros seriais. Certificados revogados pela AC s˜ao identificados unicamente pelo n´umero serial do certi- ficado. A data na qual a revoga¸c˜ao ocorreu ´e especificada. O tempo para revocationDate DEVE ser expresso conforme descrito na se¸c˜ao 5.1.2.4. Informa¸c˜ao adicional pode ser for- necida nas extens˜oes das entradas da LCR; extens˜oes de entrada da LCR ser˜ao discutidas na se¸c˜ao 5.3.

5.1.2.7 Extens˜oes

Este campo apenas ocorre se a vers˜ao for 2 (se¸c˜ao 5.1.2.1). Se presente, este campo ´e uma sequˆencia de um ou mais extens˜oes de LCR. As extens˜oes de LCR s˜ao ser˜ao discutidas na se¸c˜ao 5.2.

5.2

Extens˜oes da LCR

As extens˜oes para LCRs X.509 v2 definidas nos padr˜oes ANSI X.9, ISO/IEC e ITU-T [X.509] [X9.55] fornecem m´etodos para associa¸c˜ao de atributos adicionais `as LCRs. O for- mato X.509 para LCR tamb´em permite que comunidades definam extens˜oes privadas para transferir informa¸c˜oes particulares `aquelas comunidades. Cada extens˜ao da LCR pode ser designada como cr´ıtica ou n˜ao-cr´ıtica. Se um LCR tiver uma extens˜ao cr´ıtica que a apli- ca¸c˜ao n˜ao possa processar, ent˜ao a aplica¸c˜ao N ˜AO DEVE usar a LCR para determinar o estado de revoga¸c˜ao dos certificados. Entretanto, as aplica¸c˜oes podem ignorar as extens˜oes n˜ao-cr´ıticas. As subse¸c˜oes seguintes apresentam aquelas extens˜oes usadas com LCRs Inter- net. As comunidades podem decidir incluir extens˜oes na LCR que n˜ao est˜ao definidas nesta especifica¸c˜ao. No entanto, devem ter cuidado na ado¸c˜ao de quaisquer extens˜oes cr´ıtica nas LCRs que podem ser utilizadas em contexto geral.

Ern

an

des

Os emissores de LCR em conformidade NECESSITAM incluir a extens˜oes authority Key Identifier (se¸c˜ao 5.2.1) e CRL number (se¸c˜ao 5.2.3) em todas as LCRs emitidas.

5.2.1 Authority Key Identifier

A extens˜ao authority key identifier fornece um meio para identificar a chave p´ublica corres- pondente a chave privada usada para assinar a LCR. A identifica¸c˜ao pode ser baseada tanto no identificador da chave (campo subject key identifier do certificado usado para assinar a LCR) ou no campo issuer name e serial number. Esta extens˜ao ´e especialmente ´util quando um emissor tem mais de uma chave para assinatura, por quest˜oes de m´ultiplos pares de chaves concorrentes ou devido a troca de chave.

Emissores de LCR em conformidade DEVEM usar o m´etodo key identifier, e DEVEM in- cluir esta extens˜ao em todas as LCRs emitidas.

A sintaxe para esta extens˜ao da LCR ´e definida na se¸c˜ao 4.2.1.1.

5.2.2 Issuer Alternative Name

A extens˜ao issuer alternative name permite que identidades adicionais sejam associadas ao emissor da LCR. Op¸c˜oes definidas incluem endere¸co de e-mail (ref822Name), nome DNS, endere¸co IP, e URI. M´ultiplas instˆancias de uma forma de nome e m´ultiplas formas de nome podem ser inclu´ıdas. Sempre que tais identidades forem utilizadas, a extens˜ao issuer alternative name DEVE ser utilizada; no entanto, um nome DNS PODE ser representado no campo issuer usando o atributo domainComponent conforme descrito na se¸c˜ao 4.1.2.4. Emissores de LCR em conformidade DEVERIAM marcar a extens˜ao issuerAltName como n˜ao-cr´ıtica.

O OID e a sintaxe para este extens˜ao de LCR est˜ao definidos na se¸c˜ao 4.2.1.7.