Decouple CA from SCEP for RA (proxy) capability

[jessepeterson]

The SCEP library as implemented acts as both a SCEP service and as a CA which is currently coupled. While its true the Depot interface exists for changing how certificates are stored and accessed the actual certificate issuance is still assumed to be in the domain of the SCEP library by nature of the SignCSR() method being a part of the PKIMessage struct which creates only its own certificates currently:

scep/scep/scep.go

Lines 435 to 436 in 40b05ae

	// sign the CSR creating a DER encoded cert
	crtBytes, err := x509.CreateCertificate(rand.Reader, template, crtAuth, msg.CSRReqMessage.CSR.PublicKey, keyAuth)

In order to better support proxying SCEP requests (what the SCEP spec calls a "Registration Authority") or otherwise issue certificates outside of the SCEP library this should be completely decoupled. This would support the SCEP server being a thin SCEP-protocol wrapper around another CA — or even proxying to to other SCEP servers.

Other open issues along this same theme are #2, #61, and #77.

As far as implementation goes, as a suggestion, perhaps instead of a Depot interface a CA interface can exist that that represents the signing & other CA work which, for the reference built-in CA, in turn uses the Depot interface — or maybe just consolidate to a single CA interface (or expand the Depot interface to also issue certificates). Also, the server will need to support an RA keypair for SCEP-only operation while including the CA certificate as per the SCEP spec.

For reference here's the current Depot interface:

scep/depot/depot.go

Lines 10 to 15 in 40b05ae

	type Depot interface {
	CA(pass []byte) ([]*x509.Certificate, *rsa.PrivateKey, error)
	Put(name string, crt *x509.Certificate) error
	Serial() (*big.Int, error)
	HasCN(cn string, allowTime int, cert *x509.Certificate, revokeOldCertificate bool) (bool, error)
	}