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. 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. It just means that the client needs to "fill out the form" that the CA requires. Using certbot as an example, possible implementations may include: 1. A new "--reg-ca-ext <key>=<value>" parameter This parameter would take the <key> and <value> put in into the "ca-extension" object. You can specify multiple key-value pairs by specifying multiple "--reg-ca-ext <key>=<value>" parameters 2. A new "–-reg-ca-ext-file" <property-style file with a list of attributes> parameter 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. > -----Original Message----- > From: Martin Thomson [mailto:[email protected]] > Sent: Tuesday, October 04, 2016 9:23 PM > To: Ray Cheng <[email protected]> > Cc: Hugo Landau <[email protected]>; [email protected] > Subject: Re: [Acme] Proposal for adding arbitrary CA-specific name-value > pairs to registration object > > Now is probably a good time to acknowledge RFC 6648. In short, if entrust > see value in having an account number, then you should just add a field > "account" and be done with it, otherwise you end up with prefix-regret. > As for operator, maybe "operator": { "name": "Me", > "email": "[email protected]" }. > > On 5 October 2016 at 04:44, Ray Cheng <[email protected]> wrote: > >> Surely vendorized keys would be better: > >> > >> { > >> "com.example.blorpNo": "BLORP122946" > >> } > > > > Can you provide a bit more details on what you mean by "vendorized keys" > and how it differs from the arbitrary name-value pairs in the proposal? > > > > It seems the above can be represented as: > > "ca-extension": [ > > "com.example.blorpNo": "BLORP122946" > > ] > > > > _______________________________________________ > > Acme mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
