*Resending after joining the list.* Thanks for clarifying that for me. It's the answer I expected.
I have a very different use case which I believe has gotten somewhat less attention than the public CA use case. I am studying large orchestration systems (some internal and some external like Kubernetes) that have very similar APIs to ACME. In these systems, the CAs are not publicly trusted. All communication secured by these CAs is internal. These APIs are used to provide credentials to processes running in the system. Processes use these credentials to establish (essentially) mutual TLS authentication with other processes. In these systems, there is a very loose coupling between the process and the TCP loadbalancers that might front the process. A process exposes a secured network endpoint and doesn't know or care where connections are coming from. A process only knows it's own identifier. This poses a problem when trying to talk to a process through a named loadbalancer. Standard TLS validation will fail if a client talks through a named loadbancer to a process that presents a certificate with a DN of the process's identifier and without a SAN of the loadbalancer identifier. Possible solutions I can think of are: 1. Have the CA add SANs to the process's CSR for the loadbalancer identifiers the process backs. This is out of ACME spec, but we aren't going to get a ticket :) 2. Have the process fetch which loadbalancer identifiers it will back before building and sending a CSR to ACME. This has some performance implications. We like processes to start rapidly. This has some architecture implications. The loose coupling is quite handy. 3. Terminate/re-establish TLS in the loadbalancers. This has some performance and security implications. 4. Relax TLS and have processes consult a central, trusted map of loadbalancer identifiers to process identifiers to validate server authentication. This solves the problem and has some other nice properties but is (fairly radically) out of TLS spec. One of these solutions is less bad than the others and we can figure out how to workaround if we decide ACME satisfies this use case. On Thu, Aug 17, 2017 at 11:26 AM, Salz, Rich <[email protected]> wrote: > There’s compliant and there’s compliant. J The IETF has no protocol police, > and you will not get a ticket for issuing a cert “wrongly.” Will anyone > complain if you change the CSR to say “S.A.” or “Pty” instead of “Inc” or > “Ltd”? Of course not. > > > > Will people be upset if you add other random SAN fields they didn’t want or > ask for? Yes. This is the internet, someone is bound to be upset. J > > > > It’s great to see commercial interest. If there are real roadblocks we can > issue errata, updates, new challenges, or whatever it takes. > > > > /r$ > > > > _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
