> From: Ron [mailto:r...@debian.org] > Sent: Sunday, October 09, 2016 10:43 PM > To: Ray Cheng <ray.ch...@entrust.com> > Cc: acme@ietf.org; Martin Thomson <martin.thom...@gmail.com> > Subject: Re: [Acme] Proposal for adding arbitrary CA-specific name-value > pairs to registration object > > On Thu, Oct 06, 2016 at 07:26:21PM +0000, Ray Cheng wrote: > > RFC 6648 does bring up some interesting points. I can appreciate how > > problems evolved with the HTTP and mail "X-" headers that may pass > > through multiple vendor products (both client and server). > > > > I see the proposed "ca-extension" in the registration object more as a > > place to hold content that a particular CA requires for its workflow. > > It is up to the CA to distribute to a client what extra info is > > required. > > Isn't the whole point of going through this work here (as opposed to just > having each CA invent its own thing), to provide a way for all of the > interested stakeholders to come up with a single interoperable standard > which they think will work for all of them? > > So that other people can implement clients to the documented spec, which > will work with any CA that implements that spec.
I don't see the proposed "ca-extension" as being incompatible with this goal. If clients implement this extension, they simply have to supply some runtime parameters to work with CA's which have particular parameter requirements. With respect to client-server interop, this "ca-extension" has some similarities to the "contact" field. For example, a "mailto" URI is optional in the eyes of ACME and certbot. However, a server is entitled to have a policy that say a valid "mailto" URI must be present. If someone using certbot chose not to send the "mailto" URI, the server can legitimately reject the request. The server will accept the request if someone using certbot "fills-in" the email. > > I think that if your due diligence on this has shown that you'll need > things which aren't already in the spec, then we should talk about those > and add them in an organised and openly thought through way. We do know that we have a requirement for a "ca-account" field. This can be added as an optional explicit field, or as a key-value pair in the "ca-extension". Client-server interop is similar in either scenario. > > If you don't know what they are yet, I think the right answer is that you > should go away and think about that until you do know - not that we should > add a way to create random incompatible extensions that still call > themselves "compatible" with this protocol. I would characterize these extensions as application-specific. X.509 extensions would be an appropriate analogy. Defining a new application-specific X.509 non-critical extension does not break X.509 clients and servers. Introducing new application features (e.g. Certificate Transparency) would be difficult if X.509 did not have extensions and required updates to its specification. I am not suggesting that the proposed "ca-extension" as being at the same level of importance to ACME as extensions are to X.509. I just want to point out that an extension mechanism is not necessarily bad for interop. > > > > If a client does not send the list of key-value pairs that a CA > > requires, it does not mean that the ACME client does not interoperate > > with that ACME server at a protocol level. > > That's kind of exactly what that means. Sort of by definition. > > > It just means that the client needs to "fill out the form" that the CA > > requires. > > Which means they are only "compatible" in the sense that "They both use > JSON". That's not a very useful definition of "interoperable". ACME is much more than the JSON that is in the registration object. It provides a lot of useful standardized cert management flow that is crucial to interop. > > > > Adding explicit elements like "account" and "operator" can also solve > > the problem for now. CA's not requiring these elements would simply > > ignore them. However, let's suppose 6 months from now that we, or > > another CA, discovers we need to collect another additional piece of > > registration data. The "ca-extension" object would allow us to do this > > without changing the client or the protocol. > > How can you do this without changing the client, if existing clients won't > send the extra fields you've decided to require? A compliant client does not need to change because it can send any new name-value pair. It is just a matter of an extra command-line parameter or a config file addition. > > And if you do that, then you *have* changed the protocol. You've just > done it without having to consult with anyone else, or without even having > to document the incompatible change you made to it. Which is like the > opposite of interoperable. > > I don't think that's a good plan. If you want to implement proprietary > extensions that only your own client knows or supports, nothing is > stopping you from doing that. But I think it's harmful to the idea of > ACME as an interoperable spec for you to pretend that is ACME. > > > If you do later realise there is something missing that is critical to > proper operation (or necessary because of some rule change at the CABF > etc.), then there's no reason people can't bring that back here and > propose that we need a revision to ACME to handle that case. > > If that discourages people from adding them on a whim, with very little > thought or peer review, that's probably a Good Thing too. > > > If you have a real need now for extra fields, we should talk about those > explicitly, and not about adding a way for you to add them at any time, > for any reason, without ever talking to anyone else about them. > > I think your feedback here as a potential server implementor is > potentially very valuable - but that will be wasted if we just turn this > spec into "anyone can implement their own random list of required JSON key > value pairs and call that ACME compatible", and you don't talk openly > about what extra things you think really are necessary to make this work > achieve its chartered goals. > As I have cited as examples, we have two known items that we would add to the registration object through the "ca-extension": "ca-account" and "requestor-name". I assume that a CA like Boulder would have no use for these as it does not have the concept of accounts and it has no intention of ever contacting a live person. Whether we add "ca-account" and "requestor-name" as extensions or as explicitly named fields should have no impact on Boulder or other CA's because they are likely to ignore them. One advantage of explicitly named fields is that usability is improved slightly when running clients like certbot - at least for CA's that cared about them. The reasons are that it can be prompted for in the UI flow and you can have explicitly named command-line parameters. The down-side is that you are adding slightly more complexity for CAs that don't care about them (e.g. prompting for not applicable values and having extra documented parameters that are not needed). _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
