Talk:Certificate revocation list

logically necessary. Necessary??

Matt, Actually, logically is not limited to mathematical relations. Rhetoric, one of the quadrivium (or was it trivium) was entirely, ahmm, rhetorical. Sorry about that. No I thought some about that phrasing and it should be retained as written, unless I got something conceptually wrong. I'm going back to look. ww 17:53, 17 Apr 2004 (UTC)

Of course "logically" is not limited to mathematics, but in a subject that straddles mathematics and pragmatic security (such as cryptography), writing "logically necessary" will appear to some readers that there is some mathematical result that implies the need, which is the exact opposite of what you wish to convey. — Matt 18:05, 17 Apr 2004 (UTC)

Matt, I don't see that implication is being made, but as you do something will have to change. I want to stress that there is an obligatory component to the necessity (lest you be a fool in your system design) and perhaps 'required' might be a reasonable choice of term. I'll go change it. ww 18:16, 17 Apr 2004 (UTC)

"Required" works, thanks — Matt 18:46, 17 Apr 2004 (UTC)

Matt, Thought we'd settled this as btw the two of us. What gives? ww 17:45, 19 Apr 2004 (UTC)

PKI / CRL subversion

Given that the CRL is signed by the CA's key, the problem of "subversion" as noted at the bottom of the article is really a non-issue. This key is "by definition" secure in a hierarchical PKI. Why mention subversion then? Yaronf 19:39, Apr 17, 2004 (UTC)

---

Yaronf, Given that some PKIs have been built w/o CRLs at all we can't assume rational design thought in the real world. Second, a subversion of the CA might yield a private key and so a test passing (suberted) CRL. Secure (and security analysis) dare not stop with 'by definition' cases. The real world doesn't necessarily follow the definition. Consider the Trusted Third Party or secure channel articles here, I've recently been over them in part to make this point (or something similar).

Comments? (<-- best on my talk page, I've not watchlisted this article).

ww 19:49, 17 Apr 2004 (UTC)

keep discussion here?

Actually, could I request that discussion about an article be held on the article's talk page? It provides a better record for future and current editors; Thanks! — Matt 19:53, 17 Apr 2004 (UTC)

Matt, I agree in principle, but the principle here is wider than this article or this edit discussion. As for keeping a record I'm all in favor of that, except when it is likely to not quite fit anywhere, and being, at least mostly, between two users, might not be particularly useful to others. And here we find me arguing on behalf of minimalism on talk pages, which is rather the reverse of the discussion going on at cleartext/plaintext. Go figure!

In addition, I think I'd be able to keep track of the threads a little better on a single venue. Ann I don't really like this editor mode much. Just now, it's not easy for me to prepare answers off line and paste them in. And, last, I think, there will be less distraction of yet another article to touch up, person to respond to and all that. So I can support a motion to go off WP for discussion, but....

Mayhap we could do it on our talk pages as Avindn and I did for a week or so before you appeared. Less satisfactory in some ways, but better than doing it here in my judgement.

ww 20:42, 17 Apr 2004 (UTC)

<<-- note that the above is a response to something else altogether, namely an invitation to Matt to discuss something off line made at another article all together. And thus we see a live example of losing the thread! ww 20:46, 17 Apr 2004 (UTC)

I agree that the discussion you mention (about general style) shouldn't clutter an individual article's page. However, surely your proposed discussion with Yaronf clearly belongs on this page? — Matt 20:54, 17 Apr 2004 (UTC)

Matt, Two points. First, the discussion I anticipate will not be devoted to this topic only, but to system design and expectations thereof and thereabout. Or at least I was expecting that it would be so. And thus would not be specific to this article. Otherwise, I would agree.

On the second point, the phrase person or persons unknown has a specific connotation I was trying for (though perhaps this is AE, not BE) and your edit loses that connotation. The substitution for must also loses a point I was trying for, namely that this is an obligatory aspect of competent PKI operation, not merely a possible one.

Comment?

(I don't understand "AE / BE".) What was the specific connotation you were trying for? — Matt 17:29, 18 Apr 2004 (UTC)

ww 16:51, 18 Apr 2004 (UTC)

Matt, American English/British English. As for the connotation, person or persons unknown conveys (at least here) a whiff of skulduggery, which applied in this case. Though I have heard of no untoward results, save embarrassement for the 'victims'. It was deserved for Microsoft for maldesign of their publisher certificate authentication system, and for VeriSign for being had, and secondarily for agreeing to participate in a maldesigned system. I think the phrase originates (and so the aroma does also) from that bland pseudo impressive officialese that we have so much of here. We call it Pentagonese as they are masters of it. By choosing this phrasing, I managed to avoid saying most of this, but apparently too sneakily.

It perhaps should be made explicit that this exploit took advantage of maldesign in the system (MS) and inadequate controls (VS). Comment?

ww 18:24, 18 Apr 2004 (UTC)

subversion con't

And now back to "subversion"... A well designed and well deployed PKI is very complex and very hard to subvert. It should employ:

• Software security, e.g. a software audit of the CA software.
• Operational security, e.g. manually approving each request to add a certificate to the CRL.
• Physical security (locking up the server room etc.)
• Network security: firewalls, IDS and so forth.

Putting a Microsoft CA on your home PC is certainly not a "real" PKI.

So I wouldn't talk blithely about subversion.

If you do want to subvert a PKI, there are dozens of easier ways to do it. If you get hold of a CA's private key, you're more likely to forge certificates (and use them for communication attacks) then to forge a CRL. Similarly, if you can bribe a CA operator. If all you want is a massive DoS attack, DNS attacks or NTP spoofing is a better bet than playing with the CRL.

Yaronf 08:58, Apr 19, 2004 (UTC)

Y, Your list is certainly true of well designed and well deployed. Such are regrettably less common than they should be.

As for 'very complex ==> very hard to subvert', I would suggest that experience suggests just the opposite. Complex designs are hard to get right, even if you're seriously trying and your development process is committed in various ways to getting it right. Certainly in software generally, and perhaps especially in crypto systems.

Agreed that there are easier ways to subvert, but that wasn't the point I was trying for. I was trying in instill in Our Reader (especially the non specialist reader -- the speialists should know better already) that mere provision of a CRL does not, in itself, sprinkle security dust over all, but that CRLs though logically necessary (sorry Matt) aren't enough.

No blith talk meant. Sorry if you perceived it that way. Can you suggest a way to deblith without doing damage to the intent?

ww 15:18, 19 Apr 2004 (UTC)

Point taken re: complexity. Should have said "employs multiple overlapping protection mechanisms".

To rephrase the "subvertion" sentence, how about: Still further [...] and all its users. Moreover, an attacker could violate the integrity of the CRL, just as other components of the PKI are subject to attack if not well protected. The result of such an attack would be a massive denial of service at best.

Yaron 22:01, Apr 25, 2004 (UTC)

Y, Just noticed your post. I agree with your 'should have said', but would note that even then there's no way to be certain that some weakness isn't still present.

As for the suggested change, I like it. I would change only 'subject to attack if not' to 'subject to attack. Even when well protected some attacks may succeed', or some such. I don't want a reader to be able to get the impression (however unwarrented) that 'well protected' is sufficient; that readers will take away any impression whatsoever, despite our best efforts at phrasing, is an unfortunate fact of writing/reading with current model humans on both ends. 'Spock never made such errors', why do we?

At present, we simply don't know wha to specify for protection that will turn out to be sufficient in practice. We might believe this to be sufficinet (or that), and bet our jobs on that belief, but it's nothing more than an opinion, and furthermore one that has a not so good track record of being regularly wrong. Anyway, will you go ahead and put it in? ww 17:54, 27 Apr 2004 (UTC)

Examples and more elaborated information needed

Im still not sure how and where CRLs are used.

1. If I go check my mail, and I see the padlock symbol in my browser, is the certificate of my mail provider then being checked against a CRL, obtained from the issuing CA? And if yes, when is this CRL retrieved, everytime I check my mail or just once a week or something?
2. Does every CA has its own CRL, that users can retrieve?
3. Does the CRL only contain the revoked or "hold" serial numbers? And how big would such a CRL typically be?
4. How long time is it between the "periodically" issued CRLs?
5. Is OCSP replacing CRLs, could it replace CRLs? Are there any advantages of CRLs over OSCP?

I think the article needs more specific information to give a true understanding of how this is used.

Velle 12:11, 20 August 2006 (UTC)

What is a "PKI-enabled application"?

What is a "PKI-enabled application" (term found in the article)? Im not sure, and if my guess is correct, this is a misleading word.

Velle 22:10, 20 August 2006 (UTC)

Workarounds?

The article says, "No comprehensive solution to these problems is known, though there are multiple workarounds for various aspects of it, some of which have proven acceptable in practice," but no examples of workarounds or details are provided. Either a summary of workarounds should be provided or a source needs to be referenced. --Sho222 15:05, 22 March 2007 (UTC)

Given that this has been tagged for verification since 2010, without support, claim deleted from text. Klbrain (talk) 07:03, 11 September 2018 (UTC)

Resolved

---

Why is the title of this article not "Certificate Revocation List"?

The redirect from the Certificate Revocation List page mentions something about generalization - if noone is going to provide a specific example of a "Revocation List" outside of standard X.508/RFC 5280 CRLs, then the ambiguous title is pointless.

VESGroup (talk) 05:13, 19 July 2016 (UTC)

Requested move 30 November 2016

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: moved per uncontested request below. also looking into the history of the target page, it was initially moved to the more generic term without the use of 'certificate' to make room for the inclusion of information regarding DRM, however that content isn't in the current article. Requested CSD#g6 to make room. (non-admin closure) Tiggerjay (talk) 19:09, 7 December 2016 (UTC)

---

Revocation list → Certificate revocation list – This term is used both in this article and in others linking to it as "certificate revocation list", and that is the common name. Mauls (talk) 11:40, 30 November 2016 (UTC)

---

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

CRL and non-browser scenarios

This article (and the corresponding Online Certificate Status Protocol article) could be improved by consideration of non-browser scenarios; including enterprise and Internet-of-things. I am hoping for improvements that could guide decision making, and provide pointers for common methods of solving the issues. I plan to help improve the CRL vs. OCSP comparisons, by including an explanation of the impact of different common scenarios (browser vs. IoT vs. enterprise). Also want to take into account implementation context for OCSP responders and CDP (CRL distribution point) implementations. — Preceding unsigned comment added by Trsm.mckay (talk • contribs) 19:39, 10 October 2019 (UTC)