O design geral da aplicação foi orientado explicitamente no sentido de assegurar a extensibilidade dos seus diversos componentes, em primeiro lugar para assegurar suporte a outras infra-estruturas de chaves públicas que não somente a ICP-Brasil, mas também para assegurar a possibilidade de diferentes implementações de suas características estruturais, como o envelopamento também por XMLDSig, outro tipo de gerenciamento de LCR's, etc.
A idéia aqui é implementar uma aplicação que suporte diferentes políticas de certificados e de assinatura. Cada conjunto coerente de políticas constituem uma PKI e o objetivo é suportar inicialmente duas: uma genérica, com políticas de assinatura CAdES-BES e CAdES-T, e a segunda inteiramente conforme à ICP-Brasil. Isso sem excluir que outras PKI's possam ser igualmente suportadas, por conveniência dos usuários e desenvolvedores da aplicação. Dentro da aplicação, cada conjunto coerente de políticas, isto é, cada PKI é implementada num módulo baseado em três dispositivos simples:
O suporte a uma PKI requer a especialização do dispositivo de validação, através da implementação da interface org.crypthing.things.validator.Rule para cada regra de validação, que deve também especializar java.lang.Throwable; do registro de cada conjunto de regras em org.crypthing.things.validator.ValidationRules e da especialização de org.crypthing.things.validator.RulesProcessor para cada processo de validação.
Além disso, é necessário especializar o dispositivo de parsing de certificados, o que é feito, em primeiro lugar, pela especialização de org.crypthing.things.cert.Policy para representar a política de certificados da PKI; pela especialização de org.crypthing.things.cert.CertificatePurpose para representar as características do certificado; pela especialização de org.crypthing.things.cert.SubjectAttributes, responsável por efetuar o parsing apropriado de SubjectAlternativeNames, para representar os atributos típicos do usuário e, finalmente, pela especialização de org.crypthing.things.cert.CertificateParser para efetuar o parsing do certificado.
O dispositivo de políticas de assinatura deve também ser especializado. Em primeiro lugar, é necessário implementar as regras de validação do envelope criptográfico em conformidade com a política (ver dispositivo de validação), especializando org.crypthing.signthings.policies.SignaturePolicyRule. Em segundo lugar, é necessário especializar org.crypthing.signthings.policies.PolicyProcessor para implementar tanto a validação quanto a lógica de construção do envelope criptográfico.
Como dissemos, outras características relevantes da aplicação são também extensíveis. O projeto prevê suporte não apenas a envelopes criptográficos baseados no padrão CMS, mas também no padrão XMLDSig para transporte de documentos assinados. Para isso, projetamos um dispositivo de parsing para o envelope de transporte que, para ser extendido, requer a especialização de org.crypthing.signthings.envelope.AbstractParser de modo a construir a lógica de parsing e a implementação da interface org.crypthing.signthings.envelope.ParsingHelper para efetuar o parsing dos vários componentes de uma assinatura. O projeto desse dispositivo é muito simples e baseia-se na premissa da rigorosa equivalência funcional entre as várias especificações, particularmente CMS e XMLDSig, pelo menos no que concerne à assinatura digital.
O gerenciamento das informações sobre a revogação dos certificados digitais mereceu também um módulo próprio. A essa altura do projeto, a arquitetura suporta informações de revogação somente através de LCR's. É muito provável que o futuro suporte a OCSP (Online Certificate Status Protocol) requeira a revisão dessa arquitetura. Porém, a versão corrente do dispositivo de gerenciamento de LCRs permite dois tipos de extensão: o meio de armazenamento físico das LCR's pode ser extendido, através da especialização da classe org.crypthing.signthings.crl.DatabaseLoader, responsável por obter as LCRs da camada de persistência, e da implementação das interfaces org.crypthing.signthings.crl.CRLDbEventListener e org.crypthing.signthings.crl.CRLEventListener, para armazenar as atualizações na camada de persistência. Por outro lado, o tipo de conexão à Internet, para obtenção das LCR's, pode ser extendido pela especialização de org.crypthing.signthings.crl.CRLHttpGetter. É exatamente aqui que um eventual suporte a OCSP deverá alterar significativamente.
Por fim, diferentes meios de armazenamento de chaves criptográficas são diretamente suportados pela aplicação com um mínimo de esforço, através de um dispositivo que requer simplesmente a especialização de org.crypthing.signthings.crypto.CrypToken para suportar novos java.secutiry.KeyStore.