I'm thinking about writing an X.509 certificate verification contract (which henceforth I'll call CVC) in Solidity. The idea is that given a certificate (for the sake of example, let's suppose the raw DER-encoded bytes of the cert) passed to some contract A, the contract A can call CVC with the certificate as input, and CVC will return whether or not the bytes represent an X.509 certificate with a valid signature.

In order to do this, CVC will likely need to do the following:

  • Parse the certificate to determine the TBSCertificate field and signature algorithm
  • Call code to hash the TBSCertificate field according to the correct algorithm (could be included in the code of the next step)
  • Call code to verify the TBSCertificate according to the correct signature algorithm

It may also be useful to write a general contract to parse an X.509 certificate to extract relevant fields. This can then be used to create, for example, a decentralized escrow service for purchasing certificates from a CA (a site pays funds into contract A, the CA sends the signed certificate to contract A, and contract A ensures using CVC that the certificate is valid and contains the correct public key of the site before releasing the funds to the CA).

Since I've done almost no programming in Solidity thus far, I'd like to get some opinions on whether or not this design makes sense. In particular it seems like it'd be quite expensive to do all of this processing in the EVM. If possible, I'd like to avoid relying on an external service to do this verification, but that would depend on the difference in price (i.e. if it's way more expensive to verify a cert using a contract, it may be worth giving up decentralized certificate verification).

Thanks in advance for your help.

  • This question would better fit /r/ethereum in Reddit. – Nicolas Massart Jul 7 '16 at 20:20
  • Join discussion here and see related. – eth Jul 7 '16 at 20:48

Validating signed data against arbitrary CA-issued certificates is currently not practical in Ethereum, at least on the public chain. This specific issue I'm aware of is that RSA verification would require too much gas for any reasonable key length. There are proposals to fix this either by adding specific verification opcodes or, more likely, by adding BigNumber support. This may be included in a future hard fork.

I'm not sure if it's still possible to work with a subset of X.509 certificates - it may be, as the standard seems to have a lot of options for different algorithms, so maybe you can cobble together something you can verify. But I guess if you were creating the signature with Ethereum in mind you wouldn't bother using X.509 in the first place.

  • Okay, so signature verification would be impractical in the current version of Ethereum. What about generally parsing the certificate into its components? Would ASN.1 parsing be feasible in the current Ethereum? – Stipe Matic Jul 8 '16 at 12:54
  • In principle I don't see any reason why you wouldn't be able to parse it in a contract, although I can't think what the use-case would be where you'd want to do that if you can't actually validate it. – Edmund Edgar Jul 8 '16 at 13:00

Not the answer you're looking for? Browse other questions tagged or ask your own question.