Store Public Keys in tiles coordinate-matched to Entry tiles.

[ezekiel]

This changes the MTCA to include the public key in the pendingEntries submitted for sequencing. Upon sequencing, the subjectPublicKeyInfo structure is bundled just like Entries are bundled, and stored in tiles with the same coordinates as the Entry tiles, but at a different layer (-2).

For writing the public key tiles, we introduce Bundling and Marshaling functions specific to a new MTCPublicKey structure which wraps subjectPublicKeyInfo and facilitates null pubkey placeholders in the tile information tracked in the Frontier.

Fixes #8913

[jsha]

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

Suggested change

	const typeMTCPubkey = 1
	const typeSPKI = 1

[jsha]

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.

[jsha]

Suggested change

	// Pubkey returns the subjectPublicKeyInfo structure bytes of an MTCPublicKey if
	// type is typeMTCPubkey, or nil
	// Pubkey returns the subjectPublicKeyInfo structure bytes of an MTCPublicKey if
	// its type is typeMTCPubkey, otherwise nil.

[jsha]

Suggested change

	// pkBytes is a crypto.x509 SubjectPublicKeyInfo structure
	// pkBytes is an RFC 5280 SubjectPublicKeyInfo structure

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

[jsha]

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.

[jsha]

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

[jsha]

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.

[ezekiel]

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

[jsha]

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.

[aarongable]

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.

[jsha]

Suggested change

	// Entry Tile is full. Queue it for writing.
	// Entry tile is full. Queue it for writing.

[jsha]

Suggested change

	// Pubkey Tile is full. Queue it for writing.
	// Pubkey tile is full. Queue it for writing.

[jsha]

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