Replying to both messages above in-line:
On Wed, Aug 6, 2025 at 3:53 PM Michael Richardson <[email protected]>
wrote:
>
> Q: If a CA can offer legacy, quantum-safe hybrid, and maybe quantum-safe
> only, certificates, are these *profiles*?
>
I think they certainly can be, but don't have to be.
For example, Let's Encrypt today determines which issuing intermediate to
use (an RSA 2048 issuer or an ECDSA P-384 issuer) based on the algorithm of
the pubkey submitted in the Finalize request. This mechanism doesn't
require this Profiles draft, and doing it this way is a principled
position: we want to ensure that our profiles are completely consistent
across issuers.
But it's easy to imagine a CA which (for example) always uses an RSA
intermediate unless the client requests an ECDSA profile in the NewOrder
request. And the same goes for using quantum-safe issuers. I suspect that
different CAs are going to take different approaches -- some using
Profiles, some using other heuristics -- as the transition to new key types
and signature algorithms sweeps across the WebPKI.
> Section 4:
> The client MUST NOT request a profile name that is not
> advertised in the server's Directory metadata object.
>
> Clients will client... so yeah, tell them not to, but the paragraph after
> says that they can expect to be rejected. The sentence seems unnecessary
> to
> me. I rather we document what happens when a client misbehaves, rather
> than
> say not to be bad.
>
Is there harm in having both, as the draft currently does? I personally
think it's nice to have strong language in the standard which can be
pointed to in bug reports against misbehaving clients.
It's also possible, since the list of profiles is not client ("Account")
> specific, that some profiles are simply unavailable to that client.
> So, even if they use a profile name that is listed, it still might not be
> allowed.
> Like, maybe clients get *one* code signing certificate per quarter or
> something.
> That's probably two different things to reply with.. [PROBLEM-DETAILS] to
> the rescue.
>
Let's Encrypt actually does this today: the "shortlived" profile is
advertised, but locked behind an allowlist to allow us to slowly roll out
usage and avoid overwhelming CT log operators. If a client requests that
profile but isn't on the allowlist, we respond
with urn:ietf:params:acme:error:unauthorized, which already exists in
RFC8555. I'm not sure that I want to get super specific about this in this
draft -- for example, the situation you propose where they're only allowed
one cert from this profile per quarter is better represented
by urn:ietf:params:acme:error:rateLimited.
> Section 5, Security Considerations
>
> The one exception is in regards to CA Policy Considerations. RFC
> 8555 did not address how a server should determine whether it is
> willing to issue the certificate as requested by the finalize CSR.
> This document greatly simplifies this determination by making the
> contents of the CSR (beyond the Subject Alternative Names and Subject
> Public Key) irrelevant to the decision-making process.
>
> This looks like a normative update to RFC8555.
> I think it should be moved to a new section, and explicitely made into such
> an update. I'm not even sure the SAN in the CSR should be trusted!
>
I agree, the SANs in the CSR can't be trusted! That's why RFC 8555 says
that the CSR SANs must be checked, and must be found to be identical to the
Order identifiers. The only reason this draft mentions the SANs is because
it *doesn't* absolve the ACME Server from performing the RFC 8555-mandaded
cross-check.
I have plans to get rid of the CSR entirely, but that's a discussion for a
different draft.
> As a minor thought:
>
> "profiles": {
> "profile1": "https://example.com/acme/docs/profiles#profile1
> ",
> "profile2": "https://example.com/acme/docs/profiles#profile2
> ",
> }
>
> maybe instead:
>
> "profiles": {
> "profile1": { "doc" : "https://example.com/acme/docs/profile1";
> }
> "profile2": { "doc" : "https://example.com/acme/docs/profile2";
> }
> }
>
> I don't have a good suggestion right now for a machine readable version of
> the profile. I don't know if there is one beyond some legal template for
> a
> CSP, but perhaps there will be one in the future.
>
I'm actually pretty opposed to the idea of machine-readable profile
descriptions. This is because they will inevitably expand to cover every
possible aspect of a certificate, and this leads to three problems:
1) We already have a format for expressing arbitrarily-detailed features of
a certificate, including previously-unknown extensions: x509. I'm unwilling
to re-invent x509 in JSON; others have already tried.
2) For a client to choose between profiles, it will have to allow its user
to configure preferences for various profile features. That means that
client authors *also* have to reinvent x509 in their config format.
3) As soon as a client has expressed two preferences (e.g. ECDSA over RSA,
and 90d validity over 398d validity), it's possible for a server's set of
advertized profiles (e.g. shortlivedRSA and longlivedECDSA) to be
unsatisfiable.
That said, making this field a dictionary means that if someone comes up
with a *good* idea of something to annotate a profile with, at least we'll
have a place to put it. This is a good future-proofing idea, so I've filed
https://github.com/aarongable/draft-acme-profiles/issues/13 for this.
On Wed, Aug 6, 2025 at 4:35 PM Greg T. Wallace <greg=
[email protected]> wrote:
> re: the profile object, I agree it would be nice to expand the profile
> object to standardize interpretation by the ACME client so it knows how to
> present the information to the client operator. As it currently sits, the
> client would have to parse the string and try to determine what information
> it contains. It would be nice if there were a human friendly name, a url
> field, and a free form text description. All fields could be optional and
> ACME Servers could decide if they want to implement none, some, or all of
> them.
>
The human-readable name is the key in the profiles object: it's just a JSON
string, CAs can put anything they want in it.
I'm open to the idea of separating a URL from an in-line text description,
perhaps with "doc" or "desc" keys to differentiate the two. I've filed
https://github.com/aarongable/draft-acme-profiles/issues/14 to continue
thinking about this.
> Additional thoughts: Based on what Let's Encrypt is currently doing, there
> could be a "restrictedAccess" bool for profiles that aren't generally
> available. Or generally if there is an object instead of a string,
> operators could add their own custom fields. Finally, even if only a single
> string is currently desired, the current format locks things to one string
> vs. defining an object with one string leaves room in the future to define
> additional keys of the object.
>
See above for why I'm opposed to adding machine-readable metadata to
profile objects.
Thanks all for the feedback so far!
Aaron
_______________________________________________
Acme mailing list -- [email protected]
To unsubscribe send an email to [email protected]
