Hello to everyone,
RFC8823 (RFC 8823 - Extensions to Automatic Certificate Management Environment for End-User S/MIME Certificates) is ready and I like to ask if there are any plans to support S/MIME using ACME by Let's Encrypt.
I know PGP is there its free and so on but the business environment mostly requires S/MIME.
Let's Encrypt TLS certificates are accepted really well so I think S/MIME certificates would be too.
Kind regards,
graphik
ISRG root keys are in root store but it's only for valify TLS servers, so mail certificate signed by it won't be trusted.
and while that is using acme but protocal path is so different so it will use sapareate key/server instance even if LE choose to implement it.
I don't think this is correct. Looking at the roots @ Chain of Trust - Let's Encrypt it seems the roots don't have the "X509v3 Extended Key Usage" extension set, but the intermediates do.
Therefore, in theory, it would be possible to generate a specific intermediate from the ISRG root certificate(s) with the correct "X509v3 Extended Key Usage" extension specifically for S/MIME purposes.
it's not key side but root program side: they need to apply for root programs again with email added to requested trust indicators
Requested Trust Indicators (email and/or SSL and/or code signing): SSL
Hm, interesting, I did not know that. Thanks for the correction!
Does this also apply for other root programs, such as Microsoft (Outlook)? And how easy would it be to change this? It might be easier to make such a change when it isn't necessary to actually modify the root certificate itself.
https://ccadb-public.secure.force.com/microsoft/IncludedCACertificateReportForMSFT
Microsoft has same kind of certificate usage limit
I bet it'd have to go through a process of ensuring that audits and what-not were all up-to-spec for the usage of email signing in addition to the existing usage of TLS server/client certificates. Kind of like how ISRG Root X2 is in the process of being added to roots, it's probably "easier" than the first time around of a new CA getting added but still needs to be scrutinized. Actually, probably best practice (my guess) would be to have a separate hierarchy entirely for S/MIME and TLS, so if Let's Encrypt wanted to get into doing this they might just make an entirely separate root for it.
I agree that Let's Encrypt offering free S/MIME would be great, but I don't know as it's something they'd be willing to add to their busy plates yet.
I bet it would be quite a lot of dev-time to add support for that in Boulder.
That's right, according to Chrome:
...priority is given to ... CAs whose certificates and certificate hierarchy are only used to issue TLS server certificates, and do not issue other forms of certificates.
Mozilla also has a similar recommendation, though not worded as strongly:
We also recommend that CAs consider using separate root CA certificates with separate public keys (or separate intermediate CA certificates with separate public keys under a single root) when issuing certificates according to different Certificate Policies, so that we or others may selectively enable or disable acceptance of certificates issued according to a particular policy, or may otherwise treat such certificates differently (e.g., in our products' user interfaces).
Microsoft only has requirements on separate intermediates:
Issuing CA certificates that chain to a participating Root CA must separate Server Authentication, S/MIME, Code Signing, and Time Stamping uses. This means that a single Issuing CA must not combine server authentication with S/MIME, code signing or time stamping EKU. A separate intermediate must be used for each use case.
reading rfc Boulder for email will be diverse from current tls Boulder
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
