Thanks, Hugo; this is all good, and thanks for the response. I'll clear the DISCUSS, though I still would like to discuss the "ca-" thing a little more. But the main point is that the BCP was known and considered, and the working group made an informed choice.
> > — Section 4 — > > > > If appropriate non-ACME identifiers are not present in the > > ACME Validation Methods IANA registry, the CA MUST use identifiers > > beginning with the string "ca-", which are defined to have CA- > > specific meaning. > > > > Was the working group aware of BCP 178 (RFC 6648), and did they consider the > > “ca-“ prefix in that context? If so, how does the working group propose to > > avoid the problems outlined by BCP 178? > > Yes. > > All of these identifiers are already scoped to a specific CA via a > domain name, due to the nature of the CAA specification. The CAA > specification also provides that parameters in general are a CA-specific > namespace. > > The core complaint of RFC 6648 is that nonstandard values tend to > graduate to being standard values, and at that point need to be renamed. > > Because "ca-" methods are CA-specific and unrelated to ACME, it is > essentially necessary that they be configured in relation to, and in > knowledge of, a specific CA and its issuance and validation practices. > In this regard it is not the same concept as an X- prefix, which defines > nonstandard parameters in the vague hope that such parameters will be > adopted by numerous implementations and entities across the net. This is > a permanent reservation for CA-specific meaning and there is no > expectation that one CA's "ca-foo" method is the same as another CA's > "ca-foo" method. This all makes sense. Would it be reasonable to recommend not just "ca-", but "ca-<caidentifier>-"? Experience has shown that if "flarb" is a common thing among CAs (or whatever) and Verisign implements a "ca-flarb", that will tend to leak and become an unregistered standard... but that's far less likely to happen if it's "ca-verisign-flarb". I'm not suggesting any formalization nor registry for the <caidentifier> part, but just the fact that it's included tends to get us away from the problem that BCP 178 is addressing. Again, this is no longer at DISCUSS level, and if the working group thinks this isn't a good idea, go ahead as planned. But please chew it over a bit and see if you can swallow it. > > — Section 6 — > > I have no idea what you’re trying to say here. This is a Proposed Standard, > > right? It defines two new parameters. Are you now trying to say that we > > have > > not really defined anything? I don’t understand. > > The CAA specification allows parameters to be attached to CAA > properties, but this is a CA-specific namespace. Per CAA, there is no > IANA registry for CAA parameters, and a CA is not required to give the > meaning given in this I-D to "accounturi" or "validationmethods" > parameters, unless it chooses to implement this RFC. See "Restrictions > Ineffective without CA Recognition". OK; no longer a DISCUSS, and no need for further response, but if you can re-word that to explain the situation a bit better, that'd be great. Thanks again, Barry _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
