<div dir="ltr">Hi!<br><div class="gmail_extra"><br></div><div class="gmail_extra">To answer a previous question, in the thread. The X509 certificate path validation is done identical on the server and the client side, however that does not mean that the CA inputs are used only for this reason. The Server will always send a cert, but the client will only send one if it was requested by the server. Also the server may send information in its request to inform the client of which certs it supports.</div><div class="gmail_extra"><br><div class="gmail_quote">2015-02-20 13:44 GMT+01:00 Vincent de Phily <span dir="ltr"><<a href="mailto:vincent.dephily@mobile-devices.fr" target="_blank">vincent.dephily@mobile-devices.fr</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thursday 19 February 2015 18:43:26 Vincent de Phily wrote:<br>
> On Thursday 22 January 2015 21:45:08 Ingela Andin wrote:<br>
</span><span class="">> > If you want to handle<br>
> > incorrect clients by building the chain to the client certificate on the<br>
> > server side , if possible, you need to do that in the verify_fun when it<br>
> > fails and then call public_key:pkix_path_validation again with the chain<br>
> > that you built.<br>
><br>
> I didn't try this yet, but I verified that<br>
><br>
> > {partial_chain, fun(CAs) -> {trusted_ca,hd(CAs)} end}<br>
><br>
> "solves" my issue but is basically a verify_none. It seems there's some<br>
> functionality overlap between partial_chain and verify_fun, but I'm not 100%<br>
> sure when to use which.<br>
<br>
</span>FWIW, I managed to get the behaviour I expect (can you spot a bug ?) using<br>
either verify_fun or partial_chain:<br>
<br>
Verif = fun(Cert,{bad_cert, _}, _) -><br>
case public_key:pkix_path_validation(TrustedCA,[Cert],[]) of<br>
{ok, _} -> {valid, P};<br>
{error, Reason} -> {fail, Reason}<br>
end;<br>
(_, {extension, Ex}, _) -><br>
{unknown, []};<br>
(_, valid, _) -><br>
{valid, []};<br>
(_, valid_peer, _) -><br>
{valid, []}<br>
end,<br></blockquote><div><br></div><div><br></div><div>I would match on the unknown_ca atom too. </div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Partial = fun(Chain) -><br>
case public_key:pkix_path_validation(TrustedCA,Chain,[]) of<br>
{ok, _} -> {trusted_ca,hd(Chain)};<br>
{error, Reason} -> Reason<br>
end<br>
end,<br>
<br>
Connecting with<br>
{fail_if_no_peer_cert, true},<br>
{verify, verify_peer},<br>
{cert, MyCert},<br>
{key, MyKey},<br>
{cacerts, [TrustedCA]}<br>
and either<br>
{verify_fun, {Verif,[]}}<br>
or<br>
{partial_chain, Partial}<br>
Same config for both the client and the server, only the values of TrustedCA<br>
and MyCert/MyKey change.<br>
<br>
At this stage, I'm still unsure wether using verify_fun or partial_chain makes<br>
more sense (or is faster).<br>
<span class=""><br></span></blockquote><div><br></div><div><br></div><div>There is a semantical difference, the verify_fun is for customising the X509-certificate path validation,</div><div>the partial chain option is for disregarding certs higher up in the chain, see also below.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
> I'd like OTP to do the "peer-sent cert chain is signed by one of the localy-<br>
> trusted CAs" step for me. I realize that I could do it myself using the<br>
> public_key module, but I find it very surprising that my usecase would be<br>
> so unusual that it isn't supported out of the box. A peer that sends the<br>
> smallest chain that can be verified by the other peer isn't "incorrect".<br>
<br></span></blockquote><div><br></div><div>Sending only the peer certificate and not sending intermediate CAs </div><div>breaks the TLS protocol, I would not call it correct. </div><div><br></div><div>The partial chain option was introduced to let you skip validation steps of CAs that you do not care about. If you get a chain Root --> A -> B -> C -> Peer </div><div>and you for some reason have decided that you trust B you can run the path_validation algorithm with B as trusted ( B becomes the root in practice). In the partial chain</div><div>fun you are responsible to check that the cert you select as root is one that you trust. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
</span>These concerns are still valid. If feels strange that my version of verify_fun<br>
does something different than OTP's version.<br><br></blockquote><div><br></div><div>Why is that strange? The verify_fun is there so that you can customise your verification. This of course gives you some responsibility too, of getting it right!</div><div>You can both add application specific checks and change the default behaviour any way you like, and of course take the consequences of doing so.</div><div><br></div><div><br></div></div>Regards Ingela Erlang/OTP Team - Ericsson AB</div></div>