<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Feb 19, 2016 at 2:49 PM Paul B. Henson <<a href="mailto:henson@cpp.edu">henson@cpp.edu</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The proxy callback URL can be any arbitrary server?</blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I thought it had to be a URL in the namespace of the service?</blockquote><div><br></div><div>There's no CAS server implementation I'm aware of that enforces that kind of constraint.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So if you are using the default Java CA list you are just trusting nobody would be able to convince a CA to issue an unauthorized certificate for <a href="http://some.server.com" rel="noreferrer" target="_blank">some.server.com</a>?</blockquote><div><br></div><div>I'm concerned about Verisign, for example, credentialing a perfectly legitimate domain owner in Kerbleckistan that is up to no good. When you use the default Java trust store, you're saying you trust all the major commercial CAs to issue certs to any legitimate domain owner on the Web. After all, that's the job of a commercial CA, to vend as many certs as possible. That's obviously not what you want in this case.</div><div><br></div><div>Hope that helps,</div><div>M<a href="mailto:users-unsubscribe@shibboleth.net" target="_blank"></a><br>
</div><div><br></div></div></div>