On 29 Sep 2009, at 08:03, Alistair Young wrote:

> just a wee q about certs in the fed. I've just heard JANET are  
> moving to Comodo and all certs issued under the existing scheme with  
> GobalSign will be revoked next April, no matter what their  
> expiration date is. Will Comodo certs work ok in the federation?

Now that JANET's plans for the successor to the first generation SCS  
have been finalised, and made public in the SCS announcement made  
yesterday, I can provide a summary of where I think everything  
stands.  This isn't an official statement on behalf of anyone, just my  
personal summary...

The original TERENA SCS deal had a fixed duration, and it was part of  
that original contract that the certificates issued under the deal  
would be revoked at its expiry independently of their stated  
validity.  If you think about it, this does make some sense given that  
running the service of allowing people whose keys are compromised to  
selectively revoke the associated certificate costs money, and there  
is no ongoing revenue for GlobalSign post termination under which that  
would be funded.  However, in retrospect everyone feels that this  
wasn't the best part of the original deal and my understanding is that  
the second generation deal with Comodo is better in this respect.

For browser-facing certificates (those at IdP SSO locations and at SP  
assertion consumer service locations) this means that browsers will  
start whining after the mass revocation occurs, always assuming that  
users have their browsers configured to check certificate revocation  
lists.  Realistically, this means that all browser-facing certificates  
issued under the original SCS deal will need to be replaced before 9  
April 2010.  I would recommend that people work to replace these much  
earlier to avoid the rush... there are a *lot* of certificates (many  
thousands) affected by this change (most used for things other than UK  
federation entities), and if people leave things too late they may  
find the system is overwhelmed.

The second part of the question is the use of SCS certificates within  
the UK federation, which is to say their use as what I'd call trust  
fabric certificates.  This requires a bit more explanation, please  
bear with me and I'll try and ramble as little as possible...

In many cases at present, people use the same certificate for trust  
fabric purposes as they do for browser-facing purposes.  However, and  
despite what it says in our 2006 documentation (mea culpa, updates  
will appear once the dust has settled a little) the UK federation  
actually runs a quite complex hybrid trust fabric at present, and we  
work with members to do the best thing in each case.  This will have  
been particularly obvious to anyone using Shibboleth 2 or other  
current generation software.

Our original model for the UK federation's trust fabric was one  
mediated entirely by commercial CAs.  This meant, we believed, less  
work for everyone because only the common name of a certificate needed  
to be embedded in the metadata.  Many existing deployments have this  
kind of "PKIX only" metadata today.

The future, though, includes SAML 2 and cross-federation  
interoperation and these require direct embedding of key material in  
most cases.  That's most easily done by embedding X.509 certificates,  
although in this model the rest of the certificate has no function to  
perform so that the requirement to use specific CAs for trust fabric  
certificates is no longer present.  Indeed, long-lived self-signed  
certificates are the most obvious choice for use in such a "direct  
key" mode of operation.

The current federation metadata includes a fair number of direct key  
only entities, and a much larger number of entities whose metadata  
supports both PKIX and direct key validation modes.  Note that all of  
this is about the *metadata* and not about the *implementation*; with  
one small exception that we think will go away relatively soon, we  
think pretty much all software currently in operation within the UK  
federation can use either mode of operation.

The current plan for trust fabric certificates is to move away from  
the PKIX-only model towards the direct key model, which is to say  
towards the direct embedding of key material in your entity metadata  
in the form of X.509 certificates).  We do *not* at present plan to  
qualify the new SCS product for use with the federation, so that if  
you are using an existing SCS certificate as a trust fabric  
certificate then when you replace it you'll need to additionally talk  
to the federation helpdesk in order to add the appropriate elements.

In the short term, we'll be happy to accept essentially any valid  
certificate for embedding, including commercial CA certificates and  
SCS certificates from the new scheme.  This is one of the upsides of  
embedded key working: you have complete freedom of certificate  
supplier both on the browser-facing and trust fabric side.  However,  
embedding a CA certificate will normally mean renewing your metadata  
every couple of years, so in the longer term we will be strongly  
recommending the use of long-lived, self-signed certificates for this  
purpose.  This completely disconnects the federation trust fabric from  
the whims of any CA and given the experience we've had behind the  
scenes with some of the commercial CAs in the last few years I can  
tell you this is a very attractive prospect.

As an aside, note that the majority of PKIX-only sites at present are  
running Shibboleth 1.3, whose support lifetime ends not much later in  
2010 than the old SCS certificates expire.  A default installation of  
the Shibboleth 2.x software generates an appropriate long-lived self- 
signed certificate and this is automatically included in the generated  
metadata that you'd hand to the UK federation helpdesk to register the  
new entity. So we think these two transitions actually go together  
rather well.

I'm sure at this point at least person will be wondering whether  
moving away from CA-based certificates doesn't imply giving up some  
security, so let me lay that fear to rest.  The answer is that it does  
not imply this, because in the direct key model the issuer of the  
certificate is irrelevant and indeed ignored: the only thing that  
matters is that we are assured by the member that the certificate  
represents the genuine public key of the entity in question.  We  
assure this by performing telephone call-backs to verify the  
certificate's fingerprint.  In fact, because this model isn't subject  
to attacks on the weakest CA we have qualified, there's actually a  
small *increase* in security going down this route.

As I said at the start, this is a personal summary.  There will be a  
more formal statement to the federation technical contact list some  
time reasonably soon, and it may differ in detail... but I thought  
that as this was showing signs of being a hot topic for people that it  
was worth having some kind of baseline available quickly.

	-- Ian