On Thu, Jan 08, 2026 at 01:25:40PM -0600, Mike Ounsworth wrote:
>
> Just thinking-out-loud here: If the deployment problem that you're
> trying to solve with the profile-sets draft is actually better
> described as "CA-recommended-crypto-policy", then maybe we should do a
> draft that specifically does that well?
>
> I'm thinking something of this shape:
>
> A new directory object:
>
> recommendedCryptoPolicies: {
> "tlsCryptoPolicy": "https://example.com/acme/tlsCryptoPolicy";,
> "smimeCryptoPolicy": "https://example.com/acme/smimeCryptoPolicy";
> }
>
> where fetching that gives you this:
>
> GET https://example.com/acme/tlsCryptoPolicy
> ...
> {
> "MldsaRootEccEE": {
> "CaAlg": "ML-DSA-65",
> "EeAlg": "ECDSA-P256",
> "profile": "profile1"
> },
> "Mldsa": {
> "CaAlg": "ML-DSA-65",
> "EeAlg": "ML-DSA-65",
> "profile": "profile2"
> }
> }
>
> where the algs map to some registered alg strings, maybe in the JOSE
> registry, and the profile IDs map to those published by the CA in
> their ACME directory as per Aaron's draft.
>
> I'm not sure this is a good idea ... I'm just brainstorming out loud.
Some quick thoughts:
- What purpose does that "CaAlg" serve? I think that combination of
"EeAlg" and "profile" would imply what kind of cert you get.
- One could use TLS SignatureScheme numbers for algorithm
identification. However, that would be messy with RSA[1].
- There could be some human-readable description field.
[1] Currently RSA seems to be the only case where multiple EE TLS
SignatureScheme values all map to the same key type (The "ibs"
stuff does not seem like it is used with certificates).
What one could do is to use 2052 (rsa_pss_rsae_sha256) for RsaEncryption
keys and 2057 (rsa_pss_pss_sha256) for RsaPss keys.
-Ilari
_______________________________________________
Acme mailing list -- [email protected]
To unsubscribe send an email to [email protected]
