Hi.

I realized that we've been coordinating a number of development and
maintenance projects that are inter-related and that will have
significant affects on the overall system and I'm not sure we've written
it up anywhere.

* We're upgrading to Freeradius 3.0.4.  This is a bigger deal than it
  might otherwise be because we're significantly reducing the amount of
  patches to Freeradius that we need.

Unless the 3.0.4 release is later than I expect, it won't include the
RP-side trustrouter integration in the upstream.  So we will still
produce a 3.0.4 release.  However, this may be the last version where
you need to use our code for moonshot-related Freeradius. 


* We're finishing constraint support in the trust router and
  Freeradius.  Se the hartmans/tr-constraints branch on the trust router
  repository for a work in progress.

This means we'll actually store the constraints in the keys database.
We'll provide a default unlang policy to validate them  and to do
channel binding checks based on them.

As a result the keys database schema will change.  So we'll probably ask
people to delete their keys database.  That kind of breaks things, but
see below:

* We're working to add support to Freeradius (presumably not in the
  upstream 3.0.4 release but hopefully in 3.0.5) for key recovery.  The
  idea is that if trustrouter is used to select a realm  and SSL
  negotiation fails in a way consistent with an unknown PSK identity,
  and it has been a sufficient time since we acquired the key, then
  we'll try trustrouter again.
This will reduce the impact of people deleting their keys database.

* Prior to Alan integrating the trustrouter code we'd like to see some
  improvements made in it that we're working on.  Currently, only one
  COI can be used within an RP.  We'd prefer per-radius-client COI
  support.  Which means we need to keep track of the trustrouter coi in
  how we do the realm lookup.  So, something like internally store it as
  coi%realm or something like that, all managed under the covers inside
  the trustrouter module.  We also need to avoid using unstable data
  structures from the trustrouter APi in the freeradius code.

* We have a pending release of mech_eap to support CA-based trust
  anchors to facilitate trust anchor key rollover.  We may also start
  moving towards more strict channel binding support in that release.

All this is coming together this July.
It will bring significant security enhancements, as well as enabling
better stability and robustness in terms of code, deployment and ongoing
development process.

The maintenance projects are also critical for a managed IDP and RP
service we're putting together for JANET.

--Sam