The name of the profile is stable; it'll be a breaking API change to remove one. We may decide to change the description, for example because of a website change.
We aren't saying the certificates for a given profile will stay the same. For example, the upcoming OCSP deprecation will apply to all profiles.
I think this is exactly what @jvanasco is trying to avoid. So like today, "tlsserver" means the cert will have properties A, B, and C. But if in the future "tlsserver" changes to have properties A, B, and D, he'd like the client to be able to know that the "tlsserver" now means something different than it did the last time it was used. Then it can decide to do whatever with that information (prompt the user, terminate and log, fall back to a different profile, fall back to no profile, etc).
It's a minor quibble considering the user may have no choice regardless of what has changed. I can see this happening for lifetime changes in the future. And we know it's already going to happen for tlsserver in staging once the short-lived certs roll out.
Yep. The current "bad profile" response is an HTTP 400 with the following body:
{
"type": "urn:ietf:params:acme:error:malformed",
"detail": "Invalid certificate profile, \"fakeprofile\": not a recognized profile name",
"status": 400
}
I also hope it stays 400 and doesn't change to 404 or 409 which would conflict with my client's current retry logic for the ARI replaces field. Then I can keep being lazy.
They should stay the same, or come with a version string. The upcoming OSCP situation is a perfect example.
@rmbogler understood me almost perfectly (I don't think this is a minor quibble). The client/subscriber should be able to detect this change and decide if they want to fall-back to another certificate profile or continue with this one. I am sure most clients would choose to implement the default as "continue to use the new version, but notify the user" (and an RFC could recommend this).
Using the forthcoming OCSP change as an example, once that is removed from the profiles, a client should be able to detect that has happened. The client should either be preconfigured to continue renewal OR not renew and notify the Subscriber for review. The subscriber would then see the information and decide if they want to continue renewing with this configuration OR if they feel they should utilize a different profile – or possibly even use another CA that might offer this.
If Clients used a default of "Continue renewal", they would not incur any downtime. Clients would also also not have to offer Subscribers any choice on this or program any functionality. Most clients and subscribers would be perfectly happy with "CAs Best Recommendation"
For those Clients and Subscribers that want (or need) to utilize this information - combined with daily ARI checks, a Subscriber electing to delay renewal and review the detected change should not have any downtime (unless a revocation were in place). Many organizations have security policies and compliance requirements; so a change the CA considers minimal may have an overstated impact with that Subscriber. Allowing automated systems to detect these changes becomes important.
Again, stressing this point - the only thing the CA needs to do is publish some sort of unique identifier about the current profiles "offering". It would be up to the client and subscriber to act on this information, and the default recommendation should be renew with the CA's recommendation. People don't expect lease or subscription terms to change midway through.
I understand this desire, but we specifically considered this possibility and decided against it. We explicitly do not want profiles to be static or identified by a content-addressed ID.
Over the last ten years, we've made many changes to the contents of our certificates. Some of those changes were simple, like changing how we compute the Subject Key Identifier. Some of those changes were compliance-critical, like reducing the validity period by one second. Some of those changes were (will be) much bigger, like removing the TLS Client Auth EKU.
The purpose of profile selection is to make those big changes much easier. Allow people to opt into them early. Socialize the idea that they're good or important. Let them live side-by-side for extended periods if we're not sure whether that change will ever become the default.
But we have to accomplish that goal without making other, smaller changes harder. If profiles were required to be static, fixing something like the 90-days-and-one-second bug would require either:
None of those are good outcomes. We need to be able to modify profiles essentially at-will. We've been doing so for many years, successfully. So we decided that tying our hands and binding profile names to their exact content would be an anti-feature for us.
The way LE has managed and communicated changes so far has been a great example.
I don't think profiles should be seen as a way to opt-out of undesired changes, but rather to opt-in early to (potential) future defaults.
Curious why you say this is a "big" change - big in terms of potential user impact, or of compliance?
There's a number of things with Client Auth EKU:
That set of circumstances leads to a bit of a squeeze: Emailing everyone and telling them they have to change isn't appropriate because it's not widely used. But we can't do targetted reach-out either, because it's not visible for us who is using their certs as client certs. And we've got a deadline.
That is on the Clients and Subscribers. The CA and RFC should explicitly recommend renewing if change is detected as the default behavior. Acting on a detected change, short of logging/notification, would be decently sized work and UX effort that most projects would not prioritize or even consider.
We need to be able to modify profiles essentially at-will. We've been doing so for many years, successfully. So we decided that tying our hands and binding profile names to their exact content would be an anti-feature for us.
I hope you reconsider. The CA should continue to change these things at will, but a Subscriber should not have to ensure they receive API announcements to learn their certificate structures may have changed. As this is an RFC meant to be widely adopted, other ACME CAs will eventually implement this - and their motivations might not be so well-intentioned and good natured as ISRG. Tossing a version id (or other signifier) into the payload is the only way to ensure a client knows their certificate's structure would change on renewal.
Looking at the most popular clients, most would certainly continue using the profile regardless of content change (especially Certbot) as an explicit decision for the benefit of their users. The bulk of commandline projects and libraries would likely follow suit for technical constraints. On a practical level, I honestly don't think this could have the negative impact you fear.
This brings into question the CA's participation in the first place. 
I think if the CA isn't well-intentioned they shouldn't be a trusted CA in the first place. Or, put another way: use a different CA. They can make changes like you're describing without profiles, but at least with profiles there's some structure around cert parameters and some incentive to document them.
I think it is good that profiles are not versioned. My guess would be that if they were versioned the number of websites that would go down accidentally on each change because someone misconfigured their ACME client would far outnumber the number of websites that would go down because their owners wanted them to go down. And I guess if you really want to stop renewing on every profile change, you can still do that the same way you can today by inspecting your final certificate and only loading it into your server configuration if it matches your expectations.
I am however surprised about the recommendation to check the selected profile against the directory object before attempting to renew. Over time some profiles will become obsolete or redundant, but they will have to be kept supported in new-order requests in order to not break existing clients. However when clients check the directory object, these obsolete profiles will have to be listed there too. This means that UI clients that offer a profile selection dropdown will have to list all obsolete profiles the CA ever had forever.
It's a subjective measurement, but I'd argue that every commercial CA falls into that definition for me, in at least some aspects. LetsEncrypt is non-profit CA with a publicly stated mission for Internet Security; AFAIK every other CA is ultimately driven towards shareholder profit.
A likely scenario that I worrry about, is that a commercial CA might decide some elements of a given profile should be moved into another profile on a different subscription or billing mechanism. i.e. a typical technology company innovation of creating a new billing product on the same services ("this now costs extra"). IMHO, I think the ACME RFCs should expect CAs to act in the worst permissible/compliant ways possible - and with that viewpoint it becomes important to notify Clients and Subscribers of these changes. I think our friends at ISRG/LetsEncrypt come from the perspective of being too biased as the good guys at a non-profit who champion a free and public internet, and sometimes forget how sleazy commercial interests can act.
I agree with this statement of fact. But I disagree with the idea that it is critical for a client to know that their certificate's structure will change on the next renewal. That hasn't been true for the entire history of the WebPKI, and I don't think that the introduction of profiles is the right time to introduce such a constraint.
I think of this as being the happy medium. A client shouldn't break and stop renewing just because the contents of a given profile have changed. But a client should be able to tell when its selected profile is no longer supported at all. In my opinion, the default behavior should be "if the configured profile no longer exists in the directory, request a certificate with no profile specified, and also notify my user", but clients could make a variety of sane decisions here. The CA must be able to remove old profiles from its directory listing, to prevent infinite growth. The only question is what a client should do when it encounters that situation, and I think that having the CA hard-fail such requests will encourage better client behavior (an explicit fallback) than silently ignoring the unrecognized profile name.
Apologies if I missed an earlier discussion of this, but: is there a way to phase out obsolete profiles? Sure, you could remove it from the list at the directory endpoint to no longer advertise it, but what would clients do then? Or are CAs bound to a profile for life?
Btw, there's an additional, implied change in the tlsserver profile, compared to classic:
Because the CN is empty, the Subject Alternative Name extension becomes critical (as mandated by RFC 5280). Which in turn implies that (very old) clients or tools that do not understand the SAN extension, MUST reject the certificate.
But in practice that's unlikely to cause (additional) problems, as the set of clients/tools that do not understand the SAN extension is most probably a subset of clients/tools that insist on a CN.
This essentially becomes the same situation as the versioning concern I have, but would happen less frequently so a "hard fail" on rejecting this has been deemed acceptable. Clients would use essentially the same logic and ux to properly handle these cases as they would with versioning, which is one of the reasons why I hope ISRG changes their mind on it.
I wouldn't say that a hard-fail has been deemed acceptable. It's only a hard-fail on the server's part -- clients are able to take whatever action they wish. it seems likely that clients which prioritize continuity of service would interpret a "invalidProfile" error as a recoverable error and retry the newOrder request with no profile specified. I'll add more client-oriented guidance to this effect to the relevant section of the Internet-Draft.
Regarding classic: you probably don't want to continue serving this as-is forever, but given the description "The same profile you're accustomed to", you can't really let it evolve either, without changing its literal meaning.
So maybe it's better to call it something else from the beginning, like default, or even legacy, of which the definition is not a "snapshot" of something existing, so it can evolve in time...
Heh, both "default" and "legacy" were alternative names that we considered, and dismissed. Not "default" because we may change the default at some point (making the features of the classic profile opt-in instead of opt-out). Not "legacy" because the connotations are slightly too negative.
We can change the textual description very easy; it's intended to be fully human-readable. And it's very likely that when we go to Production with profiles, it will be a link to a documentation page.
IMHO, the meanings of both those terms would be too confusing.
The server could identify the default profile (i.e what is used if no profile is provided), and recommend a profile for clients to use (which is likely to change over time). Based on the previous support concerns with the cross-sign deprecation, the default and recommended profiles are likely to change and not be in sync at times.
A potential way of doing that within the same payload would be using a field that starts with an illegal character for a profile name, and the value is a profile name;
{
"*default": "classic",
"*recommended": "short",
"classic": ...,
"short": ...,
}
It's actually not feasible to simply identify a "default" profile. For example, when we begin issuing certificates for IP Addresses, any new-order request with an ipAddr identifier will be defaulted to the short-lived profile, while new-order requests containing only dnsName identifiers will continue to be defaulted to the classic profile. Other CAs could have much more complex heuristics.
The same goes for a "recommended" profile -- recommended for whom? For what kinds of certificates?
This is why I've purposefully kept this system so simple: a list of names, and human-readable descriptions of them. That's it. Anything beyond that begs for clients to be executing (and therefore requiring their users to configure) complex heuristics, which I don't think is a good outcome.
At the end of the day, subscribers should still be able to trust their CA to pick the best certificate profile for them, just as they've been doing for years.