CT package should use zcrypto/x509

[dadrian]

The CT package currently contains it's own fork of crypto/x509 and crypto/asn1. It's not entirely clear why these are needed. At the very least, we should make sure whatever changes in the ct/x509 module are in zcrypto/x509, and try to remove that dependency. However, this will create a circular dependency between zcrypto/x509 and zcrypto/ct. So we'll then have to figure how what the ct module needs any form of x509 anyway, and possible extract that to a separate package.

Another possible solution might be to make it ct subpackage of zcrypto/x509.

[dadrian]

I took a crack at this the other day. This is non-trivial. The zcrypto/ct code from Google is poorly organized, and tightly coupled to it's use of zcrypto/ct/x509, and there's not a clear division between what goes in a CT log, and what CT info goes in a certificate. I started splitting it up by moving all SCT-related code into our x509 library, so that we could get rid of the CT x509 library. This is also annoying because of the massive serialization.go, which defines a bunch of interrelated serialization functions that make it difficult to cut the package down the middle.

So in summary:

• It's entirely possible to remove zcrypto/ct/x509
• There will have to be some split between zcrypto/ct and zcrypto/x509/ct in order to avoid circular dependencies.
• Splitting zcrypto/ct in two is non-trivial.
• Whoever works on this will have to spend a decent amount of time getting familiar with the implementation of zcrypto/ct in order to do this cleanly. My first attempt to do this was largely copy-paste based, and got complicated fast. It needs a bit more methodology to do cleanly than copy paste, change names, fix compile errors. Some functions will need to be split, changed, defined on different objects, etc.

[zakird]

I'm not sure this is worth it. We need to just scrap our entire CT client implementation and write a fresh one. As part of this, we should probably just write a clean client. We need to introduce new, fundamental pieces of functionality (e.g., verifying log entries), their threading model doesn't make a lot of sense, and so I'm a bit doubtful we'd want to use the existing Google one anyway.