From: Massimiliano Z. <mas...@gm...> - 2011-07-13 08:04:09
|
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...>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...>> 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...>>> 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 > > > > LuatVV > > > > -- > > > > Full name: Vũ Văn Luật > > > > Position: Project manager, VNPT-CA - VDC - VNPT > > > > Mobile: 0977686757 <tel:0977686757> <tel:0977686757 > > <tel:0977686757>> > > > > Email: dra...@gm... > > <mailto:dra...@gm...> > > > <mailto:dra...@gm... > > <mailto:dra...@gm...>> > > > <mailto:dra...@gm... > > <mailto:dra...@gm...> > > > <mailto:dra...@gm... > > <mailto:dra...@gm...>>> > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > All of the data generated in your IT infrastructure is > seriously > > > valuable. > > > Why? It contains a definitive record of application > performance, > > > security > > > threats, fraudulent activity, and more. Splunk takes this > > data and makes > > > sense of it. IT sense. And common sense. > > > http://p.sf.net/sfu/splunk-d2d-c2 > > > _______________________________________________ > > > Ejbca-develop mailing list > > > Ejb...@li... > > <mailto:Ejb...@li...> > > > <mailto:Ejb...@li... > > <mailto:Ejb...@li...>> > > > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > All of the data generated in your IT infrastructure is seriously > > valuable. > > > Why? It contains a definitive record of application performance, > > security > > > threats, fraudulent activity, and more. Splunk takes this data > > and makes > > > sense of it. IT sense. And common sense. > > > http://p.sf.net/sfu/splunk-d2d-c2 > > > > > > > > > > > > _______________________________________________ > > > Ejbca-develop mailing list > > > Ejb...@li... > > <mailto:Ejb...@li...> > > > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > > > > > ------------------------------------------------------------------------------ > > All of the data generated in your IT infrastructure is seriously > > valuable. > > Why? It contains a definitive record of application performance, > > security > > threats, fraudulent activity, and more. Splunk takes this data and > makes > > sense of it. IT sense. And common sense. > > http://p.sf.net/sfu/splunk-d2d-c2 > > _______________________________________________ > > Ejbca-develop mailing list > > Ejb...@li... > > <mailto:Ejb...@li...> > > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > > > > > > > > > > > ------------------------------------------------------------------------------ > > All of the data generated in your IT infrastructure is seriously > valuable. > > Why? It contains a definitive record of application performance, security > > threats, fraudulent activity, and more. Splunk takes this data and makes > > sense of it. IT sense. And common sense. > > http://p.sf.net/sfu/splunk-d2d-c2 > > > > > > > > _______________________________________________ > > Ejbca-develop mailing list > > Ejb...@li... > > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > |