Menu
▾
▴
Re: [Ejbca-develop] why expired certificate is not in CRL list
|
From: Massimiliano Z. <mas...@gm...> - 2011-07-15 08:08:55
|
Hi Anders/Arshad. You are both right, but that is not the point. We weren't talking about what was better/worse: I completely agree with you that OCSP is much better and that CADES-C would be much better than CRL with expired certificates. We were talking about WHY a CA software should support the expired certificate retention feature. The reasons are: 1) Even if CADES-C and other proposals exists to locally store the CRLs, there are no much (any?) verifier that supports them 2) It would solve the long life signature verification issue very easily 3) Some government regulation (italian) imposes that. At the moment, for example. EJBCA can't be used in Italy for qualified CA 4) The HUGE crl problem is solved using partitioned CRL. 5) There's no reason to not giving one the choice to choose if keep or remove expired certificates. About the problem that 'a ca can't exists forever' : this is another problem. In the event that the CA do not exists anymore at the time of the verification, the first problem one shoud solve is how to demonstrate that the CA that released the certificate is a qualified CA. That brings to many other serious problems unrelated to the CRL verification issue. Regards, Massimiliano On Thu, Jul 14, 2011 at 21:14, Arshad Noor <ars...@st...>wrote: > In addition to the comments that Anders makes - which I concur with - > there is another practical problem. A PKI with a certification > practice that issues a CRL every day (yes, there are some of them) > and millions of certificates will find itself dealing with an > unmanageable CRL size after even a small percentage of certificates > are revoked. This can create significant performance problems for > everyone. > > Take a look at these CRLs from the US DOD PKI; they are 23M and 28M > in size each, respectively. I'm not even sure whether it includes > expired certificates are not (I think not because to the best of my > knowledge, the software that runs their PKI did not support the > feature to keep expired certs on the CRL - I'm not sure if it does > now): > > http://crl.disa.mil/getcrl?DOD CA-19 > http://crl.disa.mil/getcrl?DOD CA-20 > > Arshad Noor > StrongAuth, Inc. > > P.S. One might ask why the DOD did not implement an OCSP responder; > it does. But, there are many software products that do not know how > to use/call an OCSP service - they still need CRLs. > > On 07/14/2011 01:23 AM, ejbca-support wrote: > > On 2011-07-14 09:40, Massimiliano Ziccardi wrote: > >> Technically speaking you are right: saving the CRL in some place one > could always be able to verify the signature. > >> > >> However, a standard way to perform such verification would be advisable. > >> > >> The only standard I'm aware of for saving CRL (or OCSP responses) so > that the signature can be verified by a generic verifier is CADES-C. > >> > >> However: are you aware of any verifier that implements such standard? > I'm not. > >> > >> It would be much simpler to perform the usual verification step: online > CRL verification. > > > > <notreallyejbcasupport> > > Although this is a slightly "political" discussion, I think it would be > rather > > short-sighted building on the hope/assumption that the CA is alive > forever. > > > > A better way dealing with signatures is doing traditional verification > > during *receival* of the document/message and store both the content and > > CRL/OSCP response in an archive. Finding out 20 years from now that > > the signature was incorrect doesn't seem like a useful scheme. > > > > A timestamp for the receival could also be nice. > > > > It should be simple picking up a CRL from the archive in the extremely > > rare condition you suspect the initial process was wrong. > > > > Without a "trusted archive" you get nowhere. > > > > There are standards for long-term archival of signed data for > > those who are worried that somebody within the government > > agency are breaking signatures using a 2040Y computer: > > > > http://datatracker.ietf.org/wg/ltans/charter > > > > </notreallyejbcasupport> > > > > Anders > > > >> > >> So, since the RFC do not mandates that CA softwares removes the expired > certificates from the CRL, keeping them would be the simplest, most > practical and standard way to solve the problem. > >> > >> This is the reason. > >> > >> So, I try to turn your question to you. > >> Many CA vendor allows to retain expired certificates on CRL, ALL the > verifier are able to perform online CRL verification, RFC allows to retain > expired certificates. > >> Why should I implement a proprietary way to check certificate validity > in time when I can get a simple solution out of the box without breaking any > standard nor any verifier? > >> > >> Regards, > >> Massimiliano > >> > >> > >> On Wed, Jul 13, 2011 at 18:34, Arshad Noor<ars...@st... > <mailto:ars...@st...>> wrote: > >> > >> Thanks for the citations, Massimiliano. > >> > >> While the texts tell me that the law requires expired certs in the > CRL, > >> and that the other CA provider supports a capability to include > expired > >> certs in the CRL, both the texts don't answer the question I have > about > >> this feature: > >> > >> Why? > >> > >> I still fail to see what a Relying Party gains from seeing an > expired > >> cert on the CRL when the two CRLs, immediately before and after the > >> signing time of the document, tell me what I need to know about the > >> validity of the certificate at the time of signing the document. > >> > >> Arshad Noor > >> StrongAuth, Inc. > >> > >> On 07/13/2011 01:03 AM, Massimiliano Ziccardi wrote: > >> > Hi Arshad. > >> > > >> > >There are lots of things that RFC 5280 does not prohibit, > Massimiliano. > >> > > >> > You are right, but, in this case, I think the RFC should be > fixed: every > >> > RFC uses the terms "MUST", "MUST NOT", etc to define > >> > undoubtedly what can or can't be used. > >> > In this case it should say something like: > >> > "The CRL MUST list all unexpired certificates...." > >> > and > >> > "The CRL MAY list revoked or suspended expired certificates" > >> > > >> > I didn't mention the software name we use because I didn't want > to > >> > publicize it here on another CA software mailing list ;-) > >> > > >> > I'll write you the CA name privately, however, to keep the > mailing list > >> > updated, I'll write below the CA documentation where the expired > >> > certificate retention is described. > >> > > >> > The software is able to manage both combined and partitioned > CRL: > >> > > >> > " > >> > 8x------------- > >> > Retaining expired certificates on combined > >> > CRLs > >> > If you use a combined CRL (see “Using a combined CRL” on page > 267), the > >> > combined CRL includes all certificates issued by the CA that > were > >> > revoked at the time > >> > the combined CRL was published. By default, when a revoked > certificate > >> > expires, > >> > xxxxxxxx will remove the certificate from the combined CRL the > next time > >> > xxxxxxxx checks the combined CRL for expired revocations (see > “Checking > >> > revocation lists for expired revocations” on page 254). > >> > > >> > ********** HERE IS THE IMPORTANT SECTION > >> > xxxxxxxx includes the advanced setting ExpiredOnCombinedCRL that > >> > controls how expired certificates are retained on the combined > CRL. > >> > > >> > 8x------------------ > >> > > >> > Retaining expired certificates on partitioned > >> > revocation lists > >> > xxxxxxxx maintains standardized, partitioned CRLs and ARLs at > unique CRL > >> > distribution points (CDPs) in the xxxxxxxx directory. The > partitioned > >> > revocation lists include all certificates issued by the CA that > were > >> > revoked at the time > >> > the revocation list was published. By default, when a revoked > >> > certificate expires, > >> > xxxxxxxx will remove the certificate from the partitioned > revocation > >> > list the > >> > next time xxxxxxxx checks the revocation list for expired > revocations (see > >> > “Checking revocation lists for expired revocations” on page > 254). > >> > > >> > ********** HERE IS THE IMPORTANT SECTION > >> > xxxxxxxx includes the advanced setting ExpiredOnPartitionRL that > >> > controls how expired certificates are retained on the > partitioned > >> > revocation lists. > >> > > >> > 8x------------------ > >> > " > >> > > >> > The text of the italian regulation can be found at > >> > > http://www.digitpa.gov.it/sites/default/files/normativa/Deliberazione_CNIPA_45_9_novembre_2009_GU_modificata%20dalla%20DT%2069_2010_0.pdf > >> > > >> > and the interesting paragraph is: > >> > > >> > " > >> > TITOLO VI > >> > INFORMAZIONI SULLA REVOCA E SOSPENSIONE DEI CERTIFICATI > >> > Art. 18 > >> > (Verifica dei certificati - CRL) > >> > > >> > .... > >> > 3. I certificati revocati o sospesi devono permanere nella CRL, > anche > >> > dopo la loro naturale > >> > scadenza, fino alla scadenza del relativo certificato di > certificazione. > >> > ..." > >> > > >> > In english (my free translation!!): > >> > > >> > " > >> > TITLE VI > >> > INFORMATION ABOUT REVOKING AND SUSPENDING CERTIFICATES > >> > Art. 18 > >> > (Certificate verification - CRL) > >> > > >> > ... > >> > 3. Revoked or suspended certificates must be retained inside the > CRL, > >> > even after their natural > >> > expiration date, until the expiration of the CA certificate. > >> > " > >> > > >> > Italian regulations mandates the signatures must follow the > CADES-BES or > >> > CADES-T specification, even for > >> > long life signatures. > >> > Moreover, it mandates that *every* verifier must be able to say > if the > >> > signature was valid at the time of the signature: this means > >> > that no 'proprietary' way to handle the CRL can be used. > >> > > >> > Since CADES-C is not mandatory, but verification is, the expired > >> > certification retention is the only solution to the problem. > >> > > >> > Regards, > >> > Massimiliano > >> > > >> > On Tue, Jul 12, 2011 at 18:07, Arshad Noor< > ars...@st...<mailto:ars...@st...> > >> > <mailto:ars...@st...<mailto: > ars...@st...>>> wrote: > >> > > >> > There are lots of things that RFC 5280 does not prohibit, > Massimiliano. > >> > That doesn't mean that it makes sense to include them in > certificates > >> > or CRLs. > >> > > >> > Any business that has a need to keep digitally signed > documents/objects > >> > for long periods must plan on storing the objects that I > mentioned so > >> > the verifier can always get to them even if the PKI is no > longer in > >> > operation (a very real possibility these days). The objects > can be > >> > easily maintained in databases, LDAP directories or just a > file-system > >> > with full path-names pointing to the objects. If the > signature and its > >> > verification is important to you, then having the minimum > number of > >> > artifacts with the minimum information in them to verify the > signature > >> > is a good design goal to have for any system. > >> > > >> > Keeping an expired certificate's revocation status on a CRL > forever > >> > serves no purpose if the certificate already tells me that > its validity > >> > period has ended. As long as the signature is within the > validity > >> > period, and as long as the CRL/OCSP-response immediately > before and > >> > after the signed object's time-stamp indicate that the > certificate was > >> > good, (and as long as all other cert-chain validity checks > are OK), > >> > there is nothing more I need, logically, to verify a > signature. > >> > > >> > Perhaps you can cite the specific sections of the Italian > law that > >> > explain why a CRL must preserve revoked certificate > information past > >> > their expiration date; it might help me understand the > rationale. Or > >> > even the other CA manufacturer's documentation that explains > why its > >> > needed. Thanks. > >> > > >> > Arshad Noor > >> > StrongAuth, Inc. > >> > > >> > On 07/12/2011 08:10 AM, Massimiliano Ziccardi wrote: > >> > > Hi Arshad. > >> > > > >> > > The RFC 5280 states the the CRL must contain the > 'unexpired > >> > > certificates' but do not mandates > >> > > that expired certificates MUST be removed. So, in my > knowledge, it > >> > > should be interpreted as: > >> > > 1) unexpired certificate MUST be kept on the CRL > >> > > 2) expired certificate MAY be kept on the CRL > >> > > > >> > > Infact there's no place in the RFC that says 'expired > >> > certificates MUST > >> > > be removed from the CRL'. > >> > > So, in my opinion, maintaing the expired certificates > inside the > >> > CRL is > >> > > fully compliant with the RFC. > >> > > > >> > > Moreover (correct me if I interpreted wrong), your > description of the > >> > > verification flow requires that > >> > > the verifier has the CRL available somewhere to perform > the > >> > > verification... but where? > >> > > > >> > > If EJBCA has an option to > 'keep-expired-certificate-on-crl', > >> > > it is superfluous. > >> > > > >> > > > >> > > I don't agree. I'm not sure EJBCA has that option, but > I'm sure other > >> > > commercial CA has (we use one of them for our qualified > CA) > >> > > > >> > > Regards, > >> > > Massimiliano > >> > > > >> > > On Tue, Jul 12, 2011 at 16:20, Arshad Noor > >> > <ars...@st...<mailto: > ars...@st...> <mailto:ars...@st...<mailto: > ars...@st...>> > >> > > <mailto:ars...@st...<mailto: > ars...@st...> > >> > <mailto:ars...@st...<mailto: > ars...@st...>>>> wrote: > >> > > > >> > > There is NEVER a need to list an expired certificate > on a CRL; > >> > > firstly, it would violate PKIX standards, and > secondly, it > >> > > would serve no logical purpose. > >> > > > >> > > Here is RFC 5280, Section 5: > >> > > > >> > > "A complete CRL lists all unexpired certificates, within > its scope, > >> > > that have been revoked for one of the revocation > reasons > >> > covered by > >> > > the CRL scope. A full and complete CRL lists > all unexpired > >> > > certificates issued by a CA that have been > revoked for > >> > any reason." > >> > > > >> > > The critical words in this section of the RFC are > "unexpired". > >> > > > >> > > Now, look at it from a logical point-of-view: > >> > > > >> > > > >> > > T0: ------ Certificate #1 validity start-date > >> > > | > >> > > | > >> > > T1: --- The first CRL issued BEFORE the signing > of a > >> > document; it > >> > > | may be an empty CRL as the > CA may not > >> > have > >> > > revoked any > >> > > | certificates yet > >> > > | > >> > > T2: --- Signed document > >> > > | > >> > > | > >> > > T3: --- Certificate #1 is revoked; CRL is issued > with > >> > certificate > >> > > | serial #1 listed in it > >> > > | > >> > > | > >> > > | > >> > > T4: --- Another CRL is issued with certificate > #2 > >> > revoked; but > >> > > | certificate #1 MUST still be > listed in it > >> > > | > >> > > | > >> > > | > >> > > T5: ------ Certificate #1 validity end-date > >> > > | > >> > > | > >> > > T6: --- Another CRL is issued with certificate > #3 > >> > revoked; but > >> > > certificate #1 is NO LONGER listed > in the > >> > CRL because > >> > > it has EXPIRED > >> > > > >> > > > >> > > All you need to validate the signed document (signed > at T3) > >> > at any time > >> > > is: > >> > > > >> > > 1) The digital signature blob (which includes a > time-stamp in > >> > it); > >> > > 2) The certificate of the signer; > >> > > 3) The certificate-chain of the issuing CAs; and > >> > > 4) The FIRST CRL (or OCSP response blob) issued > BEFORE and > >> > AFTER the > >> > > signing time (T1 and T3 in the above > example). > >> > > > >> > > From this, any software can determine the > validity of the > >> > signature at > >> > > T2. > >> > > > >> > > A) By checking the the validity date of the signing > >> > certificate, the > >> > > verifier can tell that the signature was > produced during the > >> > > validity > >> > > period; > >> > > > >> > > B) By checking the CRL issued BEFORE the > signing-time (T1), > >> > it can tell > >> > > that that the certificate was NOT revoked; > >> > > > >> > > C) By checking the CRL issued AFTER the signing time > (T3) it > >> > can tell > >> > > that the certificate was revoked. The CRL MUST > have the > >> > immediate > >> > > next sequential number from the same CA. > >> > > > >> > > From just this, it now knows that the certificate > was NOT > >> > revoked at > >> > > the signing-time (T2) and therefore the signature is > valid. > >> > > > >> > > Once the certificate validity expires, there is no > reason to > >> > keep the > >> > > expired certificate on the CRL because the verifier > software > >> > does not > >> > > need to see any CRL past the one issued at T3. > >> > > > >> > > If any verifier needs to see an expired certificate > in a CRL, > >> > that is > >> > > a bug. If EJBCA has an option to > >> > 'keep-expired-certificate-on-crl', > >> > > it is superfluous. > >> > > > >> > > Arshad Noor > >> > > StrongAuth, Inc. > >> > > > >> > > On 07/12/2011 01:45 AM, Massimiliano Ziccardi wrote: > >> > > > I agree with you, but I think that an > >> > > 'keep-expired-certificate-on-crl' > >> > > > option would be very useful, expecially for long life > signatures > >> > > (and, > >> > > > if I'm not wrong, EJBCA has such option). > >> > > > > >> > > > If I have a signed document with the > 'signature-timestamp-token', > >> > > than > >> > > > that means I could need to verify that the signature > is valid > >> > > even years > >> > > > after the certificate is expired: how can I perform > such > >> > operation if > >> > > > the new CRL do not contains expired certificates ? > >> > > > > >> > > > Embedding the CRL inside the signed document at the > moment of the > >> > > > signature is not an option: CRL could be very big > (even if they > >> > > usually > >> > > > are not). > >> > > > Moreover, at the moment I'm not aware of verifier > that handles such > >> > > > attribute. > >> > > > > >> > > > Italian regulations requires that expired > certificates remains > >> > inside > >> > > > the CRL. > >> > > > > >> > > > Regards, > >> > > > Massimiliano > >> > > > > >> > > > > >> > > > On Tue, Jul 12, 2011 at 05:18, Arshad Noor > >> > > <ars...@st...<mailto: > ars...@st...> <mailto:ars...@st...<mailto: > ars...@st...>> > >> > <mailto:ars...@st...<mailto: > ars...@st...> <mailto:ars...@st...<mailto: > ars...@st...>>> > >> > > > <mailto:ars...@st...<mailto: > ars...@st...> > >> > <mailto:ars...@st...<mailto: > ars...@st...>> > >> > > <mailto:ars...@st...<mailto: > ars...@st...> > >> > <mailto:ars...@st...<mailto: > ars...@st...>>>>> wrote: > >> > > > > >> > > > When you issue a digital certificate, it has a > natural > >> > lifetime. > >> > > > When the natural lifetime ends, the certificate > is > >> > considered to > >> > > > be EXPIRED. All software that use digital > certificates > >> > know (or > >> > > > are supposed to know) that a certificate which is > expired > >> > is not > >> > > > good for use anymore, except to verify a digital > signature that > >> > > > was created when the certificate was valid, or to > decrypt some > >> > > > thing that was encrypted with the public-key. > >> > > > > >> > > > Certificates that are no longer needed *before* > their natural > >> > > > expiry date, or whose private keys are > lost/compromised, etc. > >> > > > during their natural lifetime, are usually > REVOKED. Only > >> > revoked > >> > > > certificates are shown in a CRL, because software > need to know > >> > > > that a certificate that still appears to have a > natural life > >> > > > (based on the validity dates in the certificate) > must be deemed > >> > > > invalid because of their revocation status. > >> > > > > >> > > > So, what you are seeing is the correct behavior > for CRLs > >> > and for > >> > > > EJBCA. You do not need to worry about expired > certificates not > >> > > > showing up in a CRL. > >> > > > > >> > > > If you are writing software that creates/verifies > digital > >> > > > signatures, you need to understand how to > validate signatures > >> > > > properly. This is because, a digital signature > of a REVOKED > >> > > > certificate can still be a valid signature if the > signature was > >> > > > created before the certificate was revoked. Your > software > >> > should > >> > > > determine that based on the date-time stamp of > the > >> > signature, the > >> > > > date-time stamp of the certificate and the > date-time stamp > >> > of the > >> > > > CRL in which that certificate appears. Of > course, all standard > >> > > > path-validation and other good X509 house-keeping > should be > >> > > > followed before you declare something to be > valid/invalid. > >> > > > > >> > > > Arshad Noor > >> > > > StrongAuth, Inc. > >> > > > > >> > > > On 07/11/2011 07:11 PM, Luat Ngo Vu wrote: > >> > > > > Dear all, > >> > > > > I installed a EJBCA system, i created some > certificates. > >> > > > > One certificate i revoked, then i generated > CRL, i saw that > >> > > > > Certificate in the CRL list. > >> > > > > One certificate was expired 3 days ago, > although i have > >> > > > generated > >> > > > > for many times, but i couldn't see that > certificate in CRL list. > >> > > > > Whether expired certificate is exported to > CRL or not? If > >> > > > yes, how > >> > > > > can i do? If no, how can i do in OCSP check > because it is still > >> > > > valid. > >> > > > > Thanks and best regards > >> > >> > ------------------------------------------------------------------------------ > >> AppSumo Presents a FREE Video for the SourceForge Community by Eric > >> Ries, the creator of the Lean Startup Methodology on "Lean Startup > >> Secrets Revealed." This video shows you how to validate your ideas, > >> optimize your ideas and identify your business strategy. > >> http://p.sf.net/sfu/appsumosfdev2dev > >> _______________________________________________ > >> Ejbca-develop mailing list > >> Ejb...@li...<mailto: > Ejb...@li...> > >> https://lists.sourceforge.net/lists/listinfo/ejbca-develop > >> > >> > > > > > > > ------------------------------------------------------------------------------ > > AppSumo Presents a FREE Video for the SourceForge Community by Eric > > Ries, the creator of the Lean Startup Methodology on "Lean Startup > > Secrets Revealed." This video shows you how to validate your ideas, > > optimize your ideas and identify your business strategy. > > http://p.sf.net/sfu/appsumosfdev2dev > > _______________________________________________ > > Ejbca-develop mailing list > > Ejb...@li... > > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > > > ------------------------------------------------------------------------------ > AppSumo Presents a FREE Video for the SourceForge Community by Eric > Ries, the creator of the Lean Startup Methodology on "Lean Startup > Secrets Revealed." This video shows you how to validate your ideas, > optimize your ideas and identify your business strategy. > http://p.sf.net/sfu/appsumosfdev2dev > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > |