Subject: Re: [pkix] ODP: Re: CRL Additional Extension

From: Stefan Santesson <[email-masked]>
Date: Fri, 08 Oct 2010 14:20:21 +0200

A few aspects,

I think CRLs in general are a suboptimal solution for historic validation of
signatures. Especially if you are relying on the current CRL to help you
validate a signature based on an expired certificate.

There are better solutions, e.g. where you store the revocation information
on original verification and use that instead.

But this extension from X.509 have nevertheless been requested by some real
implementations and I think it represents a valid (even though not optimal)
option.

We can't add this extension to RFC 3280 but we can document it in an
informational RFC or save it for RFC5280bis which will not happen any time
soon (hopefully).

I don't object to any of these approaches.

/Stefan

On 10-09-28 9:47 AM, "Rafal Siuda" <[email-masked]> wrote:

> 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:
> 
>         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/CRLFetch?Issuer=(escaped_DN)&lastBefore=(timestamp)>
> http://host/directory/CRLFetchDP?Name=(escaped_URI)&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.
> 
> 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:
>> > 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

---

From: Rafal Siuda <[email-masked]>
Date: Mon, 11 Oct 2010 09:23:43 +0200

Yes.
Decision if CRL should contain revoked certs or not is up to CA, and off 
course it MAY be like disaster. But it doesnt mean it always be disaster. 
(if on CRL is 100 or 1000 certs - it makes no difference ; if there is one 
hundred times more - it makes....)
Extension ExpiredCertsOnCRL  doesnt force CA to include expired 
certificates,  it is just carrying important information which could help 
in verifying signature. Thats why it should be part of RFC.

Regards

Rafal Siuda

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

That would be a disaster. Won't it be? US DOD PKI management office would 
agree wholeheartedly :).
I don't mean to suggest that CAs should be forced to include the expired 
certificates in the list and a standard optional extension would certainly 
not force them to.

Also, I have to agree that I have no idea which of the two approaches 
would be more burdensome, but my guess is that for SSL type online 
applications smaller CRLs would be preferable but for long term archiving 
of SMIME artifacts a single large CRL with status for every revoked 
certificate would be preferable.

Dave's proposal in this discussion 
http://www.ietf.org/mail-archive/web/pkix/current/msg03771.html would 
address the needs of both kind of applications, but that's a separate 
discussion.

Your proposal to include this extension as part of different RFC makes a 
lot of sense. It is quiet cumbersome to go through revisions of big 
documents like 5280 and having a separate RFC to define additional CRL and 
CERT extensions would make the process faster and keep the discussions 
focused.

Best Regards
-Piyush

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Thursday, September 30, 2010 6:11 AM
To: Jain Piyush
Cc: [email-masked]; Rafal Siuda
Subject: RE: [pkix] ODP: Re: CRL Additional Extension

        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:

        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, 

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

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

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

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

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

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

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: Mon, 11 Oct 2010 09:54:33 +0200

When a CA decide (or have to, in case it is mandated to do so by law) to keep revoked certs in the CRL, its CRL grows even without the ExpiredCertsOnCRL extension… on the other hand the RFC can limit the drawbacks recommending to keep revoked certificates in the CRL only when it makes sense and together with a mechanism that can limit  an excessive increase of the CRL, such as CRL partitioning.
If a CRL is associated with y 1000 certificates, this is the maximum size of the related CRL. Another possibility is when OCSP is used: its DB can be loaded with a CRL containing ExpiredCertsOnCRL and give answers also for expired certs. Does it makes sense to allow this extension also in OCSP requests and/or responses?

Regards,
Andrea Caccia

Il giorno 11/ott/2010, alle ore 09.23, Rafal Siuda ha scritto:

> Yes. 
> Decision if CRL should contain revoked certs or not is up to CA, and off course it MAY be like disaster. But it doesnt mean it always be disaster. (if on CRL is 100 or 1000 certs - it makes no difference ; if there is one hundred times more - it makes....) 
> Extension ExpiredCertsOnCRL  doesnt force CA to include expired certificates,  it is just carrying important information which could help in verifying signature. Thats why it should be part of RFC. 
> 
> Regards 
> 
> Rafal Siuda 
> 
> 
> 
> 
> 
> That would be a disaster. Won't it be? US DOD PKI management office would agree wholeheartedly :).
> I don't mean to suggest that CAs should be forced to include the expired certificates in the list and a standard optional extension would certainly not force them to. 
> 
> 
> 
> Also, I have to agree that I have no idea which of the two approaches would be more burdensome, but my guess is that for SSL type online applications smaller CRLs would be preferable but for long term archiving of SMIME artifacts a single large CRL with status for every revoked certificate would be preferable.
> 
> Dave's proposal in this discussion http://www.ietf.org/mail-archive/web/pkix/current/msg03771.html would address the needs of both kind of applications, but that's a separate discussion.
> 
> Your proposal to include this extension as part of different RFC makes a lot of sense. It is quiet cumbersome to go through revisions of big documents like 5280 and having a separate RFC to define additional CRL and CERT extensions would make the process faster and keep the discussions focused.
> 
> Best Regards
> -Piyush
> 
> 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: Stefan Santesson <[email-masked]>
Date: Mon, 11 Oct 2010 13:16:09 +0200

The point of this extension is not to propose CA practice.

If the CRL contains information about expired certificates, the relying
party need to know what that means. Most importantly, since this is a
negative list (absent information about revocation, the certificate is
supposed to be valid at the time), the relying party need to know from what
date all expired certificates are covered by this CRL.

That is the kind of information you provide in this extension.

By having a date after which all expired certs are covered by the CRL, the
CRL does not grow indefinitely, you just introduce a timeframe during which
expired certs are covered by the CRL.

/Stefan

On 10-10-11 9:54 AM, "Andrea Caccia" <[email-masked]> wrote:

> When a CA decide (or have to, in case it is mandated to do so by law) to keep
> revoked certs in the CRL, its CRL grows even without the ExpiredCertsOnCRL
> extension... on the other hand the RFC can limit the drawbacks recommending to
> keep revoked certificates in the CRL only when it makes sense and together
> with a mechanism that can limit  an excessive increase of the CRL, such as CRL
> partitioning.
> If a CRL is associated with y 1000 certificates, this is the maximum size of
> the related CRL. Another possibility is when OCSP is used: its DB can be
> loaded with a CRL containing ExpiredCertsOnCRL and give answers also for
> expired certs. Does it makes sense to allow this extension also in OCSP
> requests and/or responses?
> 
> Regards,
> Andrea Caccia
> 
>> course it MAY be like disaster. But it doesnt mean it always be disaster. (if
>> on CRL is 100 or 1000 certs - it makes no difference ; if there is one
>> Extension ExpiredCertsOnCRL  doesnt force CA to include expired certificates,
>> it is just carrying important information which could help in verifying
>> signature. Thats why it should be part of RFC.
>> 
>> Regards 
>> 
>> Rafal Siuda 
>> 
>> 
>> 
>> 
>> 
>> Also, I have to agree that I have no idea which of the two approaches would
>> be more burdensome, but my guess is that for SSL type online applications
>> smaller CRLs would be preferable but for long term archiving of SMIME
>> artifacts a single large CRL with status for every revoked certificate would
>> be preferable.
>> 
>> http://www.ietf.org/mail-archive/web/pkix/current/msg03771.html
>> <http://www.ietf.org/mail-archive/web/pkix/current/msg03771.html> would
>> Your proposal to include this extension as part of different RFC makes a lot
>> of sense. It is quiet cumbersome to go through revisions of big documents
>> like 5280 and having a separate RFC to define additional CRL and CERT
>> extensions would make the process faster and keep the discussions focused.
>> 
>> Best Regards
>> -Piyush
>> 
>> From: Tom Gindin [mailto:[email-masked] <mailto:[email-masked]> ]
>> From: [email-masked] [mailto:[email-masked]
>> <mailto:[email-masked]> ] On Behalf Of
>> Tom Gindin