You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/ISSUANCE-CYCLE.md
+3-35Lines changed: 3 additions & 35 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,44 +8,12 @@ At a high level:
8
8
2. Recheck CAA for hostnames that need it.
9
9
3. Allocate and store a serial number.
10
10
4. Select a certificate profile.
11
-
5. Generate and store linting certificate, set status to "wait" (precommit).
12
-
6. Sign, log (and don't store) precertificate, set status to "good".
11
+
5. Generate and store linting precertificate.
12
+
6. Sign, log (and don't store) precertificate.
13
13
7. Submit precertificate to CT.
14
14
8. Generate linting final certificate. Not logged or stored.
15
15
9. Sign, log, and store final certificate.
16
16
17
17
Revocation can happen at any time after (5), whether or not step (6) was successful. We do things this way so that even in the event of a power failure or error storing data, we have a record of what we planned to sign (the tbsCertificate bytes of the linting certificate).
18
18
19
-
Note that to avoid needing a migration, we chose to store the linting certificate from (5)in the "precertificates" table, which is now a bit of a misnomer.
20
-
21
-
# OCSP Status state machine:
22
-
23
-
wait -> good -> revoked
24
-
\
25
-
-> revoked
26
-
27
-
Serial numbers with a "wait" status recorded have not been submitted to CT,
28
-
because issuing the precertificate is a prerequisite to setting the status to
29
-
"good". And because they haven't been submitted to CT, they also haven't been
30
-
turned into a final certificate, nor have they been returned to a user.
31
-
32
-
OCSP requests for serial numbers in "wait" status will return 500, but we expect
33
-
not to serve any 500s in practice because these serial numbers never wind up in
34
-
users' hands. Serial numbers in "wait" status are not added to CRLs.
35
-
36
-
Note that "serial numbers never wind up in users' hands" does not relieve us of
37
-
any compliance duties. Our duties start from the moment of signing a
38
-
precertificate with trusted key material.
39
-
40
-
Since serial numbers in "wait" status _may_ have had a precertificate signed,
41
-
We need the ability to set revocation status for them. For instance if the public key
42
-
we planned to sign for turns out to be weak or compromised, we would want to serve
43
-
a revoked status for that serial. However since they also _may not_ have had a
44
-
Precertificate signed, we also can't serve an OCSP "good" status. That's why we
45
-
serve 500. A 500 is appropriate because the only way a serial number can have "wait"
46
-
status for any significant amount of time is if there was an internal error of some
47
-
sort: an error during or before signing, or an error storing a record of the
48
-
signing success in the database.
49
-
50
-
For clarity, "wait" is not an RFC 6960 status, but is an internal placeholder
51
-
value specific to Boulder.
19
+
Note that to avoid needing a migration, we chose to store the linting certificate from (5) in the "precertificates" table, which is now a bit of a misnomer.
0 commit comments