Re: [Ejbca-develop] why expired certificate is not in CRL list

[Arshad N. <ars...@st...>]

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...>> 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...>>> 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...>>>> 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