regex 'fun'

[Alexander Clouter]

Stefan Winter <stefan.winter at restena.lu> wrote:
> 
>> So, 'eduroam-ca.der' can be a *group* of Root CA's I hope and there is a 
>> way to make sure that when the original CA reaches it's end of life you 
>> get *all* the sysadmins involved to update it to have the two CA's for a 
>> while and then on a 'd-day' to remove the old one?
>>   
> 
> The current plans in eduroam do indeed foresee a group of CAs: one for
> each National Research Network that's willing to operate its own, and a
> catch-all CA for the rest. All of which have individual rollover dates.
> And have their own CRLs which need to be re-loaded regularly (which
> means that there is no one D-Day). Sounds dreadful to you? Simple: a
> repository with CAs and CRLs and a cron job to fetch the current state
> once per day or so, and a HUP to pick it up. Nothing a server operator
> should be afraid of.
>
Consider myself 'slapped down'.
 
>> Kinda my point is there is no reason why the bar could not be lowered 
>> further.  The DNS idea was a hair brained idea of mine and I think it is 
>> crazy enough to work...plus it is using the *existing* infrastructure; 
>> plus finally admitting that edroam is *not* something that can be 
>> wholely accepted by an RFC...it is an exception.
>>
>> This is obviously turning into an Alex v's World argument. :-/
> 
> We've spent tremendous amounts of thinking and taxpayer money to think
> about this. Without knowing your own flavour of DNS idea: how do you
> solve the following:
> 
> - eduroam is for educational use only
> - microsoft.com sets up a RADIUS server and enters a DNS record for it
> - eduroam hotspot gets a user login from microsoft.com, looks up server,
> authenticates, user uses network
> - damn, we just allowed a commercial user into our network and violated
> our own AUP and national regulations orders!
> 
> We think PKI (and certificates that hold accreditation info) comes to
> the rescue. What rescues you?
>
What I was touting privately to Alan involved maintaining a zone file, 
akin to what you promoted in you dyndiscovery draft[1] but for for a 
custom 'root' server list.

I compared the PKI approach to mutex locking.  Sure you can use it, but 
the proper way to do things is to build an algorithm that remove the 
need for mutex's.  You dyndiscovery draft touts a PKIless world and 
thats a *good* thing.

None of this matters anyway.

>> RADSEC with the PKI instructure eduroam is touting is a ticking time 
>> bomb and knowing the educational world they are going to notice this 
>> international trust network and want to shovel their own cruft over it 
>> too.  When d-day arrives, it is going to break hard....the ides of March 
>> I tell you the ides of March.
> 
> Without a specific D-Day, your statement above loses much of its sense.
> 
Indeed it does.

Cheers

[1] http://www.ietf.org/id/draft-ietf-radext-dynamic-discovery-01.txt 

-- 
Alexander Clouter
.sigmonster says: Robot, n.:
                  	University administrator.