implement modular CA

[lukehinds]

as per #107 , implement a modular layer for CA / HSM integration.

[dlorenc]

I think the "lowest common denominator" API here is to switch from these protobufs to using CSRs for the API format. The "transport" layer for where to send the CSR would vary, but that's easier to make pluggable.

[mmalone]

Consider factoring out the HSM/KMS backend code from step-ca for this: https://github.com/smallstep/certificates/tree/master/kms

[mmalone]

/cc @maraino who wrote the above code and may have thoughts on how reusable it is.

step-ca can also run as a registration authority with a backing CA. We use a different interface for this, which may also be reusable for Fulcio. That code is at https://github.com/smallstep/certificates/tree/master/cas.

[dlorenc]

It would be nice to handle at least the following:

• in memory/k8s secret with the root key (mostly for testing I guess)
• a root key in a KMS
• pkcs11/softHSM
• any other cloud providers people are interested in?

[dlorenc]

Oh, k8s even has its own basic CA.

[lukehinds]

Oh, k8s even has its own basic CA.

I think they are using cfssl? (I might be wrong there as its a while ago since I looked)

[lukehinds]

it could be handy to add AWS Certificate Manager Private Certificate Authority

My main want is SoftHSM and other pkcs11 HSM's via miekg/pkcs11 and I expect thalesignite/crypto11 to expose the crypto.Signer interface.

[maraino]

I'm the main the package that @mmalone mentioned, https://github.com/smallstep/certificates/tree/master/kms.

This provides a common interface for different KMS/HSMs:

• AWS KMS
• Google CloudKMS
• PKCS11 (SoftHSM, YubiHSM, ... using thalesignite/crypto11)
• SoftKMS (using a key in memory or in a file)
• Yubikey
• ssh-agent (although this might not support everything)

The main interface looks like this:

type KeyManager interface {
    GetPublicKey(req *GetPublicKeyRequest) (crypto.PublicKey, error)
    CreateKey(req *CreateKeyRequest) (*CreateKeyResponse, error)
    CreateSigner(req *CreateSignerRequest) (crypto.Signer, error)
    Close() error
}

[lukehinds]

@maraino , have you considered Google Certificate Authority Service as well?

Just thinking that could mean that we possibly have smallstep/certificates/kms as a main interface to abstract the ca / hsm coverage we need?

Is AWS KMS is different to AWS Certificate Manager?

[maraino]

@lukehinds Yes, and there's an implementation for it too, but it's in the cas package, so it uses a different interface, the basic interface is this

type CertificateAuthorityService interface {
    CreateCertificate(req *CreateCertificateRequest) (*CreateCertificateResponse, error)
    RenewCertificate(req *RenewCertificateRequest) (*RenewCertificateResponse, error)
    RevokeCertificate(req *RevokeCertificateRequest) (*RevokeCertificateResponse, error)
}

And there are some extra methods that allow retrieving the root certificate, or even create a full PKI on Google CAS

[maraino]

Is AWS KMS is different from AWS Certificate Manager?

Yes, AWS KMS is this https://aws.amazon.com/kms/ I haven't look into AWS CM, but I assume an implementation would be more like the CAS one above.

[mmalone]

have you considered Google Certificate Authority Service as well?

We have integrated with GCP CAS. But that's a "CA Backend" service, not a "Key Management Service". The primary difference is that a CA backend accepts a CSR and returns a certificate whereas a key management service / hardware security module (KMS/HSM) exposes a lower-level signing API where you send bytes and get a signature back.

Oh, k8s even has its own basic CA... cfssl...

I think what @dlorenc might be referring to is the Kubernetes CSR resource. In a vanilla k8s cluster all this does is maintain a list of CSRs in a queue that some person/operator/whatever acting as a signer can monitor and update with an issued certificate. I don't think this is really useful here, but could be wrong.

It would be nice to handle at least the following...

• K8s secret we do by just mounting the issuing certificate/signing key into the CA container.
• Root key in KMS/pkcs11/softhsm uses the KMS library linked above
• The big three cloud providers have KMS offerings that are all pretty popular (GCP CloudKMS, AWS KMS, Azure Key Vault). There are also virtualized HSM offerings that support PKCS#11 (AWS CloudHSM, Azure Dedicated HSM). With GCP and Azure you can get HSM-backed keys as a "protection level" of their KMS offering with the same API. We support GCP CloudKMS, AWS KMS, and PKCS#11 in the KMS library linked above, which covers most of these offerings. The exception is Azure Key Vault, but I think there's a PKCS#11 bridge for that product.

It occurred to me that another way we could integrate that may be easier short-term is to have Fulcio act as an RA in front of step-ca, the same way it currently integrates with GCP CAS. Thoughts?

[bobcallaway]

a related question - does step-ca deal with precertificates?

[maraino]

a related question - does step-ca deal with precertificates?

We have an old branch that supports CT and creates precertificates for it. Right now we can generate a precertificate if you add a custom template like this one:

{
    "subject": {{ toJson .Subject }},
    "sans": {{ toJson .SANs }},
{{- if typeIs "*rsa.PublicKey" .Insecure.CR.PublicKey }}
    "keyUsage": ["keyEncipherment", "digitalSignature"],
{{- else }}
    "keyUsage": ["digitalSignature"],
{{- end }}
    "extKeyUsage": ["serverAuth", "clientAuth"],
    "extensions": [
        {"id":"1.3.6.1.4.1.11129.2.4.3", "critical": true, "value":"BQA="}
    ]
}

[lukehinds]

closing as fulcio has a modular system in place now