Verisign silliness

[Brian Deacon]

On Thu, Jan 08, 2004 at 09:23:13AM -0800, David Lowenstein wrote:
> I just went to https://www.verisign.com. The cert expires in june of 2005
> and says it was issued in june of 2003.

The feeding frenzy of the half-informed has already begun on
slashdot... (Why do I keep reading that website?  I think it's the
same urge that makes me watch Cops.)

Verisign apparently has known about this for some time:
http://www.verisign.com/support/vendors/exp-gsid-ssl.html

I think I don't understand ssl certs completely.  My understanding was
that the chain of authority was written in stone.  A site's cert has
an expiration that will never change.  It is auth'd by a CA that has
an expiration that will never change.  'parently, though, you can
"update" your intermediate CA cert on your web server and everything
is honky dory.  But if the expiration of a particular CA cert is
mutable, then why would the web server need to be involved in updating
the CA cert's expiration date?  If the expiration date isn't
inherently part of the cert, then why would you need to update it when
it expires?  Just some kind of DNS'y distributed expiration doodly-bob
would work.  (Sorry to bust out the jargon.)

The other way 'round seems equally disturbing.  "Hi I am cert X and
you can trust me because cert Y says so."  Cert Y says, "I am cert Y
and you can trust me because Verisign says so."  And you trust
verisign because your browser trusted that root CA when it was born.
But if cert X says, "Just ask Cert Y" why should it be allowed to turn
around later and go, "Oh, cert Y is expired, well, umm, here, use this
one."  I thought the chain of authority was built into the certs... if
not, then couldn't any old cert pretend to be auth'd by anybody it
wants?  

Stop me when I make sense.  :)

B