Subject: [pkix] CRL Additional Extension

From: Rafal Siuda <[email-masked]>
Date: Wed, 15 Sep 2010 08:55:29 +0200

Hi, 
I would like to propose additional extension on CRL which indicates if CRL 
contains entries about expired certificates.

Reason:
As rfc5280 states on CRL should be certificates which are not expired. 

Some of PKI software, (UNICERT),and even some version of UNICERT patches 
are different in this,   they do not remove entry about certificate from 
CRL, even if this certificate is expired, and some PKI software removes 
CRL entry about particular certificate just after it expiration time. 

In case if we are validating digital signature, when we are checking 
signing certificate (which is expired now) we can have problems:
 -- if we are checking with "current date" then it is ok - we will get 
result that certificate is expired
BUT:
-let us assume that we want check with date from the past, in particular 
with date from signing certificate validity period. Then: 
If  CRL would have extension that it contains all certificates issued by 
particular CA (ie expired also) , then we would be  sure that signing 
certificate (and thus signature) is valid (if CRL doesn't have an entry 
about this certificate).,
Without this entry we have to know, if CRL contains entries about expired 
certificates or not. If it contains - then signing certificate in this 
verification date is ok, if not- we don't know status of the certificate 
in verification date (and we have to get old or historical CRL). Off 
course if CRL has any entry about certificate, even if it is expired , 
then we are able to get status of this certificate.

Regards
Rafal Siuda

Krajowa Izba Rozliczeniowa S.A., ul. rtm. W. Pileckiego 65, 02-781 
Warszawa, zarejestrowana w Sądzie Rejonowym dla m. st. Warszawy, XIII 
Wydział Gospodarczy Krajowego Rejestru Sądowego pod nr KRS 0000113064, NIP 
526-030-05-17, REGON 012105474, kapitał zakładowy i wpłacony 5.445.000 zł.

Informacja zawarta w tej transmisji jest przeznaczona tylko dla osoby lub 
jednostki, do której jest adresowana. Może ona zawierać zastrzeżone i 
poufne informacje i jeżeli to nie Państwo są wskazanym odbiorcą, nie można 
kopiować, rozpowszechniać lub podejmować żadnych czynności w oparciu o 
nią. W przypadku otrzymania tej transmisji przez pomyłkę, proszę 
powiadomić nadawcę za pomocą emaila zwrotnego i usunąć tę transmisję (wraz 
z załącznikami) z Państwa systemu.

The information contained in this transmission is intended only for the 
individual or entity to whom it is addressed. It may contain privileged 
and confidential information and if you are not an indicated recipient, 
you must not copy, distribute or take any action in reliance on it. If 
received in error, please notify the sender by return email and delete his 
transmission (and any attachments) from your system.

---

From: Andrea Caccia <[email-masked]>
Date: Wed, 15 Sep 2010 09:22:33 +0200

RFC5280 do not prevent from keeping revoked certificates that expires in the CRL, it allows but do not mandate to remove them.
I agree such an extension can be very useful to be mentioned in RFC5280 as it solves a lot of issues, especially in long term verification. Such an extension is already defined in X.509, it is  named ExpiredCertsOnCRL (OID 2.5.29.60). This extension contains the date starting from which expired certificates are kept in the CRL. In case all certificates issued by a CA are kept in the CRL, the value can be set equal to the issuing date of the CA certificate.

By the way, qualified CA in Italy now have to keep expired certificates in CRLs and this extension will become mandatory starting from september 1st, 2011.

Regards,
Andrea Caccia

Il giorno 15/set/2010, alle ore 08.55, Rafal Siuda ha scritto:

> Hi,   
> I would like to propose additional extension on CRL which indicates if CRL contains entries about expired certificates. 
> 
> Reason: 
> Some of PKI software, (UNICERT),and even some version of UNICERT patches are different in this,   they do not remove entry about certificate from CRL, even if this certificate is expired, and some PKI software removes CRL entry about particular certificate just after it expiration time. 
> 
> 
> In case if we are validating digital signature, when we are checking signing certificate (which is expired now) we can have problems: 
>  -- if we are checking with "current date" then it is ok - we will get result that certificate is expired 
> BUT: 
> -let us assume that we want check with date from the past, in particular with date from signing certificate validity period. Then: 
> If  CRL would have extension that it contains all certificates issued by particular CA (ie expired also) , then we would be  sure that signing certificate (and thus signature) is valid (if CRL doesn't have an entry about this certificate)., 
> Without this entry we have to know, if CRL contains entries about expired certificates or not. If it contains - then signing certificate in this verification date is ok, if not- we don't know status of the certificate in verification date (and we have to get old or historical CRL). Off course if CRL has any entry about certificate, even if it is expired , then we are able to get status of this certificate. 
> 
> Regards 
> Rafal Siuda 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Krajowa Izba Rozliczeniowa S.A., ul. rtm. W. Pileckiego 65, 02-781 Warszawa, zarejestrowana w Sądzie Rejonowym dla m. st. Warszawy, XIII Wydział Gospodarczy Krajowego Rejestru Sądowego pod nr KRS 0000113064, NIP 526-030-05-17, REGON 012105474, kapitał zakładowy i wpłacony 5.445.000 zł.
> 
> Informacja zawarta w tej transmisji jest przeznaczona tylko dla osoby lub jednostki, do której jest adresowana. Może ona zawierać zastrzeżone i poufne informacje i jeżeli to nie Państwo są wskazanym odbiorcą, nie można kopiować, rozpowszechniać lub podejmować żadnych czynności w oparciu o nią. W przypadku otrzymania tej transmisji przez pomyłkę, proszę powiadomić nadawcę za pomocą emaila zwrotnego i usunąć tę transmisję (wraz z załącznikami) z Państwa systemu.
> 
> 
> The information contained in this transmission is intended only for the individual or entity to whom it is addressed. It may contain privileged and confidential information and if you are not an indicated recipient, you must not copy, distribute or take any action in reliance on it. If received in error, please notify the sender by return email and delete his transmission (and any attachments) from your system.
> 
> 
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Wed, 15 Sep 2010 11:50:09 +0200

Rafal Siuda wrote:
> I would like to propose additional extension on CRL which indicates if
> CRL contains entries about expired certificates.

During the discussion phase of RFC5280, it was requested several time to 
document inside it the expiredCertsOnCRL extension of X.509.

The editors held to the position that there was already too many 
extensions in RFC5280 to add yet another one. I personally consider they 
are quite a few features in RFC5280 that about nobody uses and are 
definitively a lot less useful than expiredCertsOnCRL.

Some past discussion about it :
http://www.imc.org/ietf-pkix/mail-archive/msg01962.html

The CRL rule that :
    An entry MUST NOT be removed
    from the CRL until it appears on one regularly scheduled CRL issued
    beyond the revoked certificate's validity period.
can not be *reliably* depended on without using expiredCertsOnCRL.

---

From: Massimiliano Pala <[email-masked]>
Date: Tue, 21 Sep 2010 12:45:54 +0200

Hi Rafal, all,

As others already said, you can always keep the entries in the CRL without
the need to remove them from the CRL - also when the certificate is expired.
This said, allowing the entry to be removed when the certificate expires
allows the CRL to not grow indefinitely (otherwise the size of CRLs would
monotonically increase).

I would argue that the problem is in the application/pki interface. There
should be an easy and standardized way to retrieve a CRL (or a set of CRLs)
based on their issuing date.

For example, a pki server should be able to provide answers like the
following:

    "I want all the CRLs valid on *this* date"

Has anybody worked on providing a data retrieval protocol for PKIX
infrastructures ? (BTW, the same problem applies to certificate retrieval
and OCSP responses).

Later,
Max

On 09/15/2010 08:55 AM, Rafal Siuda wrote:
> Without this entry we have to know, if CRL contains entries about
> expired certificates or not. If it contains - then signing certificate
> in this verification date is ok, if not- we don't know status of the
> certificate in verification date (and we have to get old or historical
> CRL). Off course if CRL has any entry about certificate, even if it is
> expired , then we are able to get status of this certificate.
>
> Regards
> Rafal Siuda

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]                   [email-masked]
                                                  [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 369-9332
PKI/Trust Laboratory                          Work Phone: +1 (603) 646-8734
--o------------------------------------------------------------------------
People who think they know everything are a great annoyance to those of us
who do.
							   -- Isaac Asimov

---

From: "Denis Pinkas"<[email-masked]>
Date: Wed, 22 Sep 2010 09:59:44 +0200

In order to reply to the original e-mail, ETSI has defined such an extension in TS 101 862: 
Qualified Certificate Profile in the following way:

Statement indicating the duration of the retention period of material information
Reliance on Qualified Certificates may depend on the existence of external information retained by the CA. 
A significant aspect is that the Directive 1999/93/EC [1] allows name forms in certificates, such as pseudonyms, 
which may require assistance from the CA or a relevant name registration authority, in order to identify the 
associated physical person in case of a dispute.
This optional statement contains:
·            an identifier of this statement (represented by an OID);
·            a retention period for material information relevant to the use of and reliance on the certificate, 
expressed as a number of years after the expiry date of the certificate.
   esi4-qcStatement-3 QC-STATEMENT ::= { SYNTAX QcEuRetentionPeriod IDENTIFIED
   BY id-etsi-qcs-QcRetentionPeriod }
   --  This statement is a statement by which the issuer guarantees 
   --  that for the certificate where this statement appears that 
   --  material information relevant to use of and reliance on the certificate 
   --  will be archived and can be made available upon 
   --  request beyond the end of the validity period of the certificate 
   --  for the number of years as indicated in this statement.
 
   QcEuRetentionPeriod ::= INTEGER
 
id-etsi-qcs-QcRetentionPeriod OBJECT IDENTIFIER ::= { id-etsi-qcs 3 }

I personnally don't like it, since it allows CRLs growing and growing, but it has been defined ...
The other reason why it is not desirable to use this approach is that a verifier in any case should verify 
a signature as soon as it receives it and should at the same time capture all the material used for the verification.

This does not prevent him to archive some of it somewhere else (i.e. not locally). 
The design of the signature format defined by ETSI has been done especially to handle that case: 
the references of the revocation information (and of the certificates from the certification path) are mandatory, 
but not the values.

Denis
----- Message reçu ----- 
De : pkix-bounces 
À : pkix 
Date : 2010-09-21, 12:45:54
Sujet : Re: [pkix] CRL Additional Extension

Pièce(s) Jointe(s) au message original :
  (1). smime.p7s

Hi Rafal, all,

Later,
Max

-- 

Best Regards,

  Massimiliano Pala

_____________________ next part ______________________

---

From: Tom Gindin <[email-masked]>
Date: Fri, 24 Sep 2010 09:30:09 -0400

Max:

        I don't understand what you mean by a "PKI server".  It would 
probably help users of this function, though, if typical CRL retrieval 
servers would support queries similar to
http://host/directory/CRLFetch?Issuer=(escaped_DN)&lastBefore=(timestamp)
http://host/directory/CRLFetchDP?Name=(escaped_URI)&lastBefore=(timestamp)
        The purpose of these queries would be to retrieve the most recent 
CRL for the specified issuer or distribution point.  I doubt that it's 
appropriate to add the URL for this query to the certificate itself.  I'm 
not sure of an appropriate method for publicizing these queries and 
similar ones.
        It might make more sense to extend RFC 4387's syntax (section 2.2) 
to cover this instead, and declare it optionally supported.  I do think 
that DPName or DPHash ought to be added to that syntax for CRL's, anyway. 
This in no way disputes Peter's choice to use SIA or AIA to point at the 
certstore interface, but it does treat DPName as the identifier of a CRL 
partition.

                        Tom Gindin

From:
Massimiliano Pala <[email-masked]>
To:
[email-masked]
Date:
09/21/2010 06:43 AM
Subject:
Re: [pkix] CRL Additional Extension
Sent by:
[email-masked]

Hi Rafal, all,

As others already said, you can always keep the entries in the CRL without
the need to remove them from the CRL - also when the certificate is 
expired.
This said, allowing the entry to be removed when the certificate expires
allows the CRL to not grow indefinitely (otherwise the size of CRLs would
monotonically increase).

I would argue that the problem is in the application/pki interface. There
should be an easy and standardized way to retrieve a CRL (or a set of 
CRLs)
based on their issuing date.

Later,
Max

-- 

Best Regards,

                 Massimiliano Pala

Dartmouth Computer Science Dept               Home Phone: +1 (603) 
369-9332
PKI/Trust Laboratory                          Work Phone: +1 (603) 
646-8734
--o------------------------------------------------------------------------
People who think they know everything are a great annoyance to those of us
who do.
                                    -- Isaac Asimov

[attachment "smime.p7s" deleted by Tom Gindin/Watson/IBM] 
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Michael Ströder <[email-masked]>
Date: Fri, 24 Sep 2010 22:19:52 +0200

Jean-Marc Desperrier wrote:
> I personally consider they are quite a few features in RFC5280 that about
> nobody uses and are definitively a lot less useful than expiredCertsOnCRL.

Yes. :-/

Ciao, Michael.

---

From: Tom Gindin <[email-masked]>
Date: Fri, 24 Sep 2010 18:24:39 -0400

If this extension doesn't belong in 5280, should there be a 
"Additional Certificate and CRL Extensions" informational draft analogous 
to PKCS-9?  If nothing else, we could clear up the difference between 
X.509's one and ETSI's apparently similar one.

                Tom Gindin

From:
Michael Ströder <[email-masked]>
To:
Jean-Marc Desperrier <[email-masked]>
Cc:
"[email-masked]" <[email-masked]>
Date:
09/24/2010 04:23 PM
Subject:
Re: [pkix] CRL Additional Extension
Sent by:
[email-masked]

Yes. :-/

Ciao, Michael.

---

From: Andrea Caccia <[email-masked]>
Date: Sat, 25 Sep 2010 20:08:54 +0200

ETSI extension has a different meaning and is a certificate extension, not a CRL one. It states that the CA issuing the Qualified Certificate containing such extension retains the information about the subject for such amount of years. It does not specify how to access to such information, that is not only about certificate revocation.

Andrea Caccia

---

From: Rafal Siuda <[email-masked]>
Date: Tue, 28 Sep 2010 09:47:42 +0200

Tim, 
You are right, but you assume almost ideal situation where each CA in the 
country has such server and such functionality.

Imagine situation where in the country are 4 CA,, and you want to develop 
app which verifies signatures from all of them (and signing certfficate is 
expired)
If you would have this extension - you will exactly know what to do 
veryfing certifiacation path and existence of signing cert on CRL.
Without this extension - you have to assume (are or arent expired certs in 
CRL) . Off course you have to know that one CA can have expired certs on 
CRL, and other not,

This extension is not reason that CRL will incease , they will, if you 
will have all expired certs on CRL, but  it will carry only information if 
expired certs are on CRL or not.
Another business is staring time from which you will have expired certs on 
CRL (you can keep them if they are not older than 5 years form example) 
and then you will have mechanism which allow you to control if CRL is 
growing rapidly or not.

Thats why,  ExpiredCertsOnCRL extension defined in X.509 solves this 
problem and it should be also defined in rfc 5280.

Regards 
Rafal Siuda

Od:
Tom Gindin <[email-masked]>
Do:
Massimiliano Pala <[email-masked]>
DW:
pkix <[email-masked]>
Data:
2010-09-24 15:31
Temat:
Re: [pkix] CRL Additional Extension
Wysłane przez:
[email-masked]

        Max:

                        Tom Gindin

From:

Hi Rafal, all,

Later,
Max

-- 

Best Regards,

                 Massimiliano Pala

---

From: Tom Gindin <[email-masked]>
Date: Tue, 28 Sep 2010 21:03:26 -0400

Rafal:

        I am in favor of having ExpiredCertsOnCRL available for use, but I 
don't believe that most CA's will use ExpiredCertsOnCRL with long time 
horizons either.  It is even less realistic to assume that all CA's will 
use that extension for the time period you need or longer than to assume 
that all CA's will support RFC 4387 and maintain CRL archives.  The 
advantage of the "lastBefore" parameter I suggested is that the query 
specifies how far back you want the CA to go rather than the CA deciding 
how many years of expired revocations to distribute for even current 
revocation checks, especially if "superseded" becomes typical practice and 
most certificates get revoked sometime in their last month of permitted 
validity.
        I did suggest last week that we might want to create an 
"Additional Certificate and CRL Extensions" informational draft analogous 
to PKCS-9, since ExpiredCertsOnCRL probably won't go into 5280.  This 
extension would go there.

Tom Gindin

From:
Rafal Siuda <[email-masked]>
To:
[email-masked]
Date:
09/28/2010 03:48 AM
Subject:
[pkix] ODP: Re:  CRL Additional Extension
Sent by:
[email-masked]

Tim, 

Regards 
Rafal Siuda 

Od: 

        Max:

                       Tom Gindin

From:

Hi Rafal, all,

Later,
Max

-- 

Best Regards,

                Massimiliano Pala

---

From: Tom Gindin <[email-masked]>
Date: Thu, 30 Sep 2010 09:10:44 -0400

There is no such requirement in 4387, and defining an interface to 
access a CRL archive through certstore if such an archive is maintained 
would not require a CA supporting certstore to maintain such an archive. 
Equally, I know of no requirement for each CA to maintain unpurged CRL's 
in X.509.  You and Rafal seem to feel that sending large CRL's containing 
lots of expired certificates, even when the user is NOT performing 
long-term verification, is less of a burden than defining a remote 
interface to an archive.  I doubt that all CA's will agree.
        The reason code "superseded" appears to be appropriate when a new 
certificate has been placed into use as a replacement for the one listed - 
not because expiration is imminent, but because the certificate has been 
replaced.  I personally have little experience with it's being used.

                Tom Gindin

From:
"Jain Piyush" <[email-masked]>
To:
Tom Gindin/Watson/IBM@IBMUS, "Rafal Siuda" <[email-masked]>
Cc:
<[email-masked]>
Date:
09/29/2010 01:30 PM
Subject:
RE: [pkix] ODP: Re:  CRL Additional Extension

Tom,

I could not find anything in RFC 4387 that imposes the requirement of 
maintaining CRL archives on a CA.
Even if such a requirement is imposed on a CA, this extension would 
probably come in handy because the CA can maintain just one CRL that 
contains the complete history of revoked certificates.

Long term archiving/lookup of revocation data has many applications and if 
CAs can provide this functionality, individual relying parties will not 
need to maintain the archive. It's also possible that CAs can issue two 
CRLs (identifiable by different attributes in the repository), one that 
contains status for currently active certificates and other that contains 
status for all certificates issued by the CA.

Now revoking certificates just because they are about to expire is 
something that I never understood. 

-Piyush

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
Tom Gindin
Sent: Tuesday, September 28, 2010 6:03 PM
To: Rafal Siuda
Cc: [email-masked]
Subject: Re: [pkix] ODP: Re: CRL Additional Extension

        Rafal:

Tom Gindin

From:

Tim, 

expired) 

Regards 
Rafal Siuda 

Od: 

        Max:

                       Tom Gindin

From:

Hi Rafal, all,

Later,
Max

-- 

Best Regards,

                Massimiliano Pala