Consider ARI "replaced" status in expiration-mailer

[griffin]

It's the Highlander problem!

There can be only one!

[griffin]

Technically, any cert with the same SANs as an earlier cert is considered a duplicate of any such earlier cert AND (thus) a renewal of any such earlier cert.

Basically, a linear-single-parentage "family" of certs with identical shoes (SANs), unique hats (issuance timestamps), and possibly different sweaters (keys).

[griffin]

Yes, I am a bit loopy today.

[mholt]

But if only part of the cert was replaced?

[petercooperjr]

Fundamentally, the goal of sending "replaced" in ARI (at least the inspiration for the feature initially) is to tell the CA "You may revoke that certificate now." (Aside: And while adding it to the order in the recent draft certainly simplifies some things, there were advantages to the prior way of a separate request so that you could indicate that not only was the certificate acquired but that it was installed and the old one no longer in use.)

So, if only part of the cert is replaced, then I guess it comes down to the question of "Are you done with the old certificate"? If not, and it's still going to be in use for some purpose, then I think that one shouldn't send the replaces field. But if it's no longer going to be installed or used anywhere once the "replacement" is acquired, then it should probably be set. (Of course, I'm sure a lot of clients don't currently have this concept or a good way to expose it to their administrators.)

To bring this a little back on topic, I think that "replaced" in the sense of "I'm okay with the CA revoking it if needed" and "I don't want the CA to send me reminder emails for it" should generally be the same concept, and it wouldn't be surprising if both actions happened when a replaces field gets sent.

[mholt]

Ah... I like that framing:

@petercooperjr

it comes down to the question of "Are you done with the old certificate"?

You're either done with it or you're not. That's a good mental model.

So, in the splitting-out scenario, maybe a client should only indicate "replaces" after the last of the SANs is issuing its cert.

For the consolidating scenario, we are still left without options AFAICT.

[aarongable]

@Osiris

I do see a new draft (4) has been published recently at draft-ietf-acme-ari-04 - Automated Certificate Management Environment (ACME) Renewal Information (ARI) Extension, so maybe it has already been addressed?

Draft -04 has only minor updates (such as improving the list of current implementations, adding acknowledgements, and a couple other rephrasings) over draft-03; none of the protocol itself has changed.

@Nummer378

Yes, there may be more or less rare edge cases where the "replaces" field isn't sufficient and there will be a certificate that is in fact replaced, but couldn't be marked as such. But where's the problem with that? In such a case, we might still have cases where the renewal mailer sends mails when it doesn't need to. But that's the status quo.

I concur with this statement. While I can certainly imagine a version of ARI that allows the "replaces" field to list as many certificates as one likes, it does not appear to be a common use-case, and it's not even clear what commands or configuration one would issue to a hypothetical client to get it to submit such a request.

@Nummer378

We certainly don't need to mail a user about a certificate that has been marked as replaced

We plan to do this. If you'd like to follow the progress, you can file a bug for this feature request and you'll be notified when we actually implement it.

[webprofusion]

In my experience the most common confusion is when someone gets a cert for example.com then changes it to include www.example.com (or vice versa) because they realized their website still didn't work, then months later they get the expiry warning about the first combination they used. So, great idea!

We generally don't need to worry about other forms of consolidation with multiple replaces, but I can see why it's potentially a problem for systems that dynamically acquire certs for hosts because they obviously get one cert per domain/subdomain as required dynamically at the time. In that instance they would presumably not get invalid expiry notifications anyway unless they are also dynamically consolidating certs.

[MikeMcQ]

@webprofusion

would presumably not get invalid expiry notifications anyway unless they are also dynamically consolidating certs.

Or just not registering with an email address

[Osiris]

@aarongable

and it's not even clear what commands or configuration one would issue to a hypothetical client to get it to submit such a request

I could imagine a --replaces option (multiple times or comma separated list) to e.g. Certbot with a certificates serial (which is included in the certbot certificates output) or certificate name.

The client then verifies the input of course and if it complies with the rules of the draft/RFC (I saw something about having at least one SAN entry in common) et c.

Doesn't need much imagination I'd say

[Osiris]

@aarongable When reading the draft 04, in section 4.1 ('The "renewalInfo" Resource') I'm actually missing that the response from the ACME server to the renewalInfo resource is actually a "renewalInfo object".

While it's very much a 1+1=2 situation, wouldn't it be better to actually explicitely mention their relationship?

Also, in section 3 there suddenly is an example at the bottom without mentioning it's an example. When reading it I was thinking: "Where did this suddenly come from?" Wouldn't it be nicer to lead in the example with an introduction saying something like: "Here's an example"?

Yes, I'm a stickler

[aarongable]

Both of these are conventions that I'm following from other ACME RFCs:

• the title of the section itself ("The renewalInfo Resource") identifies that the section is talking about both a path and the object served by that path, both of which are called "renewalInfo". See RFC 8555 Section 7.1 Resources for a comparison.
• the uncommented example follows the standard set by all of the other "foo object" sections, e.g. RFC 8555 Section 7.1.2 Account Objects.

Honestly I don't have a strong sense of what's "right" here -- RFC documents are so far from the kind of writing I normally do that I don't know when to follow my own editorial instincts vs when to cargo-cult conventions from preceding documents. If you want editorial changes to this draft which will make it diverge from other ACME documents, I suggest bringing them up on the acme@ mailing list where others can chime in.

[orangepizza]

would it make sense to allow mark a certificate 'replaced' without pointing any new certificate, marking end of lineage? (like it was for one time event subdomain, and now that event is ended so won't need to renew)

[petercooperjr]

I think the closest thing to that is revoking for reason "cessationOfOperation". While it would be nice to have a way to tell CAs that "I don't need to renew" without making the CA actually revoke the certificate, it may not be a compelling enough use case to try to get into ARI.

[Osiris]

@aarongable

Both of these are conventions that I'm following from other ACME RFCs

Well, not that I'm a RFC professional or anything, but I'm also not really a fan of how RFC 8555 is written to be honest. E.g., the "directory" is often called a "directory resource" and is also listed in the resources section at 7.1, but it's not listed in section 9.7.5, the "resource types" registry (also not at IANA). To me such details stand out as "contradictory".

For me, RFCs "should" be written as structured as possible without any doubt in interpretation (CAA Issuer Critical Flag anyone?) or contradictions and I believe extensive use of definitions and strictly keeping to those definitions help a lot. I also like lists, tables and/or structured graphs more than too much words. (I'm not saying RFC 8555 nor draft-ietf-acme-ari don't do that or are a badly written. I just think it's perhaps RFC 8555 not the best example.)

@aarongable

Honestly I don't have a strong sense of what's "right" here -- RFC documents are so far from the kind of writing I normally do that I don't know when to follow my own editorial instincts vs when to cargo-cult conventions from preceding documents.

I can appreciate that I would rather not stand in your shoes

@aarongable

If you want editorial changes to this draft which will make it diverge from other ACME documents, I suggest bringing them up on the acme@ mailing list where others can chime in.

Mailing the ACME WG is kinda scary Maybe I'll do that, maybe not, I'll think about it