Boa noite povo!
No último versículo: parte 4 da tradução de “The Ricardian Contract“
Hoje: parte 5.
A PKI Ricardiana entrega clareza. Contratos Ricardianos carregam sua própria Infraestrutura de Chave Pública (“PKI”) [na sigla em inglês] em sí. A chave pública de nível superior do Emitente está incluída no contrato, e este assina a sua chave de assinatura do contrato, também incluída. A chave de assinatura do contrato assina o próprio contrato.
Isso realiza várias coisas. Em primeiro lugar, o software cliente pode verificar toda a cadeia de assinatura digital em uma sequência automática.
Em segundo lugar, não há necessidade de uma complexa PKI multipartidária. Todas as chaves estão presentes e não há necessidade de procurá-las na rede. Isso elimina ataques de substituição, por meio dos quais uma chave que pode passar em algumas verificações pode ser inserida em alguma fase de pesquisa de chave. Também reduz os custos drasticamente.
Em terceiro lugar, o hash canônico do contrato também representa uma assinatura no contrato. É gravado em todos os registros relevantes e, portanto, emaranha o contrato com essas atividades [13]. Uma vez que o contrato esteja em vigor há algum tempo, ele estabelece sua procedência por meio da presença e confiança do público usuário. Isso fornece evidências muito mais persuasivas do que a própria assinatura do emissor; uma vez que o emissor e o público tenham gasto tempo e dinheiro contando com o contrato, por meio do hash, é difícil para o emissor renegar a natureza do contrato ou de sua assinatura.
O resultado é uma PKI que oferece alta confiabilidade de ponta a ponta, com base em um único documento. Isso simplesmente não está presente em outros designs de PKIs [14]. Essa confiabilidade compensa na fase de resolução de disputas, onde, sugerimos, o Contrato Ricardiano pode ser independente em seus méritos e não exige descrições complexas de PKI, assinaturas digitais ou referências a terceiros incertos para reforçar sua procedência. Ao incluir as chaves, podemos traçar algumas linhas simples dentro do contrato, afirmando “esta chave assina aquela chave e a última assina o contrato. A primeira chave é a chave de nível superior do indivíduo que assinou este contrato. Essa é a história toda, meu senhor”
Validando a Chave do Emissor. Todos os bons protocolos de criptografia dividem-se em duas partes, a primeira das quais diz para a segunda, “confie nesta chave completamente.”
A chave de nível superior do Emissor, em última análise, autentica o contrato. As chaves e outras informações no contrato também permitem que um protocolo como o SOX inicialize uma conexão fortemente segura com o servidor [15].
Como então verificar se essa chave definitiva é realmente do Emissor? Isso não é difícil. O processo de negócios de emissão digital envolve uma grande construção de relacionamento entre Emissores e Usuários. Muitas interações diferentes envolvem chances de estabelecer confiança. Por exemplo, em seu site, o Emissor pode publicar o contrato, as chaves e os hashes e fazer com que outros sites os espelhem. O valor assim emitido será distribuído por meio de pagamentos que incluem o hash. Uma parte já confiável geralmente entrega esses pagamentos. Os pagamentos identificam o contrato de forma válida e derivam sua própria validade por meio do hash.
Compare isso com as suposições no x.509 PKI por trás da navegação SSL / HTTPS (o seguinte é altamente discutível, mas é apresentado apenas para comparação). Nessa PKI, foi originalmente alegado que um usuário apresentaria seu cartão de crédito a sites com os quais ela não tinha nenhum relacionamento anterior e nenhuma maneira de estabelecer a proveniência da chave do site. Assim, um terceiro confiável, a Autoridade de Certificação, foi criado para confirmar a chave.
Pagamentos, negociações e questões financeiras são fundamentalmente ricos em relacionamentos. A natureza do dinheiro e das finanças é que os participantes sempre realizam sua própria diligência, preferem ouvir colegas em quem já confiam e não aceitam prontamente a palavra de uma parte independente. Portanto, não há lugar para uma terceira parte central intervir e autenticar os participantes. Antes que o usuário deseje atribuir algum valor a um determinado pagamento, é quase certo que ele tenha sido informado do contrato por outros meios.
[14] Jane K. Winn, “Couriers without Luggage” 49 South Carolina Law Review 739 (1998)
[15] Gary Howland, “Development of an Open and Flexible Payment System” 1996.
Vista a quinta parte, no versículo seguinte a penúltima. Ricas bençãos amigos!
