Nit: the outer type is MTCPublicKey. The inner type represented by this constant is SubjectPublicKeyInfo.

Needs a doccomment. I notice below that "Marshal returns the encoding of its receiver." That's also what MTCLogEntry.Marshal says; but type MTCLogEntry defines what its encoding is (by reference to the spec). Since MTCPublicKey is our own local data type we should define its encoding. Ideally in the type MTCPublicKey doccomment. Also this doccomment should mention briefly that this is a local data type, not defined in the MTC spec.

(there's no type SubjectPublicKeyInfo in crypto/x509).

Here you use nil (Go idiom); elsewhere you use null (matching how MTC names its null_entry). Let's do this: for the encoded data, let's follow MTC practice and call this typeNullPubkey. Let's reserve nil for when we are talking about a Go value that holds nil. I think that just means renaming this const; in the rest of the code you already use null.

We should define "pubkey bundle format" somewhere. Maybe in a package doccomment?

We should avoid global vars when possible, even in tests. They can create hard-to-debug interactions between test cases, and can prevent setting test cases to t.Parallel(). I know there are some examples to the contrary in the code base, particularly in the RA tests.

I think we can improve things in these tests by having testPubkeySingleton simply generate the key from scratch each time. Same for the other ...Singleton functions. And in the process we should rename them to remove Singleton from the name.

Generating the key each time slows down tests quite a lot because tile_test has some tests that write 65k tiles.

Ah, that makes sense. Three possible solutions:

• Generate a key once per test case, and pass it down into the helper functions.
• Continue to use one global test key, but initialize it in init() and subsequently only read it (avoiding race conditions). In this case I'd also want to document that the tests don't rely on key equality.
• In the helpers, put in a syntactically valid but not "real" key.

I think I prefer the last one. tiles_test isn't testing marshaling/unmarshaling of type MTCPublicKey, so it doesn't need to exercise that code with a real key. You actually did this in tiles_test.go line 580:

		err := f.AppendEntry(&entry.MTCLogEntry{}, &pubkey.MTCPublicKey{})

I suspect the other tests needed a more realistic key because of the ParsePKIXPublicKey() call that I suggested removing.

Note that &pubkey.MTCPublicKey{} isn't actually an invalid entry / fake key: it's the null entry used at index 0. To exercise the "load some bytes" code path, it would need to be something more like &pubkey.MTCPublicKey{typ: typeMTCPubkey, pub: []byte("hello world")}. Otherwise I totally agree: all of the real keys in these tests were necessary when this code was calling x509.ParsePKIXPublicKey on every one of them, but we've simplified that out now.

Here's another place where we should generate key within each test case (possibly by calling a helper function) rather than having a singleton.