On Thu, Oct 13, 2016 at 04:29:08PM +0000, Ray Cheng wrote: > > From: Ron [mailto:r...@debian.org] > > > > 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.
I think you are confusing 'simple mechanics' with 'interoperability'. It might be 'simple' to add arbitrary extra fields, but it's impossible for them to be interoperable if they aren't documented and well defined as part of the relevant standard. > 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. "There are other fields which are optional" is not a useful similarity. The important difference is that "contact" is a well known field name with well defined semantics for implementors. > > 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. The mechanics may be similar, but 'interop' is only possible if you actually standardise exactly what should go in that field when and why. I don't particularly care how we add this to the JSON object as long as it's not totally insane - what I'd want to see is a rationale for why ACME needs specific additional fields for your implementation, that they aren't already provided for by some other existing mechanism, and a clear definition in the standard of how what you need should be done by anyone who does need it. We don't get any of the things which are essential for interop if the solution is just "anyone can add or remove or change their own extra fields any time they like". And in the case of something like what I imagine "ca-account" might be used for, some security consideration and review might be useful too. What stops me from putting someone else's account details into my requests for certificates from you? Surely you need something stronger than this to securely link an ACME account key to your own billing account records? And you're probably not the only CA who might want a solution to that, so we should have one well thought through solution for ACME, not one per CA (that possibly one developer invented without review, under time pressure from their manager to deploy it by tomorrow). > > 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. X.509 probably isn't the best example of Good Practice or a model for good interoperability :) X.509 version 3 (which added the extensions) seems more like a case of the ITU throwing its hands in the air in acknowledgement of their own process limitations, and doing the same as what was done to Q.931 for QSIG. We've had a long time to learn the lessons of how that turned out, and the IETF is open to all participants, so I don't think we have the need to punt on carefully considering exactly what this protocol needs to function for all of its intended users. I do quite expect that whatever we do today, there probably will be an ACME v3 eventually as people find bugs and/or limitations or security vulnerabilities that aren't yet obvious to us. I'd be happier if that didn't happen, but I'm realistic enough to expect that it probably will. So it's a bit early for us to already be giving in to just letting chaos rule for 'normal' implementations by early adopters. JSON objects are already inherently extensible, they don't need a special tag defined for that like ASN.1 does. The interesting question here is not "Do we need a mechanism to allow future extension?" (because the answer to that is 'no, we already have that'), it is "Should we allow extensions that aren't in themselves standardised?" - And speaking from my own experience, I think the answer to that should be no too. That would be a big mistake to repeat this early in the evolution of ACME. > > > 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. Yes. Which is useful and allows interop precisely because it is standardised. If we encourage undocumented proprietary extensions to it, we lose that value almost immediately. We can't stop people from doing that anyway. But that doesn't mean we shouldn't prefer creating a standard which is complete enough to not need them for already known users and uses. > > > 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. Which is functionally equivalent to saying "we have interop, because an end user can always edit the source of the client they use, to make it compatible with a CA using non-standard extensions". Assuming they can actually find out the details of those extensions themselves, which aren't a documented part of ACME. > 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. Boulder or other CAs aren't the case where interop with your requirements is necessary. It's the client software implementors and end users which want to be able to interop with any ACME using CA who need all of this to be well standardised. And they can only do that if these extra things are standardised too. They don't have to be mandatory for every server to use, but it is important that CAs which do use them, don't all reinvent the same wheel differently. We learnt not to build train lines with different gauge tracks a long time ago too :) Let's talk about what "ca-account" and "requestor-name" should do, and confirm there really isn't some other existing place those functions should be (or are already) supported in. And then if we do really need them because nobody thought of that yet, let's add the needed mechanism and documentation for 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). I think we need to not make too many assumptions about UI here, or design the protocol around what seems 'simple' in one UI idiom or another. We should look at what information you need carried in the protocol to do your job as a CA that isn't already present or supported by what we have defined so far. How the client software collects that information is a problem with many right answers for different users. The important bit here is that we have just one clear way to send that same information to all CAs that do require it. That way the client software doesn't need specialisation for each CA to send that data, or need to collect essentially the same data in multiple different forms to suit each CA's quirks in their custom fields for it. It then does become the 'simple' matter of "do I need the content of this field from the user or not". And they can safely err on the side of sending it, knowing that CAs which don't care really will ignore it, and not mistake it for a similarly named but incompatible field of their own. Ron _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme