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.
I maintain a web app ACME client and this tweak would help greatly with how
I present the information to the client user.
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.
current:
"profiles": {
"profile1": "https://example.com/acme/docs/profiles#profile1";,
"profile2": "https://example.com/acme/docs/profiles#profile2";,
}
maybe instead:
"profiles": {
"profile1": {
"name": "Default Profile"
"doc" : "https://example.com/acme/docs/profile1";
}
["desc" omitted]
"profile2": {
"name": "Short Lived"
"desc": "A certificate that is only valid for 6 days. Also the only profile
that supports IP identifiers."
"doc" : "https://example.com/acme/docs/profile2";
"restrictedAccess": true
}
}
On Wed, Aug 6, 2025 at 6:53 PM Michael Richardson <[email protected]>
wrote:
>
> I have read draft-aaron-acme-profiles.
> It seems like a good idea, please adopt.
>
> Q: If a CA can offer legacy, quantum-safe hybrid, and maybe quantum-safe
> only, certificates, are these *profiles*?
>
> Some random comments that can be fixed after adoption:
>
> 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.
>
> 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.
>
> 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!
>
> The CSR is a container for public key only, and
> !!draft-ietf-lamps-csr-attestation!!
>
> 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.
>
>
>
> --
> Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
> Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> _______________________________________________
> Acme mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
_______________________________________________
Acme mailing list -- [email protected]
To unsubscribe send an email to [email protected]
