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 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. 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. > 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". > 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? 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. Ron _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
