certificates
certificates copied to clipboard
smallstep
ACME S/MIME support
I have just found that ACME now support S/MIME via rfc8823. While the implementations of this is still ongoing, there is already a client being developed ontop of certbot: polhenarejos/acme_email.
What are your thoughts on this?
Excuse my ignorance, but what's the use case for S/MIME certificates from a private/internal CA? How does root distribution work? If I'm using a cert from my internal CA, you wouldn't be able to validate my cert without manually configuring your client to trust my root cert, right? Or is there something I'm missing?
If both parties have different CAs then yes, it would be less useful. But if they have different domains but connect to the same CA, you get the benefits of S/MIME, signature verification and/or encryption. Probably also useful in organization setups, with different departments.
I'm still looking into this, but if it's possible to combine with dmarc and publish the root CA via dnssec, that would be something. Hopefully though let's encrypt will implement this acme to be the public signature.
I think you can find S/MIME deployments with internal PKI in (large) Windows deployments with elevated (internal) email security requirements. You'll likely find AD CS and perhaps also SCEP in use there, so then that would've to be (partly) replaced by step.
Something that I just thought of: assuming that it is possible to integrate with public CAs using their (proprietary) interfaces and to authorize issuance (simple API authentication would be nice; a challenge via mail would be more involved, if practical at all), it may be possible to function like a gateway to that API, verifying the requestor identity and handling the ACME S/MIME challenge (or use another provisioner) in step, resulting in an S/MIME certificate from that public CA. Conceptually it is similar to the cloudcas integration.
Yea, it seems like root distribution is the problem here. I can understand the elevated internal security use case, but I don't know how common that is. If there's a way to do root distribution (e.g., with DMARC? I didn't know DMARC did that though?) then this becomes more interesting.
It feels like the main value of RFC8823 is to make it easier for end-users to get publicly trusted S/MIME certificates. but I definitely could be wrong. I can see value in implementing this spec just to have an open source reference implementation for people to test against and whatnot, but that's fairly niche, and I think this could be a fair amount of work. The RFC itself looks pretty simple, but we don't currently send or receive email from step-ca, so we'll have to figure that out.
For now, let's leave this open. If anyone else from the community wants this, please express interest by giving this issue a 👍 or, even better, leaving a comment with a couple sentences on why you need this.
(e.g., with DMARC? I didn't know DMARC did that though?)
I did more digging on the DMARC part, and it seems there is no support for anything other than SPF and DKIM. I guess it's because it's supposed to be domain wide policy, while S/MIME is for the end-user.
For now indeed, the ACME part of S/MIME is only useful if you can get the root to be public or you have a big enough cooperation.
There is the certificate DNS record if you have DNSSEC on, but I don't know how that one interacts in general.
As for S/MIME, a second use-case is for signing commits. Useful if you have something like an internal gitea repository. But if you also want to make it public, it could become problematic.
For now at least, how about making a template for S/MIME through the current providers? Do the current client certificates already work for that?
Yes, you should be able to use templates to issue certificates with the right extensions (key usage / extended key usage) for S/MIME using any of our existing provisions (OIDC would work really well for this). We don't include the necessary extensions by default though. You may also need to use RSA keys since S/MIME also does encryption (you can't encrypt with ECDSA keys).
For code signing we're keeping a close eye on https://www.sigstore.dev/.