I was at my College Security Lesson, the professor said that Certificate Revocation Lists (CRLs) violate some of the Secure Design principles.
Secure Design Principles:

  • Fail-Safe Defaults
  • Economy of Mechanism
  • Complete Mediation
  • Open Design
  • Separation of Privilege
  • Least Common Mechanism
  • Psychological Acceptability

I can't really face this thing!

Which Secure Design principles are violated with the use of CRLs? Why?

  • 1
    $\begingroup$ Can you post a short, one-sentence description of each of those principles? $\endgroup$
    – mikeazo
    Apr 25 '18 at 15:43
  • 2
    $\begingroup$ I'd venture a guess and say fail-safe defaults? If your connection fails and you cannot access the CRL, what do you do? Fail-Safe would mean rejecting all certificates. (I'm pretty sure most implementations will fail deadly and accept everything.) But I agree with mikeazo, not all of those are immediately clear. $\endgroup$
    – Maeher
    Apr 25 '18 at 18:19

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!


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.