<div>Hi all,</div>
<div> </div>
<div>Interesting discussion :)<br> </div>
<div><span class="gmail_quote">On 10/10/05, <b class="gmail_sendername">Greger V. Teigre</b> <<a href="mailto:greger@teigre.com">greger@teigre.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">>From that perspective, you would probably only allow From domains that are<br>found in the CN and alternative names of the certificate of server A.
<br><br>I don't think this is a general matter (finding what is "correct"), but more<br>about the policies you implement (or level of integrity checks you want to<br>enforce). Do you allow the certificate of the sender to deviate
<br>(domain-wise) from the domain of the proxy? If you have multiple proxies<br>between you and the sender and you trust the proxy, you probably will allow<br>it. If you are peering with a proxy and only want to allow that proxy's
<br>users, you probable disallow it.</blockquote>
<div> </div>
<div>I would agree with greger that the authentication you need depends on the local policy. For that, ser needs to provide flexible mechanism as i don't think there is a one-fits-all. </div>
<div>As it is now, the current tls code does not really allow for flexibility, i would say. How about creating some kind of module that would allow in-depth access to tls functions, such as </div>
<div>- tls_verify_peer_cert()</div>
<div>- tls_check_from()</div>
<div>- tls_check_to()</div>
<div>.....</div>
<div>This way a barebones connection may be accepted on the tls level (say, just server authentication). Then, in the config file you may be able to stiffen the authentication requirements with a bunch of functionalities provided by a tls_tools module.
</div>
<div> </div>
<div>Regards,</div>
<div> </div>
<div>Cesc</div>
<div> </div>
<div> </div>
<div> </div>
<div> </div><br> </div>