[Acme] Re: Early review of draft-ar-acme-pqc-tlsjws-00

[Matt G1 <[e-mail]>]

OFFICIAL



Hi all,

I wanted to echo Mike’s comments about using ‘profile’ in this document. It gave me the erroneous first impression that this was going to be somehow about certificate profiles.

Something that struck me about the draft was that it didn’t refer to, or use the phrase, “account key”. I prefer the simple direct approach so would suggest referring to that rather than JWS request authentication (noting we also have another draft using JWT claim constraints in progress).

Whilst I’m not an ACME operator, I would like to have ACME up for discussion again in my main SDO (3GPP), and the mandatory nature of the profiles and the MUSTs in them isn’t helpful to me – having the algorithms available is.

The profiles just raise questions like: do I have to wait until my TLS stack has PQ authentication on it before I can use PQ ACME account keys. On the server side how do I cope with clients which still want to use traditional account keys and TLS 1.2 whilst still permitting new clients to use PQ and TLS 1.3? If I receive a newAccount message with ML-DSA for the account key but the connection was over TLS 1.2 what error message should I send if/when I reject the newAccount message? If proof-of-possession is added as a challenge does that need to be a PQ algorithm to qualify as either profile?

Perhaps the principles in the profiles belong in a security considerations section of an RFC adding PQ account key options?

Matt

Matt G1 – NCSC Telecoms Security Consultant (Standards)
[e-mail]



OFFICIAL
From: Mike Ounsworth <[e-mail]>
Sent: 04 July 2026 04:44
To: IETF ACME <[e-mail]>
Subject: [Acme] Early review of draft-ar-acme-pqc-tlsjws-00

Hi Aritra and Tiru,

Draft reviewed: draft-ar-acme-pqc-tlsjws-00


Overall:

While I think it is necessary to have an ACME document that says "You MAY use the following PQC algs in ACME JWS / TLS", I have pause about the nature of this document which feels more like a policy document that is REQUIRING a specific set of PQC algs. I would like to hear from the community of ACME operators about whether they like the mandatory policy feel of this document, or would prefer something softer that simply makes the new algorithms available to use.

I also think this document as written will invite a lengthy bikeshedding exercise about which algorithms are REQUIRED (especially your mandated support for Ed25519 / Ed448 hybrids). I suspect this draft will go much smoother if you simply say "The following algorithms MAY be used within ACME", and leave it at that.




Specific comments / nits:


I find the use of the term "profile" here collides with the more common uses such as "RFC5280 is a profile of ITU-T X.509", or the phrase "certificate profile" as used in draft-ietf-acme-profiles. I wonder if you could use a different term in order to avoid further overloading the term "profile"?

I have seen the terms "Quantum-Ready" and "Quantum-Safe" used the same way you are using "Quantum Ready" and "Strictly Quantum-Ready". But I do not believe there is any consensus around these terms.


4.2:
"ACME servers operating under a quantum-ready profile MUST implement
   ML-DSA-44, ML-DSA-65, and ML-DSA-87 [RFC9964]"

Again, this feels far too strong to me. What if you have an ACME server operating as part of an IoT manufacturing facility where the entire PKI is ML-DSA-44. Or you have an ACME server part of a CNSA 2.0 compliant infrastructure that only supports ML-DSA-87. This draft is requiring that those ACME servers MUST implement the other ML-DSA parameter sets even though they will never be used?