Seems like you are asking 2 questions:
Is there any benefit to having the end entity certificate have a larger key space than the CAs in the signing chain
I agree with other posters that the result is mixed - but I want to break it down into the typical security features:
- Confidentiality - if you are using the end entity key pair for confidentiality (key encryption during SSL setup, encryption of data for storage or transmission) - then you are getting the benefit of the larger key regardless of what the CA signer is doing. Breaking your encryption is entirely related to finding your private key (or finding a weakness in algorithm)
- Integrity - if you are using the end entity key pair for signing data, then cracking your signature is linked to the strength of you key. However, integrity checks are often combined with authentication checks - see below.
Authentication - here's the rub. Your authentication/non-repudiation abilities become diminished if your CA's private key is easier to guess. If I can find your CA's private key due to the smaller key space, then I can pretend to be your CA and I can make a certificate and key pair of any size that looks like you and has a key pair that I control. That pretty much shoots authentication in the foot. It won't be caught by a list of trusted CA certs because the attacker will emulating one of those configured, trusted certs. And it will be hard to detect until after the break in is found. Also, revoking a CA is painful. Either you should have a certificate status check in place in every consuming system that checks the status of both the end entity and the CA chain, or you must revoke every valid end entity that was issued by the CA. This gets even harder if we are talking about a small key space in a self-signed root certificate. There is no way to status check the root. The CA system would have to issue a huge public warning and have any relying party remove the root and all it's sub CAs from their trusted stores.
Availability - when I think about availability in PKI, I think about use of PKI for authentication/access control to make the services available only to the privileged users. In that light, availability is shot just as much as authentication.
So, the summary - what are you using the certificate for? If you are only using it for confidentiality and pure integrity - you're not so badly off. But keep in mind the frequently, PKI protection mechanisms mix these categories. SSL client or server auth is both a way to set up a secure channel (confidentiality) and a way to vet the identity of the server (authentication). Email signatures are both a way to tamper proof the transmission (integrity) and a proof that the transmission came from the sender (authentication). It gets hairy awfully quickly.
Is it beneficial or even possible to have my end entity be of a longer validity than the CA that issued it?
In the PKI systems I've worked on - no absolutely not - end entity certificates cannot be issued as a longer validity period than the life of the CA certificate.
Stepping back from actual experience, however, I'm looking at the RFC for X509 Certificates:
Section 6.1.3 Basic Certificate Processing
includes the verification of validity dates for each certificate in the chain.
This section is part of:
6.1 Basic Path Validation
This text describes an algorithm for X.509 path processing. A
conformant implementation MUST include an X.509 path processing
procedure that is functionally equivalent to the external behavior of
this algorithm. However, support for some of the certificate
extensions processed in this algorithm are OPTIONAL for compliant
implementations. Clients that do not support these extensions MAY
omit the corresponding steps in the path validation algorithm.
So it should be done for every certificate in the path (ie, the end entity, every signing CA and the Root)
Validity checks are not an OPTIONAL extension, they are required part of the certificate.
IF the system is doing path validation correctly, having a longer validity on end entity certificate should do you no good. I didn't look farther to see if it's allowed. I believe the CA systems I've tested have had a setting that disallowed this, but I also think that with some degree of creativity I may have been able to generate a cert that broke this mould. Keep in mind, however, I was doing that with sys admin privilege and possibly even white box testing mechanisms that shouldn't be available in a hardened CA. I was also doing that 10+ years ago with CAs that are no longer the market today - mileage may vary.