Shibboleth Developers

["RL 'Bob' Morgan" <>]

On Fri, 6 Jun 2003 

 wrote:

> I guess there's a lesson in here for InCommon, about how much testing
> is required when *any* changes are made to the trust file...
>
> So, just to confirm......
>
> -- if we remove the duplicate RSA cert from the trust.xml file... and
> rebuild the tarballs... that's all that's required?

Removing the dup permits the current target to work.

Putting in Derek's patch would (I believe) permit the target to work even
if the dup were still in there, which is appropriate.

I suggest that we also make the validation work in general such that it
tries all applicable certs/keys before giving up, rather than stopping
upon name-match-but-failure-to-validate.  I imagine that was Scott's
intention.

So yeah, the validation needs to be resilient to at least some dumb
mistakes in setting up the trust.xml file ...

We still need to test the chained-validation case, with the HEPKI/bossie
certs.  Hmm, I just set up perq to have only the HEPKI Master CA in its
trust.xml (for incommon:pilot) and the UW origin on
shib.cac.washington.edu to use its HEPKI cert/key, and ... got a shar
segfault ... but others could test with the UW origin.

Gotta run now, and in stupid meetings most of the day ...

 - RL "Bob"


------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

    http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--