I understand your point of view. The DNS attack we are trying to mitigate with this protection is very unlikely. So this extra check should not be enabled by default, but maybe only for some very few super critical services. That way, the burdeon of certificates management would not be a real issue.
Thus, I tend to think that having the same check than for proxy callback would be good for (code) consistency ! For this proposal (SEC_6), I noticed also that it doesn't make sense to have it if we don't have SEC_5 : if we have a default truststore (a lot of certificates are consequently trusted), so a certificate check is not very useful. And if we don't have SEC_5, SEC_4 becomes more useful : if we have a default truststore (a lot of certificates are consequently trusted), an url check on the proxy callback url is more useful. I hope things are getting clearer... 2013/9/6 Marvin S. Addison <marvin.addi...@gmail.com> > why can't we just >> import the certificate of the client application for a SSL check from >> the CAS server to the client application ? To avoid of course that the >> CAS server trusts all certificates certified by Verisign or another >> certification entity... >> > > That would be an acceptable solution with respect to security. From an > operational standpoint, it seems as untenable as managing keys for each > peer. The vast majority of certificates expire annually or biannually, > which would require substantial communication and maintenance costs for a > non-trivial deployment. In practice no one does certificate trust on a > per-certificate basis for this reason. > > You might consider a facility like Shibboleth metadata where each service > is responsible for maintaining its own certificate or other data needed to > provide strong identity assurance. That scales much better by distributing > the maintenance burden among N peers. On balance it's probably more work > than what would be feasible for the 4.0 release. > > M > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > lel...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/**display/JSG/cas-dev<http://www.ja-sig.org/wiki/display/JSG/cas-dev> > -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
