[erlang-questions] Figuring out proper ssl certificate settings with 17.3

[Vincent de Phily]

Hi,

we're trying to upgrade from 17.1 to 17.4 and are hitting authentication 
failures, apparently due to the changes that introduced the partial_chain 
option.

First some background:
* We want to authenticate both server and client
* We manage certificate ourselves, and don't care about the OS-supplied CAs.
* The signing hierarchy is
  TopCA -> ServerCA -> Account1ServerCert
                    -> Account2ServerCert
                    -> ...
        -> ClientCA -> Account1ClientCert
                    -> Account1Device1Cert
                    -> Account1Device2Cert
                    -> ...
                    -> Account2ClientCert
                    -> ...
* The server and test client are in erlang, the real clients are in various
  languages (and we can't afford to update them).


What we used to do, works fine in 17.1:
  server: {cert, Account1ServerCert}, {cacerts, [ClientCA]}
  client: {cert, Account1Device1Cert}, {cacerts, [ServerCA]}
(in some cases we used the 'file' version of the option, but that doesn't 
change the semantics AFAIK).

But that gives us an "unknown ca" error with 17.4.

The minimum list of cacerts that seems to work is [ServerCA,TopCA] for the 
server and [clientCA,TopCA] for the client, but:
* Having to specify the TopCA is an administration pain (lots of configs to
  change, and need to take the file out of the vault).
* I'd rather not send unnecessary bytes over the wire. Ideally I don't want to
  send any root/intermediate CA, only the leaf cert.
* Huh ? Why does ClientCA not need to be in ther server's cacerts (and vice-
  versa) ?

I guess some confusion comes from the fact that the cacerts option is used for 
two different things (authenticating the cert received by the peer, and 
sending intermediate CAs to the peer to help it authenticate me). Maybe the 
option could be split in two ?

AFAIU, the new requirement for TopCA to be present comes from a tightening of 
the check mandated by the RFC : the certificate chain (which one ? the one 
sent by the client or the one set up locally) needs to end with a self-signed 
cert.

I'll pass on the weirdness of that requirement (I'll trust whichever CA I 
decide, wether it's self-signed or not, damnit), as it looks like 
partial_chain is expressely designed to bypass it. But I wasn't able to write 
one that worked *and* didn't look like a big security hole. Could somebody 
write an example partial_chain fun that works for my usecase ?

Ideally, the docs could do with some clarifications :
* The spec for partial_chain has a typo (at least a missing '}')
  Again, and example in the docs wouldn't go amiss.
* It's not clear which chain it acts uppon
* Is the semantic of cacertfile really different for the server and the
  client ? From my knowledge of TLS, it should be symetrical (even if the
  common real-world case is that the client doesn't authenticate itself), so
  the option should be in the common section (next to cacerts with a note that
  one is equivalent to the other).


Thanks in advance.

-- 
Vincent de Phily