> when a client requests a certificate with a deprecated profile it will
receive an invalidProfile error, however it would be nice to know about
this situation in advance.
Should the profile include a "deprecated" flag, or a notAfter date of some
sort? That may require modifying the proposal's JSO
My primary concern with "moving beyond the CSR" is that it's a defacto
standard which is widely supported today, so we should make sure that (at
least for the most part), an ACME client can still take a CSR and transform
it into whatever public key format is required. But if the ACME client
doesn'
My personal opinion here is that adding a profile field to the Order object
is likely to hamper client adoption, and as Ben just said, makes
configuration more difficult if CAs don't have matching profiles.
An alternative approach that I believe has been used is adding URL
parameters to the direct
s. or perhaps even adding some errata
to published RFCs.
Thanks,
Matthew McPherrin
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
RFC 7301 section 3.1 says:
> the "ProtocolNameList" MUST contain exactly one "ProtocolName"
On Fri, Feb 4, 2022 at 12:49 PM Salz, Rich wrote:
>
>- Does "with the single protocol name" mean that it should be
>considered an error if the ACME server offers more than a single supported
>
