The announcement above starts with the following words:
ACME is designed to be extensible by adding new JSON fields....
Can anybody please point me to the section and specific language in RFC8555 supporting that claim?
The "extensible" nature of the protocol is mentioned multiple times in the introduction in section 1.
This document describes an extensible framework for automating the issuance and domain validation procedure
It should be noted that while the focus of this document is on validating domain names for purposes of issuing certificates in the Web PKI, ACME supports extensions for uses with other identifiers in other PKI contexts.
In section 4:
Note that while ACME is defined with enough flexibility to handle different types of identifiers in principle, the primary use case addressed by this document is the case where domain names are used as identifiers.
5 Likes
That is certainly true as far as general considerations are concerned, but when we look at the precise technical specifications, it seems to me that - as of today - extra fields are just not allowed in section 9.7.1 of RFC 8555.
9.7.1 talks about fields in Account objects which is not where the random entry is being added. Regardless, that section is talking about fields that must be in the various objects. It doesn't say anything about things that can't be in those objects.
Negative language in these RFCs is very explicit using words like "MUST NOT" and "SHOULD NOT". But there's nothing that says the server MUST NOT add a random entry to the JSON output. And the extensible nature of the protocol almost guarantees that fields will be added to these objects over time that clients will need to deal with.
Is there a problem you're running into?
9 Likes
Sorry, my bad. I meant to refer to section 7.1.1 (Directory). I cannot see any passage in that section allowing for extra entries in the directory object.
I am not saying that adding an extra field in the directory object should be prohibited.
I am just saying that the current language in RFC8555 is unclear (at best) about such an addition being allowed. If allowing it was the intent, perhaps an Errata would be in order.
In the context and culture or RFCs, not addressing your concern for additional fields with a "MUST NOT" or "SHOULD NOT" is considered to be a clear allowance. This is done in large part to support future extensibility.
If the RFC were to oppose the additional fields, it would mean the ACME protocol is essentially locked and can not evolve with new functionality unless the RFC is obsoleted and completely replaced. That doesn't routinely happen in the context and culture of RFCs - instead it is favored that protocols are extended.
6 Likes
Also, the use of "Initial contents" as header for the table of resources in 9.7.5 implicitly allows for additional resources added to this list.
Although I agree it would have been a good idea to incorporate some statement as "An ACME client MUST ignore any ACME Resource Types it doesn't recognise and SHOULD NOT error out. Blahblah add something about future extensions blahblah." or something similar.
7 Likes
Also, the use of "Initial contents" as header for the table of resources in 9.7.5 implicitly allows for additional resources added to this list.
I agree. It's not crystal clear, but it leaves the door open 
Thanks for all comments.
1 Like
Also note that Let's Encrypt itself implements extensions to the directory json (draft-ietf-acme-ari-01 - Automated Certificate Management Environment (ACME) Renewal Information (ARI) Extension), so whether it's in the spec or not an LE client would fail if it didn't allow that.
2 Likes
Thank you, I was not aware of that draft.
1 Like