sa: add schema for MTC operations#8764
Conversation
New tables `checkpoints`, `checkpointSubtrees`, `landmarks`, and some new fields on `orders`. We have a new concept `mtcaID` that is the MTC equivalent of `issuerID` in our pre-existing infrastructure. This is a string-valued field that contains an ASCII-formatted relative OID, to match how CAs are identified in MTC. We also have the corresponding `mirrorID` which contains a relative OID identifying a mirror. Note that we use the more specific term `mirror` rather than `cosigner`, because we expect that root programs will require full mirrors. And since the term "cosigner" in MTC can also refer to a "CA cosigner," we can be clearer by being more specific. Also note that mirror signatures are included as fields rather than as separate rows. That limits us to a fixed number of signatures (one for now), but makes querying simpler.
|
@jsha, this PR appears to contain configuration and/or SQL schema changes. Please ensure that a corresponding deployment ticket has been filed with the new values. |
1 similar comment
|
@jsha, this PR appears to contain configuration and/or SQL schema changes. Please ensure that a corresponding deployment ticket has been filed with the new values. |
| -- ASCII-format OID relative to 1.3.6.1.4.1 | ||
| -- https://tlswg.org/tls-trust-anchor-ids/draft-ietf-tls-trust-anchor-ids.html#name-trust-anchor-identifiers | ||
| -- https://ietf-plants-wg.github.io/merkle-tree-certs/draft-ietf-plants-merkle-tree-certs.html#ca-ids | ||
| `mtcaID` varchar(255) NOT NULL, |
There was a problem hiding this comment.
From conversation this morning: should we instead have a separate database schema per mtcaID? This would allow us to more easily drop data about old MTCAs, without having to do temporal partitioning.
beautifulentropy
left a comment
beautifulentropy
left a comment
There was a problem hiding this comment.
Overall this schema looks good. Also, thanks for taking to the time document your intentions. I have some comments but nothing that stops this from moving forward.
| ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 COLLATE=utf8mb3_general_ci; | ||
|
|
||
| ALTER TABLE `orders` | ||
| ADD COLUMN `isMTC` bool NOT NULL DEFAULT FALSE, |
There was a problem hiding this comment.
isMTC is just mtcaID IS NOT NULL, right? Will these two columns be touched at different times/ by different components or does this just make querying less verbose?
There was a problem hiding this comment.
Yep, touched at different times: isMTC is set at new-order time to say "I want this to become an MTC", while mtcaID is set at issuance time.
Note that this depends somewhat on our decisions about ACME integration. If "this will become an MTC" is a property of certain profiles, we don't need isMTC as a separate field (though it also won't hurt). If it's a field in the new-order request independent of profile, then we need a new field in the DB.
Let's keep it as a field in the DB for now; since we're still in a prototyping phase we can easily remove it later.
| ALTER TABLE `certificateStatus` DROP COLUMN `LockCol`; | ||
| ALTER TABLE `revokedCertificates` ADD KEY `serial` (`serial`); | ||
|
|
||
| CREATE TABLE `checkpoints` ( |
There was a problem hiding this comment.
Perhaps worth a comment that we cannot guarantee uniqueness or monotonicity due to sharding and that these invariants are the responsibility of the MTCA.
| KEY `checkpointID` (`checkpointID`) | ||
| ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 COLLATE=utf8mb3_general_ci; | ||
|
|
||
| CREATE TABLE `landmarks` ( |
There was a problem hiding this comment.
Same here, it might be worth commenting that we cannot guarantee uniqueness or monotonicity due to sharding and that these invariants are the responsibility of the MTCA.
3 participants
New tables
checkpoints,checkpointSubtrees,landmarks, and some new fields onorders.We have a new concept
mtcaIDthat is the MTC equivalent ofissuerIDin our pre-existing infrastructure. This is a string-valued field that contains an ASCII-formatted relative OID, to match how CAs are identified in MTC. We also have the correspondingmirrorIDwhich contains a relative OID identifying a mirror.Note that we use the more specific term
mirrorrather thancosigner, because we expect that root programs will require full mirrors. And since the term "cosigner" in MTC can also refer to a "CA cosigner," we can be clearer by being more specific.Also note that mirror signatures are included as fields rather than as separate rows. That limits us to a fixed number of signatures (one for now), but makes querying simpler.
Part of #8738.