I intend to save profile names in an 'ini' file for renewal orders. I did not notice any restriction on valid profile names. I think there should be to make local serializing/parsing easier and perhaps coding.
I would preclude the empty string and very long strings. Furthermore, I would restrict whitespace to the regular keyboard space character placed only within the profile name: no leading or trailing whitespace.
Whether or not other restrictions are a good idea is beyond my expertise to opine. Perhaps only some subset of ASCII characters should be allowed, perhaps not. Seems to me that all RFCs must have some grammar production rules, right?
The only relevant limitation in the ACME standard is that the service and clients use UTF-8 encoded JSON, which means even emojis would be valid profile name content. Because the profile names are object keys the limitation is more around what is a valid JSON object key, which is pretty much any string. RFC 8259 - The JavaScript Object Notation (JSON) Data Interchange Format
Profile names can also change, so your client should check the requested profile name is still offered by the CA when renewing, and decide a course of action, otherwise your order may fail.
I would suggest just UTF8 encoding your INI file (ASCII is rarely the right choice) and don't use the profile name as a filename unless you can normalize it to your filesystem naming rules.
I agree some sort of restrictions might be nice. Or at least, if empty-string, string with newlines, and emoji names are to be allowed, they should be listed in example test cases. You should make an issue on Aaron's github repo for it, just to make sure this idea gets tracked:
Thanks. My design is to use a human-readable and human-editable text files that happen to be ini files. My client checks for profile availability every time per the draft document, and my will fail the certification attempt if the profile is given and not advertised in the current directory resource. "The client MUST NOT request a profile name that is not advertised in the server's Directory metadata object." I do not cache the directory resource. Does anyone?
My ini design is a very unsophisticated subset of what OpenSSL manpage 5 'config' documents and of how OpenSSL seems to work. My file system encoding is utf-8. Leading and trailing whitespace are trimmed from the value unless escaped in the ini file's assignment statement. The escaping methods are those given by any unix-like shell except that single quoting and double quoting are (perhaps) equivalent except for the choice of quotation character type (but every such detail is not given in the 'config' manpage.
I suppose I would like processing of profile names to be easy for computer and human. Even if no restrictions are placed on profile names by the profiles extension protocol per se, an explicit statement on what the boundaries are for profile names would be helpful to readers and implementer. If there are no additional restrictions, that could be stated. If server implementations SHOULD uses 'simple' names, that could be stated.
Peter, I deliberately posted my thoughts here to not trouble the people doing the 'heavy lifting' because the 'heavy lifting' is what gets things done.
I like the way you think and write, and this is my first occasion to tell you so since I formed that opinion. You are a careful writer. You said might, which does not inspire confidence that I am on the right track, but then you listed an alternative possibility, and either way is explicit. I think the standard should be explicit on what the boundaries are. I will make a request for clarification on the point.
Thank you. I think a lot of the ACME standards could use being more explicit on expected behavior and (even if not in the "spec" itself) have robust test cases for client implementors (and server implementors!) to expect. (I still find it odd that as far as I can tell, the standard for ARI allows the server to send a hundred digits after the seconds' decimal point when giving a time.)
I think that restricting profile names to ASCII-only is too restrictive. I see no reason that one shouldn't be able to specify a name using one of those many human languages with a different and/or more complicated alphabet. Using emoji is odd, but if some CA wanted to have a "" profile on their staging server, I guess there are worse options.
Empty string is a corner case; I could see a CA wanting to use it to explicitly mean "default" (and hopefully have the same behavior as not passing a profile at all). I don't really care if it's allowed, or disallowed, but it seems like it ought to be called out explicitly somewhere one way or the other.
And similarly for newlines (and horizonal tab, and other whitespace one doesn't usually use in identifiers in computing), or really long names, I don't know if they really hurt anything, but there may be security implications if one side or the other isn't expecting something. See, for instance, this severe bug in acme.sh a couple years ago where a client could be tricked into executing code sent by a hostile server. Since ACME clients are often run in at-least-somewhat privileged environments (usually on the same system as a web server), having specifications that help people think about possible buffer overflow and escaping vulnerabilities can be useful. And so, like, embedded quotation marks in a profile name should be either explicitly banned, or explicitly called out as a possibility.
In general, I feel like whenever I've tagged Aaron on something here he's said that Github issues are the best way to make sure he sees something, so that was why I suggested it. (Though maybe I'm overgeneralizing.) I agree that there's a lot of heavy lifting in making a good Internet Standard, and well, I haven't signed up for joining the IETF ACME group or anything since I know I can't commit the time for it. But I'm sure they'd be happy for more people willing to do the heavy lifting.
As said, I am trying to save the profile value as an 'ini'-style value. I now realize that I can save anything by using the technique demonstrated by the Unix-like 'alias' command with no arguments. To wit, I can single quote all runs of characters without a single quote and backslash escape each single quote that is part of the string. OpenSSL interprets a backslash escape of a Linefeed/Newline character as a logical-line continuation token (as do Unix-like shells and Python).
The idea of control characters including Linefeed/newline/LF/'\n' and Carriage Return/CR/'\r' rub me the wrong way. I think identifiers should have some conventional identifier value assurances. Then I got an idea before I posted this. From RFC 4949, "Internet Security Glossary, Version 2":
$ identifier
(I) A data object -- often, a printable, non-blank character
string -- that definitively represents a specific identity of a
system entity, distinguishing that identity from all others.
(Compare: identity.)
Tutorial: Identifiers for system entities must be assigned very
carefully, because authenticated identities are the basis for
other security services, such as access control service.
I draw attention to the above phrase 'often, a printable, non-blank character string'.
As @petercooperjr carefully considered, the empty string could be used as the default. The word 'default' would work too. Is it advisable to get the default profile by an explicit name that semantically means the current default (whatever it is right now) and to implicitly indicate the default with no 'profile' key or field in the JSON request for a new Order Resource? I ask only to encourage the formulation and use of a well-considered answer. I don't have such an answer. If I am making too much of this, then of course that is also an answer.
" profile on their staging server, I guess there are worse options.