Este caso de uso descreve a verificação da conformidade do certificado digital do Operador com a RFC 5280 e com a regulamentação da ICP-Brasil. O certificado verificado pode tanto ser o próprio certificado do Operador quanto de um assinante, contido num envelope de transporte.
Operador
O operador seleciona o certificado a ser verificado. | O sistema obtém a cadeia completa de certificados. |
O Operador seleciona a verificação de conformidade à RFC 5280. | O sistema verifica a integridade do certificado segundo R1. |
O Operador seleciona a verificação de conformidade à ICP-Brasil. | O sistema verifica a integridade do certificado segundo R2. |
A verificação de conformidade foi realizada. | O sistema fornece feedback completo ao Operador. |
A cadeia completa de certificados não está disponível. | O sistema solicita o fornecimento dos certificados da cadeia. |
O Operador fornece um certificado da cadeia. | O sistema armazena o certificado num repositório de emissores confiáveis. |
O Operador cancela a inclusão de certificados da cadeia. | O sistema alerta o operador que a confiabilidade do certificado não poderá ser verificada e retorna ao fluxo principal. |
O certificado deve obedecer à sintaxe definida na RFC 5280.
Um caminho de certificação consiste de uma seqüência de "n" certificados digitais {1, ...., n}, sendo que o primeiro certificado corresponde ao da entidade considerada como "âncora de confiança", ou seja, a AC Raiz. O n-ésimo certificado corresponde ao certificado que deve ser validado, neste caso, o de entidade final. O processo de validação do caminho de certificação de um certificado digital deve satisfazer à seguinte condição: para todo certificado digital "x" no intervalo {1, ...., n-1}, o proprietário do certificado digital "x" deve ser o emissor do certificado digital "x+1", isto é:
O instante de uso currentTime deve obedecer à restrição: notBefore > currentTime < notAfter. O instante corrente pode tanto ser obtido do sistema operacional, no caso da realização de uma ssinatura, quanto ser obtido do atributo SigningTime ou do Time-Stamp Token fornecido pela TSA e incluso num envelope de transporte, no caso da verificação de assinatura.
Se presente, a extensão deve conter somente os bits digitalSignature, nonRepudiation e keyEncipherment ativados em certificados de assinatura digital. Por outro lado, em certificados de sigilo, somente os bits keyEncipherment e dataEncipherment podem estar ativos. Em certificados de AC, os bits keyCertSign e cRLSign devem estar ativos.
Se presente, em certificados de TSA, o identificador id-kp-timeStamping deve estar presente.
Se presente, a extensão deve conter a URL onde está publicada a CRL correspondente.
A conformidade à ICP-Brasil requer a conformidade à RFC 5280.
Se presente, a extensão deve conter o hash SHA-1 da chave pública do emitente.
Se presente, a extensão deve conter a URL da DPC da AC que emitiu o certificado digital e o OID da PC correspondente, a saber:
Um relatório completo sobre o resultado da validação deve estar disponível.