OK, let's go over them:
- Fail-Safe Defaults: this is the most important one, as a CRL doesn't provide on-line information and may not be available or out-of-date;
- Economy of Mechanism: a CRL may contain information about many certificates, so the mechanism isn't as economic as it could be;
- Complete Mediation: CRL's are public info while complete mediation is about access control and therefore this rule is not applicable;
- Open Design: well, CRL's are an open standard as well - as part of X.509 and the derived RFCs, so it complies;
- Separation of Privilege: privilege separation is not on topic here, both CRL's and OCSP's are generally performed by the same entity;
- Least Common Mechanism: possibly the ASN.1 parser is shared with the X.509 certificate, but if the ASN.1 parser of the certificate is broken then you're already in trouble, I don't see how it applies here;
- Psychological Acceptability: I guess nobody complains if certificate is refused because of a CRL and certainly nobody complains if it isn't, so this isn't really applicable.
Note that OCSP - the online certificate status protocol - does provide a positive way of knowing if a certificate is valid at that time or not. However, you still face the same issue if the OCSP server cannot be reached. Generally the certificate should not be accepted, but this is often configurable. Besides that, OCSP requires a higher availability of the service.
I'd hazard that the private key could be known to be exposed while the CRL is still valid is the biggest issue; without an online protocol it certainly doesn't comply fully with Fail-Safe Defaults.
However, your professor should not leave you guessing; ask your professor what was meant!