Assurance

[Ian Young <>]

> On 7/20/12 4:11 PM, "Tom Scavo" 
> <>
>  wrote:
>> We already have a policy that states IdPs "SHOULD generate a new private
>> key and submit a certificate with a new public key every 3 years."
>> (https://spaces.internet2.edu/x/boY0). Enforcing this policy at the time
>> of certification doesn't seem too unreasonable. What do others think?

As a matter of interest, does anyone remember where that particular term 
recommendation come from?  Is there some specific line of reasoning here 
about length of time a key should be in use, or is it just an arbitrary 
compromise between the undeniably true "shorter cryptoperiods reduce risks" 
vs. the hassle of key update?


On 20 Jul 2012, at 21:17, Cantor, Scott wrote:

> I think one of the reasons we haven't even tried to revisit that SHOULD is
> that we don't know what the real need is, and it's a complete nightmare to
> do it.

We see a lot of key rollover in the UK federation, because most of our IdPs 
have always used short-lived commercial certificates for trust fabric use 
(albeit, more recently, Comodo ones through the TERENA deal).  The main 
reason for that has been an inability of some of our SPs to accept 
self-signed trust fabric certificates.  We're down to just one or two of 
those now, so we're beginning to see a slow drift towards long-lived 
self-signed certificates for IdPs.

Just to balance that out and prove that the universe isn't prepared to give 
anyone a break, we also have a lot of SPs which handle multiple trust fabric 
certificates in metadata badly.  So, yes, every time anyone replaces a 
certificate they lose connectivity to some SPs during the transition.  It's a 
huge pain for everyone and it costs the helpdesk a lot of time sorting out, 
because the IdP people don't tend to be expecting it and often can't figure 
out what has gone wrong.

        -- Ian

Attachment: smime.p7s
Description: S/MIME cryptographic signature