Can a SSL certificate have longer validity period than its parent in X.509 chain?
This is an historically disputed point.
In the validation algorithm from RFC 5280 (that supersedes RFC 2459, by the way), there is no requirement of validity range nesting. However, some historical implementations have insisted on it; see for instance the X.509 style guide of Peter Gutmann:
Although this isn't specified in any standard, some software requires validity period nesting, in which the subject validity period lies inside the issuer validity period. Most software however performs simple pointwise checking in which it checks whether a cert chain is valid at a certain point in time (typically the current time). Maintaining the validity nesting requires that a certain amount of care be used in designing overlapping validity periods between successive generations of certificates in a hierarchy. Further complications arise when an existing CA is re-rooted or re-parented (for example a divisional CA is subordinated to a corporate CA).
The Microsoft PKI ("ADCS", aka Active Directory Certificate Services) enforces validity period nesting, in that, when it issues a certificate, it will not allow the end-of-validity date of that certificate to exceed that of the current CA certificate (in effect, truncating the validity period mandated by the template if it would lead to such a situation).
Even though, when renewing a CA certificate, it is possible to keep the same CA name and CA key, in which case both the old and new CA certificates can be used interchangeably as long as neither is expired, on EE certificates issued both before and after the renewal. That is, if the old CA certificate is CA1, the new one is CA2, certificate EE1 was issued before the renewal and certificate EE2 was issued after, then CA1->EE1, CA1->EE2, CA2->EE1 and CA2->EE2 should all validate; this is very convenient to ensure smooth transitions. While the validity period nesting implies that CA1->EE1 and CA2->EE2 will nest, CA1->EE2 and CA2->EE1 might not nest -- and this is fine.
Summary: you cannot rely on validity period nesting, and you should not try to enforce nesting when validating certificates.
Hmm, I agree that I would have expected to find this info in RFC 5280 4.1.2.5. Validity. (By the way, RFC 5280 obsoletes RFC 3280, which obsoletes RFC 2459, so you really shouldn't be looking at 2459 any more).
That said, you can figure this one out logically (at least for a standard TLS-like setting): When an end-user validates a cert, they have to follow the chain up to the root, ensuring that every cert along the way is valid. Let's say that X2 expires before X1 (and assume that X2 was the issuer for X1). Once X2 expires, X1 is as good as useless since there is no way to build a validation chain from X1 to Xn.
Here's a case where a CA might issue certs with a longer lifetime than the root: requirements state that A) All leaf certs must have a lifetime of 3 years (say they're going into embedded devices) B) All leaf-certs must be issued off the same root (say you only have space to pin one root). Now, the CA cert will expire in 2 years, and within that time you plan to issue a new CA cert for the same CA key. In that case there's no problem issuing a 3 year leaf-cert off a 2 year root.
The question you're asking is a little vague as to whether you're looking for the CA / issuer to enforce the "validity nesting" rule, or for the client / verifier to enforce it.
If you are the CA / Issuer:: it is up to you. There are many CAs that will not issue a cert with a longer lifetime than themself. That said, I can imagine scenarios in which might want to do this.
If you are the Client / Verifier: I don't think it gains you anything to be strict about this. You are intentionally causing compatibility problems between your client and CAs that don't follow "validity nesting" ... for what gain? _(assuming that all certs in the chain have to be within their validity period at the time of validation, I suppose this is what you are calling "standard validation" in your comment).