Re: [TLS] [pkix] Possible revocation delay issue with TLS stapling

["Miller, Timothy J." <[e-mail]>]

A possible 'fix' to the revocation window problem has always been shorter certificate validity periods.  This has its own costs.

IMHO, however, timeliness revocation isn't the problem.  Experience with real world PKIs shows that sometimes revocation simply doesn't happen.  The CA may not be available, the incident may never get reported, or the system may simply fail in any of a dozen different ways up to and including lost database transactions.  Don't think it doesn't happen.

In short, relying on revocation to deny access may not be a good idea, at least for some systems.  Since the usual goal of authentication is to enable authorization, it can be safer to rely on the authorization system--i.e., revoke the account, remove the account's privileges, or invalidate the mapping between the shouldn't-be-used-any-more key and the account.  This is where X.509 gets in trouble; X.509 binds keys to names, and names are strongly (and naturally) mapped to accounts, so under X.509 the ways in which an authorization system can break the key-to-account mapping are very limited.  (The alternative--binding names to keys--has it's own set of problems, naturally.  They're different from X.509's, though.)

Either way, PKI authentication isn't enough by itself.  You need an equivalent authorization infrastructure to really make things work.

-- Tim


>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf Of
>Nicolas Williams
>Sent: Friday, March 26, 2010 1:17 PM
>To: Yngve N. Pettersen
>Cc: [e-mail]; [e-mail]
>Subject: Re: [pkix] [TLS] Possible revocation delay issue with TLS
>stapling
>
>[Why not pile on?  I think there's an angle not covered.]
>
>As others have pointed out this is nothing new, nor special about OCSP
>versus CRLs, and they have pointed out the workaround for RPs that care.
>
>The more interesting point, I think, is that instantaneous revocation is
>like password synchronization: hard.  You can get down to a window of
>minutes.  But instantaneous revocation?  I don't believe that's feasible
>in real world deployments.  Also, revoking certs is not enough if you
>want instantaneous revocation!  You'd also want to slam existing
>connections, and yet we have no protocol for doing that.
>
>However, quick revocation has much higher costs than quick password
>synchronization.  That's because making it possible to revoke certs
>quickly means making more frequent use of online infrastructure, and
>more frequent validation of signatures, whereas with password synch you
>need only push changes as quickly as possible to a relatively few
>servers.  Nowadays that extra cost may be in the noise, but it's not
>nothing, and it's the reason that we have the ability to have OCSP
>responses without nonces.
>
>Think of OCSP as a Kerberos-like ticketing facility, with certs+OCSP
>being like TGTs with long renewable lifetimes (corresponding to the
>certs' notAfter) but short lifetimes (corresponding to OCSP response
>freshness requirements / nextUpdate).  If you care about quick
>revocation then you can just tune down the OCSP response freshness
>requirements such that they fall within a time window whose size is
>comparable to the time needed for revocation notices to reach all the
>relevant OCSP responders.  The trick is to find just the right setting.
>
>Nico
>--
>_______________________________________________
>pkix mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/pkix