Revert "SA: Stop supporting OCSP status NotReady" (#8429)

Reverts #8395

The reverted change needed to land one release behind
#8394. Unfortunately, the
first release which contained 8394 also contained a bug, and had to be
rolled back. The next release would contain both 8394 and 8395, which
would lead to availability issues during a deploy when non-updated CA
instances try to communicate with updated SA instances.

Revert 8395 so that the next release can contain only 8394. This change
will be followed by a re-land of 8395, after 8394 has been fully and
successfully deployed.

Part of #8343

Author: aarongable

ca/ca_test.go

@@ -135,6 +135,10 @@ func (m *mockSA) GetLintPrecertificate(ctx context.Context, req *sapb.Serial, _
 	return nil, berrors.NotFoundError("cannot find the precert")
 }
 
+func (m *mockSA) SetCertificateStatusReady(ctx context.Context, req *sapb.Serial, _ ...grpc.CallOption) (*emptypb.Empty, error) {
+	return &emptypb.Empty{}, nil
+}
+
 var ctx = context.Background()
 
 func setup(t *testing.T) *testCtx {

core/objects.go

@@ -76,11 +76,16 @@ type OCSPStatus string
 const (
 	OCSPStatusGood    = OCSPStatus("good")
 	OCSPStatusRevoked = OCSPStatus("revoked")
+	// Not a real OCSP status. This is a placeholder we write before the
+	// actual precertificate is issued, to ensure we never return "good" before
+	// issuance succeeds, for BR compliance reasons.
+	OCSPStatusNotReady = OCSPStatus("wait")
 )
 
 var OCSPStatusToInt = map[OCSPStatus]int{
-	OCSPStatusGood:    ocsp.Good,
-	OCSPStatusRevoked: ocsp.Revoked,
+	OCSPStatusGood:     ocsp.Good,
+	OCSPStatusRevoked:  ocsp.Revoked,
+	OCSPStatusNotReady: -1,
 }
 
 // DNSPrefix is attached to DNS names in DNS challenges

docs/ISSUANCE-CYCLE.md

@@ -8,12 +8,44 @@ At a high level:
 2. Recheck CAA for hostnames that need it.
 3. Allocate and store a serial number.
 4. Select a certificate profile.
-5. Generate and store linting precertificate.
-6. Sign, log (and don't store) precertificate.
+5. Generate and store linting certificate, set status to "wait" (precommit).
+6. Sign, log (and don't store) precertificate, set status to "good".
 7. Submit precertificate to CT.
 8. Generate linting final certificate. Not logged or stored.
 9. Sign, log, and store final certificate.
 
 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).
 
-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.
+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.
+
+# OCSP Status state machine:
+
+wait -> good -> revoked
+   \
+    -> revoked
+
+Serial numbers with a "wait" status recorded have not been submitted to CT,
+because issuing the precertificate is a prerequisite to setting the status to
+"good". And because they haven't been submitted to CT, they also haven't been
+turned into a final certificate, nor have they been returned to a user.
+
+OCSP requests for serial numbers in "wait" status will return 500, but we expect
+not to serve any 500s in practice because these serial numbers never wind up in
+users' hands. Serial numbers in "wait" status are not added to CRLs.
+
+Note that "serial numbers never wind up in users' hands" does not relieve us of
+any compliance duties. Our duties start from the moment of signing a
+precertificate with trusted key material.
+
+Since serial numbers in "wait" status _may_ have had a precertificate signed,
+We need the ability to set revocation status for them. For instance if the public key
+we planned to sign for turns out to be weak or compromised, we would want to serve
+a revoked status for that serial. However since they also _may not_ have had a
+Precertificate signed, we also can't serve an OCSP "good" status. That's why we
+serve 500. A 500 is appropriate because the only way a serial number can have "wait"
+status for any significant amount of time is if there was an internal error of some
+sort: an error during or before signing, or an error storing a record of the
+signing success in the database.
+
+For clarity, "wait" is not an RFC 6960 status, but is an internal placeholder
+value specific to Boulder.

mocks/sa.go

@@ -12,6 +12,8 @@ import (
 	"github.com/go-jose/go-jose/v4"
 	"github.com/jmhodges/clock"
 	"google.golang.org/grpc"
+	"google.golang.org/grpc/codes"
+	"google.golang.org/grpc/status"
 	"google.golang.org/protobuf/types/known/emptypb"
 	"google.golang.org/protobuf/types/known/timestamppb"
 
@@ -211,6 +213,10 @@ func (sa *StorageAuthorityReadOnly) GetCertificateStatus(_ context.Context, req
 	return nil, errors.New("no cert status")
 }
 
+func (sa *StorageAuthorityReadOnly) SetCertificateStatusReady(ctx context.Context, req *sapb.Serial, _ ...grpc.CallOption) (*emptypb.Empty, error) {
+	return nil, status.Error(codes.Unimplemented, "unimplemented mock")
+}
+
 // GetRevocationStatus is a mock
 func (sa *StorageAuthorityReadOnly) GetRevocationStatus(_ context.Context, req *sapb.Serial, _ ...grpc.CallOption) (*sapb.RevocationStatus, error) {
 	return nil, nil