Discussion:
What should be in "Next Update" field of the last CRL?
(too old to reply)
Roberto Opazo
2011-02-16 18:49:50 UTC
Permalink
Hello:

I can't find an specification about what to put in the "Next Update"
field of the last CRL issued by one CA in its last day. I mean, the
day when this CA certificates expires.

Is there any recommendation?

Without a recommendation you could chose very different options:

* NULL. The field is optional after all, but RFC5280 states
"Conforming CRL issuers MUST include the nextUpdate field in all
CRLs."

* 24 hours, as all other CRL's. But that's a lie, CA is going to be
expired in 24 hours, son It can't sign.

* Year 2999. So no one alive today is going to be alive that they, but
it's a lie any way and there could be systems not prepared to process
that date.

So, could you help me with an official recommendation?

--
Best regards,

Roberto Opazo
Russ Housley
2011-02-16 19:46:33 UTC
Permalink
Is the CA being shut down forever? Or, is a new CA taking over using the key rollover stuff specified in CMP?

Russ


On Feb 16, 2011, at 1:49 PM, Roberto Opazo wrote:

> Hello:
>
> I can't find an specification about what to put in the "Next Update"
> field of the last CRL issued by one CA in its last day. I mean, the
> day when this CA certificates expires.
>
> Is there any recommendation?
>
> Without a recommendation you could chose very different options:
>
> * NULL. The field is optional after all, but RFC5280 states
> "Conforming CRL issuers MUST include the nextUpdate field in all
> CRLs."
>
> * 24 hours, as all other CRL's. But that's a lie, CA is going to be
> expired in 24 hours, son It can't sign.
>
> * Year 2999. So no one alive today is going to be alive that they, but
> it's a lie any way and there could be systems not prepared to process
> that date.
>
> So, could you help me with an official recommendation?
>
> --
> Best regards,
>
> Roberto Opazo
> _______________________________________________
> pkix mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
Russ Housley
2011-02-16 21:56:08 UTC
Permalink
RFC 5280 says the following about a certificate notAfter field:

To indicate that a certificate has no well-defined expiration date,
the notAfter SHOULD be assigned the GeneralizedTime value of
99991231235959Z.

It seems to me that the same value is appropriate for a CRL.

Russ


On Feb 16, 2011, at 3:32 PM, Roberto Opazo wrote:

> CA being shut down forever.
>
> 2011/2/16 Russ Housley <***@vigilsec.com>:
>> Is the CA being shut down forever? Or, is a new CA taking over using the key rollover stuff specified in CMP?
>>
>> Russ
>>
>>
>> On Feb 16, 2011, at 1:49 PM, Roberto Opazo wrote:
>>
>>> Hello:
>>>
>>> I can't find an specification about what to put in the "Next Update"
>>> field of the last CRL issued by one CA in its last day. I mean, the
>>> day when this CA certificates expires.
>>>
>>> Is there any recommendation?
>>>
>>> Without a recommendation you could chose very different options:
>>>
>>> * NULL. The field is optional after all, but RFC5280 states
>>> "Conforming CRL issuers MUST include the nextUpdate field in all
>>> CRLs."
>>>
>>> * 24 hours, as all other CRL's. But that's a lie, CA is going to be
>>> expired in 24 hours, son It can't sign.
>>>
>>> * Year 2999. So no one alive today is going to be alive that they, but
>>> it's a lie any way and there could be systems not prepared to process
>>> that date.
>>>
>>> So, could you help me with an official recommendation?
>>>
>>> --
>>> Best regards,
>>>
>>> Roberto Opazo
>>> _______________________________________________
>>> pkix mailing list
>>> ***@ietf.org
>>> https://www.ietf.org/mailman/listinfo/pkix
>>
>>
>
>
>
> --
> Saludos,
>
> Roberto Opazo
Michael StJohns
2011-02-17 01:23:45 UTC
Permalink
That's probably the most right choice, but hard to implement programmatically I think. The code generating the signature doesn't know/can't know (absent outside info) whether or not the signing cert will be reissued. I'd suggest that using the same interval time for "Next Update" - at that point, either the cert has been reissued or it hasn't. If it has, the date is appropriate. If it hasn't - well the CRL becomes moot as the signing cert is no longer valid.

Mike



At 04:56 PM 2/16/2011, Russ Housley wrote:
>RFC 5280 says the following about a certificate notAfter field:
>
> To indicate that a certificate has no well-defined expiration date,
> the notAfter SHOULD be assigned the GeneralizedTime value of
> 99991231235959Z.
>
>It seems to me that the same value is appropriate for a CRL.
>
>Russ
>
>
>On Feb 16, 2011, at 3:32 PM, Roberto Opazo wrote:
>
>> CA being shut down forever.
>>
>> 2011/2/16 Russ Housley <***@vigilsec.com>:
>>> Is the CA being shut down forever? Or, is a new CA taking over using the key rollover stuff specified in CMP?
>>>
>>> Russ
>>>
>>>
>>> On Feb 16, 2011, at 1:49 PM, Roberto Opazo wrote:
>>>
>>>> Hello:
>>>>
>>>> I can't find an specification about what to put in the "Next Update"
>>>> field of the last CRL issued by one CA in its last day. I mean, the
>>>> day when this CA certificates expires.
>>>>
>>>> Is there any recommendation?
>>>>
>>>> Without a recommendation you could chose very different options:
>>>>
>>>> * NULL. The field is optional after all, but RFC5280 states
>>>> "Conforming CRL issuers MUST include the nextUpdate field in all
>>>> CRLs."
>>>>
>>>> * 24 hours, as all other CRL's. But that's a lie, CA is going to be
>>>> expired in 24 hours, son It can't sign.
>>>>
>>>> * Year 2999. So no one alive today is going to be alive that they, but
>>>> it's a lie any way and there could be systems not prepared to process
>>>> that date.
>>>>
>>>> So, could you help me with an official recommendation?
>>>>
>>>> --
>>>> Best regards,
>>>>
>>>> Roberto Opazo
>>>> _______________________________________________
>>>> pkix mailing list
>>>> ***@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/pkix
>>>
>>>
>>
>>
>>
>> --
>> Saludos,
>>
>> Roberto Opazo
>
>_______________________________________________
>pkix mailing list
>***@ietf.org
>https://www.ietf.org/mailman/listinfo/pkix
Michael StJohns
2011-02-17 01:34:13 UTC
Permalink
To expand on this - consider a CA with a CRL interval quite a bit longer - say 30 days. The CA cert will expire 20 days into that period. It seems to me that issuing a CRL at day 0 with a Next Update of "sometime far in the future" would become problematic if the CA were resigned with a longer expiration date around day 15.

Mike



At 08:23 PM 2/16/2011, Michael StJohns wrote:
>That's probably the most right choice, but hard to implement programmatically I think. The code generating the signature doesn't know/can't know (absent outside info) whether or not the signing cert will be reissued. I'd suggest that using the same interval time for "Next Update" - at that point, either the cert has been reissued or it hasn't. If it has, the date is appropriate. If it hasn't - well the CRL becomes moot as the signing cert is no longer valid.
>
>Mike
>
>
>
>At 04:56 PM 2/16/2011, Russ Housley wrote:
>>RFC 5280 says the following about a certificate notAfter field:
>>
>> To indicate that a certificate has no well-defined expiration date,
>> the notAfter SHOULD be assigned the GeneralizedTime value of
>> 99991231235959Z.
>>
>>It seems to me that the same value is appropriate for a CRL.
>>
>>Russ
>>
>>
>>On Feb 16, 2011, at 3:32 PM, Roberto Opazo wrote:
>>
>>> CA being shut down forever.
>>>
>>> 2011/2/16 Russ Housley <***@vigilsec.com>:
>>>> Is the CA being shut down forever? Or, is a new CA taking over using the key rollover stuff specified in CMP?
>>>>
>>>> Russ
>>>>
>>>>
>>>> On Feb 16, 2011, at 1:49 PM, Roberto Opazo wrote:
>>>>
>>>>> Hello:
>>>>>
>>>>> I can't find an specification about what to put in the "Next Update"
>>>>> field of the last CRL issued by one CA in its last day. I mean, the
>>>>> day when this CA certificates expires.
>>>>>
>>>>> Is there any recommendation?
>>>>>
>>>>> Without a recommendation you could chose very different options:
>>>>>
>>>>> * NULL. The field is optional after all, but RFC5280 states
>>>>> "Conforming CRL issuers MUST include the nextUpdate field in all
>>>>> CRLs."
>>>>>
>>>>> * 24 hours, as all other CRL's. But that's a lie, CA is going to be
>>>>> expired in 24 hours, son It can't sign.
>>>>>
>>>>> * Year 2999. So no one alive today is going to be alive that they, but
>>>>> it's a lie any way and there could be systems not prepared to process
>>>>> that date.
>>>>>
>>>>> So, could you help me with an official recommendation?
>>>>>
>>>>> --
>>>>> Best regards,
>>>>>
>>>>> Roberto Opazo
>>>>> _______________________________________________
>>>>> pkix mailing list
>>>>> ***@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/pkix
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Saludos,
>>>
>>> Roberto Opazo
>>
>>_______________________________________________
>>pkix mailing list
>>***@ietf.org
>>https://www.ietf.org/mailman/listinfo/pkix
>
>
>_______________________________________________
>pkix mailing list
>***@ietf.org
>https://www.ietf.org/mailman/listinfo/pkix
Alan Sill
2011-02-17 01:47:04 UTC
Permalink
A CA can become inactive for the purposes of issuing new credentials
without necessarily invalidating the certificates already issued. The
CRL server can be maintained and can be used to revoke previously
issued certificates for as long as they are of use to the relying
parties making use of those certificates.

In principle, a CRL server should be maintained and should issue
updates (with valid "Next Update" fields) through the full period that
includes any certificate previously issued by the CA. Otherwise, any
relying parties making use of the certificates either to assert or
grant trust will be unaware of any change to the status of the
previously issued certs.

An option is to revoke all previously issued certs at a time of your
choice and put them all into your last CRL update. the "next Update"
time would then be set to the previously quoted GeneralizedTime value
(99991231235959Z) to indicate that there will be no further updates.
It would also be perfectly valid to leave previously issued certs that
you as the CA operator would like to allow to remain active out of the
CRL, and continue to issue CRL updates through the expiration date of
the last remaining active certificate.

Alan

On Feb 16, 2011, at 7:34 PM, Michael StJohns wrote:

> To expand on this - consider a CA with a CRL interval quite a bit
> longer - say 30 days. The CA cert will expire 20 days into that
> period. It seems to me that issuing a CRL at day 0 with a Next
> Update of "sometime far in the future" would become problematic if
> the CA were resigned with a longer expiration date around day 15.
>
> Mike
>
>
>
> At 08:23 PM 2/16/2011, Michael StJohns wrote:
>> That's probably the most right choice, but hard to implement
>> programmatically I think. The code generating the signature
>> doesn't know/can't know (absent outside info) whether or not the
>> signing cert will be reissued. I'd suggest that using the same
>> interval time for "Next Update" - at that point, either the cert
>> has been reissued or it hasn't. If it has, the date is
>> appropriate. If it hasn't - well the CRL becomes moot as the
>> signing cert is no longer valid.
>>
>> Mike
>>
>>
>>
>> At 04:56 PM 2/16/2011, Russ Housley wrote:
>>> RFC 5280 says the following about a certificate notAfter field:
>>>
>>> To indicate that a certificate has no well-defined expiration date,
>>> the notAfter SHOULD be assigned the GeneralizedTime value of
>>> 99991231235959Z.
>>>
>>> It seems to me that the same value is appropriate for a CRL.
>>>
>>> Russ
>>>
>>>
>>> On Feb 16, 2011, at 3:32 PM, Roberto Opazo wrote:
>>>
>>>> CA being shut down forever.
>>>>
>>>> 2011/2/16 Russ Housley <***@vigilsec.com>:
>>>>> Is the CA being shut down forever? Or, is a new CA taking over
>>>>> using the key rollover stuff specified in CMP?
>>>>>
>>>>> Russ
>>>>>
>>>>>
>>>>> On Feb 16, 2011, at 1:49 PM, Roberto Opazo wrote:
>>>>>
>>>>>> Hello:
>>>>>>
>>>>>> I can't find an specification about what to put in the "Next
>>>>>> Update"
>>>>>> field of the last CRL issued by one CA in its last day. I mean,
>>>>>> the
>>>>>> day when this CA certificates expires.
>>>>>>
>>>>>> Is there any recommendation?
>>>>>>
>>>>>> Without a recommendation you could chose very different options:
>>>>>>
>>>>>> * NULL. The field is optional after all, but RFC5280 states
>>>>>> "Conforming CRL issuers MUST include the nextUpdate field in all
>>>>>> CRLs."
>>>>>>
>>>>>> * 24 hours, as all other CRL's. But that's a lie, CA is going
>>>>>> to be
>>>>>> expired in 24 hours, son It can't sign.
>>>>>>
>>>>>> * Year 2999. So no one alive today is going to be alive that
>>>>>> they, but
>>>>>> it's a lie any way and there could be systems not prepared to
>>>>>> process
>>>>>> that date.
>>>>>>
>>>>>> So, could you help me with an official recommendation?
>>>>>>
>>>>>> --
>>>>>> Best regards,
>>>>>>
>>>>>> Roberto Opazo
>>>>>> _______________________________________________
>>>>>> pkix mailing list
>>>>>> ***@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/pkix
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Saludos,
>>>>
>>>> Roberto Opazo
>>>

Alan Sill, Ph.D
Senior Scientist, High Performance Computing Center
Adjunct Professor of Physics, TTU
Vice President of Standards, Open Grid Forum

====================================================================
: Alan Sill, Texas Tech University Office: Drane 162, MS 4-1167 :
: e-mail: ***@ttu.edu ph. 806-742-4350 fax 806-742-4358 :
====================================================================
Michael StJohns
2011-02-17 01:57:40 UTC
Permalink
At 08:47 PM 2/16/2011, Alan Sill wrote:
>A CA can become inactive for the purposes of issuing new credentials
>without necessarily invalidating the certificates already issued.

The specific question referred to a CA certificate that was expiring. If the CA certificate expires, then the certificates under that certificate (absent a re-signed replacement) are invalid by definition - or am I missing your point?

Mike
Sill, Alan
2011-02-17 02:34:47 UTC
Permalink
On Feb 16, 2011, at 7:58 PM, "Michael StJohns" <***@comcast.net> wrote:

> At 08:47 PM 2/16/2011, Alan Sill wrote:
>> A CA can become inactive for the purposes of issuing new credentials
>> without necessarily invalidating the certificates already issued.
>
> The specific question referred to a CA certificate that was expiring. If the CA certificate expires, then the certificates under that certificate (absent a re-signed replacement) are invalid by definition - or am I missing your point?
>
> Mike

Mike,

Yes, with respect, you're missing my point. The user or relying party has no way of determining that your CA is no longer in existence. The CRL server can convey information about the revoked certificates you have issued from it previously, if any, and properly written relying party services will fail to accept any certificates from your current or previously existing CA at any time beyond the last "Next Update" time of your most recently fetched CRL, but otherwise no one actually communicates with your CA itself to verify its existence. They don't need to, as the public key that they already have for your CA, along with that of the certificate, are all that they need to check that the cryptography of the certificate is valid.

Hope this helps,

Alan
Sill, Alan
2011-02-17 02:38:15 UTC
Permalink
On Feb 16, 2011, at 7:58 PM, "Michael StJohns" <***@comcast.net> wrote:

> At 08:47 PM 2/16/2011, Alan Sill wrote:
>> A CA can become inactive for the purposes of issuing new credentials
>> without necessarily invalidating the certificates already issued.
>
> The specific question referred to a CA certificate that was expiring. If the CA certificate expires, then the certificates under that certificate (absent a re-signed replacement) are invalid by definition - or am I missing your point?
>
> Mike

Woops -- you're right; if the CA certificate itself has expired, then the question is of course moot.

Sorry, I missed that in the original question.

Alan
Roberto Opazo
2011-02-17 03:44:43 UTC
Permalink
Well, the real situation is... Next Monday the CA certificate expires
after 10 years of work. So CA certificate has not been expired yet and
we have a little time to take some decisions.

This is the first time for us on these situation. Next time is going
to be in 20 years, so I expect there will be and standard way to
finish CA live at that time.

Have anybody an experience to share?

How have other CAs ended?

I think using a 24 hours valid period for the last CRL is not good
choice. For instance, the next year a relaying party (RP) could try to
validate a valid signature (like an XML signed last week) and the RP
will get and expired CRL, I mean a CRL whit "Next Update" field
expired. RP would have to note than "Next Update" is pointing to a
date out of the CA's certificate validity period and assume that is
the reason why there are no other CRL and then, decide to trust in an
expired CRL. I think there are no many sw with this logic on the
marked.

That's why I prefer Rus recommendation, but I think It would be nice
having an RFC with a sentence like "CAs conforming to this profile
MUST create a final CRL with 99991231235959Z on "Next Update" field.

After all, Rus is a guru to me, but I can't say to others "Rus told me
to...". So I will have to repeat Rus argument, but It's not the same
when it's me or the company I work for, the person saying that.

Best regards,

Roberto Opazo

2011/2/16 Sill, Alan <***@ttu.edu>:
>
>
>
>
> On Feb 16, 2011, at 7:58 PM, "Michael StJohns" <***@comcast.net> wrote:
>
>> At 08:47 PM 2/16/2011, Alan Sill wrote:
>>> A CA can become inactive for the purposes of issuing new credentials
>>> without necessarily invalidating the certificates already issued.
>>
>> The specific question referred to a CA certificate that was expiring.  If the CA certificate expires, then the certificates under that certificate (absent a re-signed replacement) are invalid by definition - or am I missing your point?
>>
>> Mike
>
> Woops -- you're right; if the CA certificate itself has expired, then the question is of course moot.
>
> Sorry, I missed that in the original question.
>
> Alan
> _______________________________________________
> pkix mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
>



--
Saludos,

Roberto Opazo
Sill, Alan
2011-02-17 04:12:59 UTC
Permalink
On Feb 16, 2011, at 9:45 PM, "Roberto Opazo" <***@opazo.cl> wrote:

> I think using a 24 hours valid period for the last CRL is not good
> choice. For instance, the next year a relaying party (RP) could try to
> validate a valid signature (like an XML signed last week) and the RP
> will get and expired CRL, I mean a CRL whit "Next Update" field
> expired. RP would have to note than "Next Update" is pointing to a
> date out of the CA's certificate validity period and assume that is
> the reason why there are no other CRL and then, decide to trust in an
> expired CRL.

Any correctly implemented RP software would fail to validate any certificate from a CA with an expired CA certificate, or any certificate at all from a CA that has a most recent "Next Update" in the past. Itdoes no good to second-guess conditions under which a RP would trust a cert that they cannot check for possible revocation.
Miller, Timothy J.
2011-02-17 14:06:05 UTC
Permalink
On Feb 16, 2011, at 10:12 PM, Sill, Alan wrote:

> Any correctly implemented RP software would fail to validate any certificate from a CA with an expired CA certificate, or any certificate at all from a CA that has a most recent "Next Update" in the past.

ITYM CRL instead of CA; only CRLs have nextUpdate.

That said, you're incorrect. CRLs don't expire. CRLs only go stale. A relying party that uses a stale CRLs increases its risk of accepting revoked certs, but they remain valid statements from the CA. It *is* common for RPs to *interpret* netUpdate as a "CRL expiry" date, but it is most certainly not correct to do so. In fact, in some operational scenarios (e.g., intermittently connected networks) this interpretation causes denial-of-service.

-- Tim
Russ Housley
2011-02-17 14:46:11 UTC
Permalink
Alan:

>> I think using a 24 hours valid period for the last CRL is not good
>> choice. For instance, the next year a relaying party (RP) could try to
>> validate a valid signature (like an XML signed last week) and the RP
>> will get and expired CRL, I mean a CRL whit "Next Update" field
>> expired. RP would have to note than "Next Update" is pointing to a
>> date out of the CA's certificate validity period and assume that is
>> the reason why there are no other CRL and then, decide to trust in an
>> expired CRL.
>
> Any correctly implemented RP software would fail to validate any certificate from a CA with an expired CA certificate, or any certificate at all from a CA that has a most recent "Next Update" in the past. Itdoes no good to second-guess conditions under which a RP would trust a cert that they cannot check for possible revocation.

If the CA certificate has been installed as a trust anchor, then the expiration time in the self-signed certificate has no role in the certification path validation.

Russ
Paul Hoffman
2011-02-17 16:30:11 UTC
Permalink
On 2/17/11 6:46 AM, Russ Housley wrote:
> If the CA certificate has been installed as a trust anchor, then the expiration time in the self-signed certificate has no role in the certification path validation.

Exactly. The previous replies on this thread that said that a relying
party would not validate a certificate that used this CA either were
thinking that the CA was an intermediate CA or were forgetting the PKIX
trust anchor model from section 6.1 of 5280.

Given this, I think Russ' second answer is the correct one:

>Another reasonable choice would be a date just after the expiration of
every certificate issued by the CA. This will not disrupt certificates
that are supposed to be valid, and the CRL will also have an end-of-life.

This allows the no-longer-used CA to still revoke certificates, such as
if there is a key compromise on an end-entity certificate that happens
even after the CA is no longer expected to be used.
Miller, Timothy J.
2011-02-17 16:58:28 UTC
Permalink
On Feb 17, 2011, at 10:30 AM, Paul Hoffman wrote:

> Exactly. The previous replies on this thread that said that a relying
> party would not validate a certificate that used this CA either were
> thinking that the CA was an intermediate CA or were forgetting the PKIX
> trust anchor model from section 6.1 of 5280.

Good point. But then again, many (most?) extant implementations make the same error.

-- T
Paul Hoffman
2011-02-17 17:27:26 UTC
Permalink
On 2/17/11 8:58 AM, Miller, Timothy J. wrote:
> On Feb 17, 2011, at 10:30 AM, Paul Hoffman wrote:
>
>> Exactly. The previous replies on this thread that said that a relying
>> party would not validate a certificate that used this CA either were
>> thinking that the CA was an intermediate CA or were forgetting the PKIX
>> trust anchor model from section 6.1 of 5280.
>
> Good point. But then again, many (most?) extant implementations make the same error.

It is not an error, it is a policy decision based on erroneous
understanding of PKIX. :-) Seriously, though, because many extant
implementations do *not* make that error^Wpolicy decision, the answer to
the question that started this thread should be to deal with both types
of systems and to continue to set the "next update" to a date when a
next update can be expected. If the CA has decided to never do a next
update, use the forever-ish standard for notAfter; otherwise, be honest
and say when you think you might update the CRL again.
Stefan Santesson
2011-02-22 14:39:32 UTC
Permalink
Back to the original topic, I lack the dimension of whether the CA that is
being closed has issued certificates that are still valid.

If there are no valid issued certificates, the issue seems obsolete. Just
close the shop. It's fine if the last CRL has a next-update indicating the
date of death, either of the CA or the last issued certificate.

If there are some certificates still valid and you are closing the CA
anyway, then there is something not entirely right. You either need to
renew the CA or invalidate the still valid certificates.

To in such case set a distant CRL next update time and close the shop
seems to be a confusing solution as it ignores the need for future
revocation and fails to provide a valid CA certificate for the "valid"
issued certificates.

/Stefan

On 11-02-17 6:27 PM, "Paul Hoffman" <***@vpnc.org> wrote:

>On 2/17/11 8:58 AM, Miller, Timothy J. wrote:
>> On Feb 17, 2011, at 10:30 AM, Paul Hoffman wrote:
>>
>>> Exactly. The previous replies on this thread that said that a relying
>>> party would not validate a certificate that used this CA either were
>>> thinking that the CA was an intermediate CA or were forgetting the PKIX
>>> trust anchor model from section 6.1 of 5280.
>>
>> Good point. But then again, many (most?) extant implementations make
>>the same error.
>
>It is not an error, it is a policy decision based on erroneous
>understanding of PKIX. :-) Seriously, though, because many extant
>implementations do *not* make that error^Wpolicy decision, the answer to
>the question that started this thread should be to deal with both types
>of systems and to continue to set the "next update" to a date when a
>next update can be expected. If the CA has decided to never do a next
>update, use the forever-ish standard for notAfter; otherwise, be honest
>and say when you think you might update the CRL again.
>_______________________________________________
>pkix mailing list
>***@ietf.org
>https://www.ietf.org/mailman/listinfo/pkix
Michael StJohns
2011-02-18 01:17:23 UTC
Permalink
At 09:46 AM 2/17/2011, Russ Housley wrote:
>If the CA certificate has been installed as a trust anchor, then the expiration time in the self-signed certificate has no role in the certification path validation.

Is that true in reality? The typical trust anchor in a browser is a self-signed cert. I'd have to check, but I'm pretty sure chaining fails if the self-signed cert has expired.

Mike
Russ Housley
2011-02-18 01:46:22 UTC
Permalink
Mike:

>> If the CA certificate has been installed as a trust anchor, then the expiration time in the self-signed certificate has no role in the certification path validation.
>
> Is that true in reality? The typical trust anchor in a browser is a self-signed cert. I'd have to check, but I'm pretty sure chaining fails if the self-signed cert has expired.

Browsers do this check, but nothing in RFC 5280 (or RFC 3280, or RFC 2459) imposes this requirement.

Russ
Michael StJohns
2011-02-18 02:18:14 UTC
Permalink
At 08:46 PM 2/17/2011, Russ Housley wrote:
>Mike:
>
>>> If the CA certificate has been installed as a trust anchor, then the expiration time in the self-signed certificate has no role in the certification path validation.
>>
>> Is that true in reality? The typical trust anchor in a browser is a self-signed cert. I'd have to check, but I'm pretty sure chaining fails if the self-signed cert has expired.
>
>Browsers do this check, but nothing in RFC 5280 (or RFC 3280, or RFC 2459) imposes this requirement.
>
>Russ


Which is kind of funny because a number of implementations treat the nextUpdate field as a CRL expiration date - and that's doesn't appear to be the processing recommended by 5280.

I started researching this and found at least three implementations have either a fixed or configurable behavior which treats ALL certs under a CA as invalid if they don't receive a new CRL before the nextUpdate date. At least one of these implementations does not have this behavior if it sees a CRL without the nextUpdate field - but 5280 requires CRLs to have the field.

Section 6.3.3 of 5280 is fairly silent on what to do if you don't have the most recent CRL - I read it that certs not on the CRLs that are in your posession have the status of "UNDETERMINED".

Is it time for a BCP on Certs as Trust Anchors and/or Cert Acceptance Policies given incomplete CRL information?

Mike
Sill, Alan
2011-02-18 02:39:47 UTC
Permalink
On Feb 17, 2011, at 8:18 PM, "Michael StJohns" <***@comcast.net> wrote:

> At 08:46 PM 2/17/2011, Russ Housley wrote:
>> Mike:
>>
>>>> If the CA certificate has been installed as a trust anchor, then the expiration time in the self-signed certificate has no role in the certification path validation.
>>>
>>> Is that true in reality? The typical trust anchor in a browser is a self-signed cert. I'd have to check, but I'm pretty sure chaining fails if the self-signed cert has expired.
>>
>> Browsers do this check, but nothing in RFC 5280 (or RFC 3280, or RFC 2459) imposes this requirement.
>>
>> Russ
>
>
> Which is kind of funny because a number of implementations treat the nextUpdate field as a CRL expiration date - and that's doesn't appear to be the processing recommended by 5280.
>
> I started researching this and found at least three implementations have either a fixed or configurable behavior which treats ALL certs under a CA as invalid if they don't receive a new CRL before the nextUpdate date. At least one of these implementations does not have this behavior if it sees a CRL without the nextUpdate field - but 5280 requires CRLs to have the field.
>
> Section 6.3.3 of 5280 is fairly silent on what to do if you don't have the most recent CRL - I read it that certs not on the CRLs that are in your posession have the status of "UNDETERMINED".
>
> Is it time for a BCP on Certs as Trust Anchors and/or Cert Acceptance Policies given incomplete CRL information?
>
> Mike
>

This is exactly what I tried to point out earlier. It is surely up to each relying party, but all production infrastructure implementationd of which I am aware treat things this way: if a CRL is not available after the time of the "next update" value of the most current one expires, then no certificates from that CA are considered valid. And despite answers to the contrary given by others on this list, I can't think of any popular implementationd that will accept EE certs from a CA after the expiration of the CA cert, either.
Kemp, David P.
2011-02-18 14:30:38 UTC
Permalink
> I started researching this and found at least three
> implementations have either a fixed or configurable
> behavior which treats ALL certs under a CA as invalid
> if they don't receive a new CRL before the nextUpdate date.

That is particularly broken behavior, akin to running your car out of
gas every time and walking to the gas station with a can to get some
more. For CAs that do not issue unscheduled CRLs, there is no way to
receive a new CRL before the nextUpdate date, so the application fails
at the end of every CRL waiting until the new CRL can be issued and
retrieved. The workaround (forcing CAs to lie about nextUpdate so that
broken applications won't fail) is repulsive - the point of standards is
to enable parties that follow the standard to work correctly.

Dave


-----Original Message-----
From: pkix-***@ietf.org [mailto:pkix-***@ietf.org] On Behalf Of
Sill, Alan
Sent: Thursday, February 17, 2011 9:40 PM
To: Michael StJohns
Cc: IETF PKIX
Subject: Re: [pkix] What should be in "Next Update" field of the last
CRL?





On Feb 17, 2011, at 8:18 PM, "Michael StJohns" <***@comcast.net>
wrote:

> At 08:46 PM 2/17/2011, Russ Housley wrote:
>> Mike:
>>
>>>> If the CA certificate has been installed as a trust anchor, then
the expiration time in the self-signed certificate has no role in the
certification path validation.
>>>
>>> Is that true in reality? The typical trust anchor in a browser is a
self-signed cert. I'd have to check, but I'm pretty sure chaining fails
if the self-signed cert has expired.
>>
>> Browsers do this check, but nothing in RFC 5280 (or RFC 3280, or RFC
2459) imposes this requirement.
>>
>> Russ
>
>
> Which is kind of funny because a number of implementations treat the
nextUpdate field as a CRL expiration date - and that's doesn't appear to
be the processing recommended by 5280.
>
> I started researching this and found at least three implementations
have either a fixed or configurable behavior which treats ALL certs
under a CA as invalid if they don't receive a new CRL before the
nextUpdate date. At least one of these implementations does not have
this behavior if it sees a CRL without the nextUpdate field - but 5280
requires CRLs to have the field.
>
> Section 6.3.3 of 5280 is fairly silent on what to do if you don't have
the most recent CRL - I read it that certs not on the CRLs that are in
your posession have the status of "UNDETERMINED".
>
> Is it time for a BCP on Certs as Trust Anchors and/or Cert Acceptance
Policies given incomplete CRL information?
>
> Mike
>

This is exactly what I tried to point out earlier. It is surely up to
each relying party, but all production infrastructure implementationd of
which I am aware treat things this way: if a CRL is not available after
the time of the "next update" value of the most current one expires,
then no certificates from that CA are considered valid. And despite
answers to the contrary given by others on this list, I can't think of
any popular implementationd that will accept EE certs from a CA after
the expiration of the CA cert, either.
Stefan Santesson
2011-02-22 15:29:37 UTC
Permalink
In reality this is even worse.

There are clearly real situations where the RP need to have both an expiry
date (Don't use this CRL after..) and a date when the next update is
available.

Since most applications treat nextUpdate as the expiry date, and in order
to stay compliant with these implementations, Microsoft defined the
private extension "nextIssue", expressing the expected date when a new CRL
should be available.

The motivation AFAIK was to allow applications (understanding the private
extension) to start caching the new CRL (which sometimes can be quite big)
in the background before the current CRL expires and thus allow a smooth
user experience, not having to wait for 50 MB CRL downloads on CRL
transitions. At the same time allowing standards compliant implementations
to work without breaking.

I don't promote this for standardization. This is just an example of what
happens when people tries to deal with real issues.

/Stefan



On 11-02-18 3:30 PM, "Kemp, David P." <***@missi.ncsc.mil> wrote:

>> I started researching this and found at least three
>> implementations have either a fixed or configurable
>> behavior which treats ALL certs under a CA as invalid
>> if they don't receive a new CRL before the nextUpdate date.
>
>That is particularly broken behavior, akin to running your car out of
>gas every time and walking to the gas station with a can to get some
>more. For CAs that do not issue unscheduled CRLs, there is no way to
>receive a new CRL before the nextUpdate date, so the application fails
>at the end of every CRL waiting until the new CRL can be issued and
>retrieved. The workaround (forcing CAs to lie about nextUpdate so that
>broken applications won't fail) is repulsive - the point of standards is
>to enable parties that follow the standard to work correctly.
>
>Dave
>
>
>-----Original Message-----
>From: pkix-***@ietf.org [mailto:pkix-***@ietf.org] On Behalf Of
>Sill, Alan
>Sent: Thursday, February 17, 2011 9:40 PM
>To: Michael StJohns
>Cc: IETF PKIX
>Subject: Re: [pkix] What should be in "Next Update" field of the last
>CRL?
>
>
>
>
>
>On Feb 17, 2011, at 8:18 PM, "Michael StJohns" <***@comcast.net>
>wrote:
>
>> At 08:46 PM 2/17/2011, Russ Housley wrote:
>>> Mike:
>>>
>>>>> If the CA certificate has been installed as a trust anchor, then
>the expiration time in the self-signed certificate has no role in the
>certification path validation.
>>>>
>>>> Is that true in reality? The typical trust anchor in a browser is a
>self-signed cert. I'd have to check, but I'm pretty sure chaining fails
>if the self-signed cert has expired.
>>>
>>> Browsers do this check, but nothing in RFC 5280 (or RFC 3280, or RFC
>2459) imposes this requirement.
>>>
>>> Russ
>>
>>
>> Which is kind of funny because a number of implementations treat the
>nextUpdate field as a CRL expiration date - and that's doesn't appear to
>be the processing recommended by 5280.
>>
>> I started researching this and found at least three implementations
>have either a fixed or configurable behavior which treats ALL certs
>under a CA as invalid if they don't receive a new CRL before the
>nextUpdate date. At least one of these implementations does not have
>this behavior if it sees a CRL without the nextUpdate field - but 5280
>requires CRLs to have the field.
>>
>> Section 6.3.3 of 5280 is fairly silent on what to do if you don't have
>the most recent CRL - I read it that certs not on the CRLs that are in
>your posession have the status of "UNDETERMINED".
>>
>> Is it time for a BCP on Certs as Trust Anchors and/or Cert Acceptance
>Policies given incomplete CRL information?
>>
>> Mike
>>
>
>This is exactly what I tried to point out earlier. It is surely up to
>each relying party, but all production infrastructure implementationd of
>which I am aware treat things this way: if a CRL is not available after
>the time of the "next update" value of the most current one expires,
>then no certificates from that CA are considered valid. And despite
>answers to the contrary given by others on this list, I can't think of
>any popular implementationd that will accept EE certs from a CA after
>the expiration of the CA cert, either.
>
>
>_______________________________________________
>pkix mailing list
>***@ietf.org
>https://www.ietf.org/mailman/listinfo/pkix
>_______________________________________________
>pkix mailing list
>***@ietf.org
>https://www.ietf.org/mailman/listinfo/pkix
Stephen Kent
2011-02-23 04:26:48 UTC
Permalink
At 4:29 PM +0100 2/22/11, Stefan Santesson wrote:
>In reality this is even worse.
>
>There are clearly real situations where the RP need to have both an expiry
>date (Don't use this CRL after..) and a date when the next update is
>available.

yes, that would be nice, but I do not recall anyone proposing an extension
to carry the first data (with a nicer name :-)).

>
>Since most applications treat nextUpdate as the expiry date, and in order
>to stay compliant with these implementations, Microsoft defined the
>private extension "nextIssue", expressing the expected date when a new CRL
>should be available.

This is an unfortunate name, as the next update value is the next
issue date :-). I appreciate the motivation, but ...

The next update value is like a "best is used before" date, analogous
to what one sees on perishable products. You don't HAVE to consume
the product before that date, but you may get a stomach ache if you
consume it too long afterwards :-).

Steve
Stefan Santesson
2011-02-23 07:05:46 UTC
Permalink
From: Stephen Kent <***@bbn.com>
Date: Tue, 22 Feb 2011 23:26:48 -0500
To: Stefan Santesson <***@aaa-sec.com>
Cc: "Kemp, David P." <***@missi.ncsc.mil>, "Sill, Alan"
<***@ttu.edu>, Michael StJohns <***@comcast.net>, IETF PKIX
<***@ietf.org>
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
>
> This is an unfortunate name, as the next update value is the next issue date
> :-). I appreciate the motivation, but ...
>
> The next update value is like a "best is used before" date, analogous to what
> one sees on perishable products. You don't HAVE to consume the product before
> that date, but you may get a stomach ache if you consume it too long
> afterwards :-).

Yes, that all sound logical. However on a practical ground that is quite
hard to code into a crypto API. There you need more distinct rules and
predictable outcome. It would of course have been more clean if they defined
a private "notValidAfter" extension, but that would not have produced the
outcome they needed.

To standardize on such extension may however be the least evil thing to do.

/Stefan
Thomas Pornin
2011-02-23 14:04:23 UTC
Permalink
On Wed, 2011-02-23 at 08:05 +0100, Stefan Santesson wrote:
> Yes, that all sound logical. However on a practical ground that is
> quite hard to code into a crypto API. There you need more distinct
> rules and predictable outcome.

I second that. Theoretically, each RP would decide, according to its own
arbitrary policy, whether a given CRL is fresh enough. But the rules for
appropriate freshness depend upon the context and are likely to be
CA-specific. Revocation is mostly a kind of damage containment: a way to
"cancel" an existing certificate, even though the signature on the
certificate is cryptographically verifiable, in order to cope with an
unfortunate occurrence, e.g. a key compromise. The revocation
information freshness is a measure of the time-wise extent of the issue:
by accepting a week-old CRL, the RP effectively accepts the risk that it
could be fooled into using a public key which has been compromised
during the last week.

How much freshness is needed ? It really depends on the procedures
deployed by the CA to detect the revocation-implying occurrences, and
how fast it can publish revocation information. Those procedures are
normally described in the Certification Policy Statement of the CA, and
supposedly are compatible with the CPS of the CA's CA, and so on.
Ultimately, this leads to the trust anchor's CPS; however, the TA CPS is
not necessarily precise about applicable freshness for all CA which it
has directly or indirectly issued.

One point of PKI (maybe _the_ point of PKI) is to be able to validate
links between public keys and identities, for an arbitrary large set of
identities and public keys, using a small, fixed set of a priori known
information (the trust anchors). We want to be able to validate
certificates issued by intermediate CA about which we had no prior
knowledge. We cannot have CA-specific knowledge for all possible CA.
Hence, the policy which a RP will use to decide CRL freshness must feed
on whatever CA-specific information it can get hold of, and the only
validated sources it can get, in all generality, are the CA certificate
and the CRL itself (and the CRL issuer certificate, if distinct from the
CA). Whatever CPS say in human language, the validation process is,
ultimately, executed by a computer, which needs Turing-compatible rules.

Using the nextUpdate field as an end-of-validity date is not incorrect.
This is certainly allowed by RFC 5280; if the freshness-decision is a
matter of local policy, that local policy can certainly be: "use
nextUpdate as an end-of-validity date". RFC 5280 even hints at that
usage, in the 6.3.3 section ("CRL Processing"): it is said that the
"local CRL cache" should be updated with a "current CRL" if the
nextUpdate field of the most recent CRL is in the past (RFC 5280 does
not tell what should be done if such an update fails). Moreover, using
the nextUpdate as end-of-validity is not a bad policy, as policies go:
basically, it is the policy known as: "issuing CA knows best". Since
appropriate freshness is CA-specific, it makes sense to follow the rules
used by the CA. Ideally, the CA would publish the CRL end-of-validity
date, which should be at some date after the nextUpdate (there should be
no date without a valid CRL at all): the nextUpdate is a lower bound for
the CRL end-of-validity. If more extensive information is not available,
then the best that can be done is to use the nextUpdate as an
approximation of the end-of-validity.

The point, here, is that whatever entity implements the certificate
validation process needs information, which must be:
1. processable by a computer;
2. CA-specific, for CA which the RP might not have been aware of
beforehand.
As I see it, given the current state of standard certificate and CRL
extensions, the nextUpdate field is the only information source that can
be used for that. This does not prevent other freshness policies from
being also correct in the RFC 5280 sense, and possibly appropriate
(although the widespread policy known as "meh, no need to check, it is
probably not revoked anyway" kind of stretches my notion of "appropriate
freshness check"). But the "nextUpdate as end-of-validity" policy is a
good policy, or, at least, as good as a generic policy can get in that
matter.


> To standardize on such extension may however be the least evil thing
> to do.

As I explain above, such an extension is a way for the CA to make a
statement about what freshness measure is appropriate for the procedures
that it applies to decide about the revocation status. It is a good
thing (as long as the CA does not botch it by publishing an
end-of-validity date which is _before_ the nextUpdate).

"Standardize" is an important word. In many usages of validation, we not
only want to have a validation process which yields a trustworthy
answer; we also want it to yield the same trustworthy answer than for
other people. For instance, in the context of a signed contract, I want
my system to accept the contract as signed only if a judge, applying
validation on the same signature, would also declare it as valid and
binding. Right now, this entails using nextUpdate as an end-of-validity
date because, whether you like it or not, that's what everybody does.


--Thomas Pornin
Stephen Kent
2011-02-24 01:42:52 UTC
Permalink
At 9:04 AM -0500 2/23/11, Thomas Pornin wrote:
>On Wed, 2011-02-23 at 08:05 +0100, Stefan Santesson wrote:
>> Yes, that all sound logical. However on a practical ground that is
>> quite hard to code into a crypto API. There you need more distinct
>> rules and predictable outcome.
>
>I second that. Theoretically, each RP would decide, according to its own
>arbitrary policy, whether a given CRL is fresh enough. But the rules for
>appropriate freshness depend upon the context and are likely to be
>CA-specific. Revocation is mostly a kind of damage containment: a way to
>"cancel" an existing certificate, even though the signature on the
>certificate is cryptographically verifiable, in order to cope with an
>unfortunate occurrence, e.g. a key compromise.

Although often cited as such, many folks have found that the principle
reason for revocation is not key compromise, but rather the change of
the value of some attribute in the cert.

>The revocation
>information freshness is a measure of the time-wise extent of the issue:
>by accepting a week-old CRL, the RP effectively accepts the risk that it
>could be fooled into using a public key which has been compromised
>during the last week.
>
>How much freshness is needed ? It really depends on the procedures
>deployed by the CA to detect the revocation-implying occurrences, and
>how fast it can publish revocation information. Those procedures are
>normally described in the Certification Policy Statement of the CA, and
>supposedly are compatible with the CPS of the CA's CA, and so on.
>Ultimately, this leads to the trust anchor's CPS; however, the TA CPS is
>not necessarily precise about applicable freshness for all CA which it
>has directly or indirectly issued.

The question of how fresh is fresh enough is purely an RP decision.
Also, while a careful reading of a CPS can help an RP decide what
might be the right freshness value on a per CA basis, this might
impose a serious configuration management burden if an RP deals with
a lot of different CAs. So I think we are heading down a serious rat
hole here.

>One point of PKI (maybe _the_ point of PKI) is to be able to validate
>links between public keys and identities, for an arbitrary large set of
>identities and public keys, using a small, fixed set of a priori known
>information (the trust anchors).

not always true. see the RPKI in the SIDR WG for a counter example, i.e.,
cert identities are mot relevant in that PKI.

>...

I agree that an RP can elect to treat the next update value as an
expiration date, because the RP can do anything that it wants in this
regard. But, I believe that RPs are not getting the option to make
this decision. Instead, SW used by RPs are unilaterally interpreting
the next update value this way, and not allowing the RP to choose
otherwise. That's not good.

Steve
Russ Housley
2011-02-23 14:37:25 UTC
Permalink
>> There are clearly real situations where the RP need to have both an expiry
>> date (Don't use this CRL after..) and a date when the next update is
>> available.
>
> yes, that would be nice, but I do not recall anyone proposing an extension
> to carry the first data (with a nicer name :-)).
>
>>
>> Since most applications treat nextUpdate as the expiry date, and in order
>> to stay compliant with these implementations, Microsoft defined the
>> private extension "nextIssue", expressing the expected date when a new CRL
>> should be available.
>
> This is an unfortunate name, as the next update value is the next issue date :-). I appreciate the motivation, but ...
>
> The next update value is like a "best is used before" date, analogous to what one sees on perishable products. You don't HAVE to consume the product before that date, but you may get a stomach ache if you consume it too long afterwards :-).

I am aware of applications that expect the new CRL to be posted by the nextUpdate, but allow a grace time for it to published and distributed. This seems like a reasonable approach since there are not separate next publication and expiration times.

Russ
Roberto Opazo
2011-02-23 19:34:52 UTC
Permalink
I think this thread is mixing two different point:

* How should a RP interpret Next Update field in a CRL? Is it an
expiration date?

* What should be en Next Update field in the last CRL? This scenario
is different than the previous one because there is not going to be
any next CRL in any time. There are many choices here and I really
think that's a problem. If there would not be so many applications
already in the market I would recommend a NULL value. But
unfortunately, I think making a choice is hurter than that. No choice
is going to be perfect, but there should be only one way to fill Next
Update field of the last CRL.

Best regards,

Roberto Opazo


2011/2/23 Russ Housley <***@vigilsec.com>:
>
>>> There are clearly real situations where the RP need to have both an expiry
>>> date (Don't use this CRL after..) and a date when the next update is
>>> available.
>>
>> yes, that would be nice, but I do not recall anyone proposing an extension
>> to carry the first data (with a nicer name :-)).
>>
>>>
>>> Since most applications treat nextUpdate as the expiry date, and in order
>>> to stay compliant with these implementations, Microsoft defined the
>>> private extension "nextIssue", expressing the expected date when a new CRL
>>> should be available.
>>
>> This is an unfortunate name, as the next update value is the next issue date :-). I appreciate the motivation, but ...
>>
>> The next update value is like a "best is used before" date, analogous to what one sees on perishable products. You don't HAVE to consume the product before that date, but you may get a stomach ache if you consume it too long afterwards :-).
>
> I am aware of applications that expect the new CRL to be posted by the nextUpdate, but allow a grace time for it to published and distributed.  This seems like a reasonable approach since there are not separate next publication and expiration times.
>
> Russ
>
> _______________________________________________
> pkix mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
>



--
Saludos,

Roberto Opazo
Kemp, David P.
2011-02-23 22:22:23 UTC
Permalink
"If a tree falls in an empty forest, does it make a sound"?

If there are no valid certificates (because either or both of the CA certificate and the EE certificate have expired), does it matter what goes into nextUpdate of the last CRL issued by the CA? There are indeed many choices, but all of them yield the identical result - an expired certificate is not valid. For that reason the simplest choice (filling nextUpdate with the same value it would have had if the CA were not expiring) seems best.

Because no choice has any effect (other than perhaps confusing apps with unexpected magic values), I don't agree that the standard needs to specify only one. 40 years ago when electrical engineers (the original EEs) were doing Karnaugh maps, we would have called nextUpdate an "X" (don't care) input.



-----Original Message-----
From: pkix-***@ietf.org [mailto:pkix-***@ietf.org] On Behalf Of Roberto Opazo
Sent: Wednesday, February 23, 2011 2:35 PM
To: IETF PKIX
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?

I think this thread is mixing two different point:

* How should a RP interpret Next Update field in a CRL? Is it an
expiration date?

* What should be en Next Update field in the last CRL? This scenario
is different than the previous one because there is not going to be
any next CRL in any time. There are many choices here and I really
think that's a problem. If there would not be so many applications
already in the market I would recommend a NULL value. But
unfortunately, I think making a choice is hurter than that. No choice
is going to be perfect, but there should be only one way to fill Next
Update field of the last CRL.

Best regards,

Roberto Opazo


2011/2/23 Russ Housley <***@vigilsec.com>:
>
>>> There are clearly real situations where the RP need to have both an expiry
>>> date (Don't use this CRL after..) and a date when the next update is
>>> available.
>>
>> yes, that would be nice, but I do not recall anyone proposing an extension
>> to carry the first data (with a nicer name :-)).
>>
>>>
>>> Since most applications treat nextUpdate as the expiry date, and in order
>>> to stay compliant with these implementations, Microsoft defined the
>>> private extension "nextIssue", expressing the expected date when a new CRL
>>> should be available.
>>
>> This is an unfortunate name, as the next update value is the next issue date :-). I appreciate the motivation, but ...
>>
>> The next update value is like a "best is used before" date, analogous to what one sees on perishable products. You don't HAVE to consume the product before that date, but you may get a stomach ache if you consume it too long afterwards :-).
>
> I am aware of applications that expect the new CRL to be posted by the nextUpdate, but allow a grace time for it to published and distributed.  This seems like a reasonable approach since there are not separate next publication and expiration times.
>
> Russ
>
> _______________________________________________
> pkix mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
>



--
Saludos,

Roberto Opazo
Thomas Pornin
2011-02-23 22:38:11 UTC
Permalink
On Wed, 2011-02-23 at 17:22 -0500, Kemp, David P. wrote:
> For that reason the simplest choice (filling nextUpdate with the same value it would have had if the CA were not expiring) seems best.

Also, using the same nextUpdate rules helps quite a lot if, one or two
days after having issued the "last" CRL, someone decides that the CA
should not be closed after all, and reissues the certificate using the
same name and public key, and new validity dates. The simplest choice is
also the choice which entails the lowest risk.


--Thomas Pornin
Henry B. Hotz
2011-02-24 00:27:06 UTC
Permalink
There's the digital signature use case. You want to know that the EE and CA(s) were valid at the time the document was signed, and you want to know that nobody has subsequently compromised them either.

On Feb 23, 2011, at 2:22 PM, Kemp, David P. wrote:

> "If a tree falls in an empty forest, does it make a sound"?
>
> If there are no valid certificates (because either or both of the CA certificate and the EE certificate have expired), does it matter what goes into nextUpdate of the last CRL issued by the CA? There are indeed many choices, but all of them yield the identical result - an expired certificate is not valid. For that reason the simplest choice (filling nextUpdate with the same value it would have had if the CA were not expiring) seems best.
>
> Because no choice has any effect (other than perhaps confusing apps with unexpected magic values), I don't agree that the standard needs to specify only one. 40 years ago when electrical engineers (the original EEs) were doing Karnaugh maps, we would have called nextUpdate an "X" (don't care) input.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
***@jpl.nasa.gov, or ***@oxy.edu
Paul Hoffman
2011-02-24 00:31:31 UTC
Permalink
On 2/23/11 4:27 PM, Henry B. Hotz wrote:
> There's the digital signature use case. You want to know that the EE and CA(s) were valid at the time the document was signed, and you want to know that nobody has subsequently compromised them either.

No, you know that the key was not known by the CA to be compromised
before the certificate expired. That's a big difference.
Henry B. Hotz
2011-02-24 00:56:27 UTC
Permalink
On Feb 23, 2011, at 4:31 PM, Paul Hoffman wrote:

> On 2/23/11 4:27 PM, Henry B. Hotz wrote:
>> There's the digital signature use case. You want to know that the EE and CA(s) were valid at the time the document was signed, and you want to know that nobody has subsequently compromised them either.
>
> No, you know that the key was not known by the CA to be compromised
> before the certificate expired. That's a big difference.

Yes, it is. However I'm talking about what a verifier wants to know, not what a likely CRL implementation will actually tell me. That there is "a big difference" is an unfortunate state of affairs.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
***@jpl.nasa.gov, or ***@oxy.edu
Stephen Kent
2011-02-24 04:02:49 UTC
Permalink
At 4:27 PM -0800 2/23/11, Henry B. Hotz wrote:
>There's the digital signature use case. You want to know that the
>EE and CA(s) were valid at the time the document was signed, and you
>want to know that nobody has subsequently compromised them either.
>

For non-repudiation purposes, the RP should have acquired the CRL(s)
issued for the relevant cert(s) immediately after the time of the
transaction in question. Also, the transaction, and the certs and
CRLs, should be time-stamped by a TSA. For more details, see the
LTANS WG RFCs.

Steve
Andrea Caccia
2011-02-24 09:40:09 UTC
Permalink
Il giorno 24/feb/2011, alle ore 05.02, Stephen Kent ha scritto:

> At 4:27 PM -0800 2/23/11, Henry B. Hotz wrote:
>> There's the digital signature use case. You want to know that the EE and CA(s) were valid at the time the document was signed, and you want to know that nobody has subsequently compromised them either.
>>
>
> For non-repudiation purposes, the RP should have acquired the CRL(s) issued for the relevant cert(s) immediately after the time of the transaction in question. Also, the transaction, and the certs and CRLs, should be time-stamped by a TSA. For more details, see the LTANS WG RFCs.

Possibly 2 CRLs as "immediately after the time of the transaction" the CA could not had time to revoke the cert.
For this reason, it there are still valid issued certificates the last CRL should be issued at the time the CA cert expires or even after if there are revocations not processed.

In case there are valid certificates the safest way (not necessarily the best for all perspectives) would be to revoke all valid certificates with a revocation date = CA cert expiration.

Andrea Caccia
Stephen Kent
2011-02-24 10:04:34 UTC
Permalink
At 10:40 AM +0100 2/24/11, Andrea Caccia wrote:
>Il giorno 24/feb/2011, alle ore 05.02, Stephen Kent ha scritto:
>
>> At 4:27 PM -0800 2/23/11, Henry B. Hotz wrote:
>>> There's the digital signature use case. You want to know that
>>>the EE and CA(s) were valid at the time the document was signed,
>>>and you want to know that nobody has subsequently compromised them
>>>either.
>>>
>>
>> For non-repudiation purposes, the RP should have acquired the
>>CRL(s) issued for the relevant cert(s) immediately after the time
>>of the transaction in question. Also, the transaction, and the
>>certs and CRLs, should be time-stamped by a TSA. For more details,
>>see the LTANS WG RFCs.
>
>Possibly 2 CRLs as "immediately after the time of the transaction"
>the CA could not had time to revoke the cert.

If a transaction occurs at time T, and a CRL is issued at T+delta,
and if the CPS for the CA says that it processes all revocation
requests in less than delta
time, one CRL should suffice. It may not be reasonable for an RP to wait for
multiple CRL intervals to consider a transaction safe, depdnding on
the frequency of issuance of CRLs, the CPS details, etc.


>For this reason, it there are still valid issued certificates the
>last CRL should be issued at the time the CA cert expires or even
>after if there are revocations not processed.

If the public key from the CA cert is used to verify the CRL, a CRL
signed by the CA after the CA's cert expires probably ought not be
verifiable.


>In case there are valid certificates the safest way (not necessarily
>the best for all perspectives) would be to revoke all valid
>certificates with a revocation date = CA cert expiration.

probably a bit before the CA cert expiration date, for the reasons I
cited above.

Steve
Miller, Timothy J.
2011-02-24 13:25:42 UTC
Permalink
On Feb 24, 2011, at 4:04 AM, Stephen Kent wrote:

> If a transaction occurs at time T, and a CRL is issued at T+delta,
> and if the CPS for the CA says that it processes all revocation
> requests in less than delta
> time, one CRL should suffice. It may not be reasonable for an RP to wait for
> multiple CRL intervals to consider a transaction safe, depdnding on
> the frequency of issuance of CRLs, the CPS details, etc.

I think you have to figure in epsilon, which I'll define as "the time the CA CP/CPS defines as the maximum reporting window." IOW, if the CP says the CA will process revocation requests hourly and publish a CRL immediately *and* requires Subscribers to report lost or suspected compromised key material within 72 hours, then the CRL you want is the CRL published at T+73h rather than T+1h.

OTOH, a CP that permits retroactive revocation (revocation request at time T for claimed time T-n) can really mess up your day.

This is why we pay lawyers. :)

-- T
Stephen Kent
2011-02-28 14:53:47 UTC
Permalink
At 8:25 AM -0500 2/24/11, Miller, Timothy J. wrote:
>On Feb 24, 2011, at 4:04 AM, Stephen Kent wrote:
>
>> If a transaction occurs at time T, and a CRL is issued at T+delta,
>> and if the CPS for the CA says that it processes all revocation
>> requests in less than delta
>> time, one CRL should suffice. It may not be reasonable for an RP
>>to wait for
>> multiple CRL intervals to consider a transaction safe, depdnding on
>> the frequency of issuance of CRLs, the CPS details, etc.
>
>I think you have to figure in epsilon, which I'll define as "the
>time the CA CP/CPS defines as the maximum reporting window." IOW,
>if the CP says the CA will process revocation requests hourly and
>publish a CRL immediately *and* requires Subscribers to report lost
>or suspected compromised key material within 72 hours, then the CRL
>you want is the CRL published at T+73h rather than T+1h.

good point.

>OTOH, a CP that permits retroactive revocation (revocation request
>at time T for claimed time T-n) can really mess up your day.

and is a violation of the fundamental notion of CRL semantics :-). yes, there
is a CRL extension to express the notion of "I wish I had revoked
this previously" but we don't support it in 5280, right?

Steve
Santosh Chokhani
2011-02-28 15:17:54 UTC
Permalink
Steve,

As to your last comment, 5280 Section 5.3.2 does describe invalidity date.

-----Original Message-----
From: pkix-***@ietf.org [mailto:pkix-***@ietf.org] On Behalf Of Stephen Kent
Sent: Monday, February 28, 2011 9:54 AM
To: Miller, Timothy J.
Cc: IETF PKIX
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?

At 8:25 AM -0500 2/24/11, Miller, Timothy J. wrote:
>On Feb 24, 2011, at 4:04 AM, Stephen Kent wrote:
>
>> If a transaction occurs at time T, and a CRL is issued at T+delta,
>> and if the CPS for the CA says that it processes all revocation
>> requests in less than delta
>> time, one CRL should suffice. It may not be reasonable for an RP
>>to wait for
>> multiple CRL intervals to consider a transaction safe, depdnding on
>> the frequency of issuance of CRLs, the CPS details, etc.
>
>I think you have to figure in epsilon, which I'll define as "the
>time the CA CP/CPS defines as the maximum reporting window." IOW,
>if the CP says the CA will process revocation requests hourly and
>publish a CRL immediately *and* requires Subscribers to report lost
>or suspected compromised key material within 72 hours, then the CRL
>you want is the CRL published at T+73h rather than T+1h.

good point.

>OTOH, a CP that permits retroactive revocation (revocation request
>at time T for claimed time T-n) can really mess up your day.

and is a violation of the fundamental notion of CRL semantics :-). yes, there
is a CRL extension to express the notion of "I wish I had revoked
this previously" but we don't support it in 5280, right?

Steve
Stephen Kent
2011-02-28 16:43:00 UTC
Permalink
At 10:17 AM -0500 2/28/11, Santosh Chokhani wrote:
>Steve,
>
>As to your last comment, 5280 Section 5.3.2 does describe invalidity date.
>

That's a pity; it's a bad idea and I thought we deprecated it. Guess
another one slipped through :-).

Steve
Santosh Chokhani
2011-02-28 18:38:26 UTC
Permalink
Steve,

Why do you think it is a bad idea?

-----Original Message-----
From: Stephen Kent [mailto:***@bbn.com]
Sent: Monday, February 28, 2011 11:43 AM
To: Santosh Chokhani
Cc: Miller, Timothy J.; IETF PKIX
Subject: RE: [pkix] What should be in "Next Update" field of the last CRL?

At 10:17 AM -0500 2/28/11, Santosh Chokhani wrote:
>Steve,
>
>As to your last comment, 5280 Section 5.3.2 does describe invalidity date.
>

That's a pity; it's a bad idea and I thought we deprecated it. Guess
another one slipped through :-).

Steve
Stephen Kent
2011-02-28 21:46:55 UTC
Permalink
At 1:38 PM -0500 2/28/11, Santosh Chokhani wrote:
>Steve,
>
>Why do you think it is a bad idea?
>

because it legitimizes the notion of "whoops, I should have revoked this
earlier, but I'm telling you now," i.e., a CRL "mulligan."

For NR purposes, an RP needs to know by which time it can acquire and
archive a CRL for future reference, in case of a dispute. As others
have noted, we did not
make this potentially useful info available in machine readable form,
i.e., in an extension. So, absent that capability, I think the
feature in question is of marginal use.

An RP that knows that it needs to wait for a specified interval for
issuance of a CRL that will, once and for all, allow the RP to act on
a transaction does not benefit from this "feature" if the cert in
question is not revoked. If the cert is retroactively revoked, but
after the transaction date, then there is utility. But, it is not
clear how often this situation arises, and thus whether it is worth
the added complexity and confusion caused by the feature.

Steve
Santosh Chokhani
2011-03-01 00:12:04 UTC
Permalink
Steve,

The pro of having this feature is that archival of CRL provides you with something useful for investigatory purposes.

-----Original Message-----
From: Stephen Kent [mailto:***@bbn.com]
Sent: Monday, February 28, 2011 4:47 PM
To: Santosh Chokhani
Cc: Miller, Timothy J.; IETF PKIX
Subject: RE: [pkix] What should be in "Next Update" field of the last CRL?

At 1:38 PM -0500 2/28/11, Santosh Chokhani wrote:
>Steve,
>
>Why do you think it is a bad idea?
>

because it legitimizes the notion of "whoops, I should have revoked this
earlier, but I'm telling you now," i.e., a CRL "mulligan."

For NR purposes, an RP needs to know by which time it can acquire and
archive a CRL for future reference, in case of a dispute. As others
have noted, we did not
make this potentially useful info available in machine readable form,
i.e., in an extension. So, absent that capability, I think the
feature in question is of marginal use.

An RP that knows that it needs to wait for a specified interval for
issuance of a CRL that will, once and for all, allow the RP to act on
a transaction does not benefit from this "feature" if the cert in
question is not revoked. If the cert is retroactively revoked, but
after the transaction date, then there is utility. But, it is not
clear how often this situation arises, and thus whether it is worth
the added complexity and confusion caused by the feature.

Steve
Stefan Santesson
2011-03-05 00:11:46 UTC
Permalink
On this issue I would agree with Santosh.

This information is not useful (in any way I can think of) when validating
a certificate. If not present it obviously has no function. If present it
is always prior to revocation date. However it may be connected to the
certificate policy with respect to liability statements. Especially in
closed community applications.

/Stefan





On 11-03-01 1:12 AM, "Santosh Chokhani" <***@cygnacom.com> wrote:

>Steve,
>
>The pro of having this feature is that archival of CRL provides you with
>something useful for investigatory purposes.
>
>-----Original Message-----
>From: Stephen Kent [mailto:***@bbn.com]
>Sent: Monday, February 28, 2011 4:47 PM
>To: Santosh Chokhani
>Cc: Miller, Timothy J.; IETF PKIX
>Subject: RE: [pkix] What should be in "Next Update" field of the last CRL?
>
>At 1:38 PM -0500 2/28/11, Santosh Chokhani wrote:
>>Steve,
>>
>>Why do you think it is a bad idea?
>>
>
>because it legitimizes the notion of "whoops, I should have revoked this
>earlier, but I'm telling you now," i.e., a CRL "mulligan."
>
>For NR purposes, an RP needs to know by which time it can acquire and
>archive a CRL for future reference, in case of a dispute. As others
>have noted, we did not
>make this potentially useful info available in machine readable form,
>i.e., in an extension. So, absent that capability, I think the
>feature in question is of marginal use.
>
>An RP that knows that it needs to wait for a specified interval for
>issuance of a CRL that will, once and for all, allow the RP to act on
>a transaction does not benefit from this "feature" if the cert in
>question is not revoked. If the cert is retroactively revoked, but
>after the transaction date, then there is utility. But, it is not
>clear how often this situation arises, and thus whether it is worth
>the added complexity and confusion caused by the feature.
>
>Steve
>_______________________________________________
>pkix mailing list
>***@ietf.org
>https://www.ietf.org/mailman/listinfo/pkix
Jacob Dilles
2011-02-24 15:58:27 UTC
Permalink
On Feb 23, 2011, at 5:22 PM, Kemp, David P. wrote:

If there are no valid certificates (because either or both of the CA certificate and the EE certificate have expired), does it matter what goes into nextUpdate of the last CRL issued by the CA? There are indeed many choices, but all of them yield the identical result - an expired certificate is not valid. For that reason the simplest choice (filling nextUpdate with the same value it would have had if the CA were not expiring) seems best.

Because no choice has any effect (other than perhaps confusing apps with unexpected magic values), I don't agree that the standard needs to specify only one. 40 years ago when electrical engineers (the original EEs) were doing Karnaugh maps, we would have called nextUpdate an "X" (don't care) input.

I think the point of the IETF is to write complete specifications - that is, one's without "don't care" inputs. Specification SHOULD discourage the use of magic values in any field, but especially one that that might be used to "reduce the amount of work" an implementation must do in validation. Leaving aspects of interoperability to the imagination of developers, even if it shouldn't matter, is typically a bad idea.

BTW,


"If a tree falls in an empty forest, does it make a sound"?

Assuming:
- "Tree" implies respiration of CO2->02+C via ambient gaseous atmosphere consisting of at least those elements, with one or more leaves consisting of a solid matrix holding the necessities for said respiration.
- "Falls" implies some sort of force, e.g. gravity, which accelerates said tree through said atmosphere.
- "Sound" implies a compression wave traveling through said gaseous atmosphere.
Then yes. A solid object with non-zero velocity relative to a gaseous atmosphere will generate a compression wave.
Roberto Opazo
2011-02-24 16:21:46 UTC
Permalink
> Because no choice has any effect (other than perhaps confusing apps with unexpected magic values), I don't agree that the standard needs to specify only one.

Choices has effects, no matter if you see it or not.

Right now, if you put a 24 more hour time in Next Update of the last
CRL, you will have problems validating signatures than wore generated
when certificates were valid, but are been validated after the time
you put on Next Update field of the last CRL.

Magic values create confusion, that is why I think standards should
have a reference for this special situation.

---

Best regards,

Roberto Opazo
Miller, Timothy J.
2011-02-24 17:27:42 UTC
Permalink
On Feb 24, 2011, at 10:21 AM, Roberto Opazo wrote:

> Right now, if you put a 24 more hour time in Next Update of the last
> CRL, you will have problems validating signatures than wore generated
> when certificates were valid, but are been validated after the time
> you put on Next Update field of the last CRL.

Signature validation after certificate expiry is a *special case* that's already covered. You validate using the CRL valid at the *time of signing*, not the final CRL from the PKI.

This is why secure time stamping is so important. Else you introduce the question of "what time was it signed?"

-- T
Stefan Santesson
2011-02-28 16:10:29 UTC
Permalink
On 11-02-24 6:27 PM, "Miller, Timothy J." <***@mitre.org> wrote:

>On Feb 24, 2011, at 10:21 AM, Roberto Opazo wrote:
>
>> Right now, if you put a 24 more hour time in Next Update of the last
>> CRL, you will have problems validating signatures than wore generated
>> when certificates were valid, but are been validated after the time
>> you put on Next Update field of the last CRL.
>
>Signature validation after certificate expiry is a *special case* that's
>already covered. You validate using the CRL valid at the *time of
>signing*, not the final CRL from the PKI.
>
>This is why secure time stamping is so important. Else you introduce the
>question of "what time was it signed?"


This in essence is the correct answer to the original question.
A last CRL issued after certificate expiry is not relevant for validating
that certificate. Unless the CRL includes the expired certificates on CRL
extension (not supported by RFC 5280), the certificate you are looking for
may not be listed in that CRL. Yet it may have been revoked.

/Stefan
David A. Cooper
2011-02-24 17:33:27 UTC
Permalink
_______________________________________________
pkix mailing list
***@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Denis Pinkas
2011-02-25 12:59:59 UTC
Permalink
We are far away from the original topic...
A minor correction to the text:
The text states:
"In this scenario, the relying party needs to find a CRL with thisUpdate and nextUpdate times that satisfy these two criteria".
The first criteria is not correctly stated:
"The CRL is sufficiently recent relative to the time the signature was generated.
As previously described in this thread, the meaning of "sufficiently recent" may depend on the application."
Proposed rewording:
" The nextUpdate field of the CRL is sufficiently later than the time the signature was time-stamped
(since you never know when the signature was generated)".
Denis

----- Message reçu -----
De : pkix-bounces
À : Roberto Opazo
Date : 2011-02-24, 18:33:27
Sujet : Re: [pkix] What should be in "Next Update" field of the last CRL?


The issue that you raise has nothing to do with the value of nextUpdate in the last CRL. X.509 defines the Validity field (notBefore and notAfter) in a certificate as follows:

validity is the time interval during which the CA warrants that
it will maintain information about the status of the certificate.

You cannot use the same process to determine whether a certificate was valid at some time in the past (e.g., when a signature was generated) that you use to determine whether a certificate is currently valid, particularly if the certificate has already expired.

The problem in the scenario that you describe below isn't the value of nextUpdate in the last CRL, it is the validation procedure that you think relying parties may use. The relying party in this scenario should not be comparing the nextUpdate time in the CRL to the current time. In this scenario, the relying party needs to find a CRL with thisUpdate and nextUpdate times that satisfy these two criteria:

1) The CRL is sufficiently recent relative to the time the signature was generated. As previously described in this thread, the meaning of "sufficiently recent" may depend on the application. It may mean a CRL with a nextUpdate time that is later than the time the signature was generated (even if the thisUpdate time was before the signature was generated) or it may mean a CRL with a thisUpdate time that is long enough after the signature generation time to allow for any potential key compromise to have been reported and processed.

2) The CRL must either have a thisUpdate time that is before the notAfter time in the certificate or have an expiredCertsOnCRL extension that specifies a time that is before the notAfter time in the certificate. (The expiredCertsOnCRL extension indicates that the CRL includes revocation status for certificates that expired on or after the time specified in the extension.) If neither of these conditions are satisfied, then the CRL may not include status information for the certificate.

Consider a scenario similar to the one you describe, but in which the CA is not at the end of its life. A subscriber generates a signature two days before his or her certificate expires, a relying party wishes to validate this signature 3 days after the certificate expires, and the CA issues CRLs once a day with nextUpdate times that are 24 hours after the thisUpdate times. If the relying party insisted on using a CRL with a nextUpdate time that is after the current time, the only such CRL available would be one that was issued after the certificate expired. Such a CRL may not provide status information for the certificate since it had already expired before the CRL was issued, and so cannot be used to verify that the certificate had not been revoked.

Similarly, if a CA that was getting ready to shut down issued its last CRL shortly after the final certificate that it had issued had expired, this CRL could be empty since a CRL only needs to list revoked certificates that have not yet expired. So again, this last CRL could not be used to determine whether a certificate was valid at some time in the past before it expired, regardless of the value of nextUpdate in the CRL.

In either case, the relying party will not be able to obtain a CRL with a nextUpate time that is after the current time that can be relied upon to indicate whether the certificate had been revoked before it expired.

On 02/24/2011 11:21 AM, Roberto Opazo wrote:
Because no choice has any effect (other than perhaps confusing apps with unexpected magic values), I don't agree that the standard needs to specify only one.

Choices has effects, no matter if you see it or not.

Right now, if you put a 24 more hour time in Next Update of the last
CRL, you will have problems validating signatures than wore generated
when certificates were valid, but are been validated after the time
you put on Next Update field of the last CRL.

Magic values create confusion, that is why I think standards should
have a reference for this special situation.

---

Best regards,

Roberto Opazo
Stephen Kent
2011-02-24 01:02:01 UTC
Permalink
At 4:34 PM -0300 2/23/11, Roberto Opazo wrote:
>I think this thread is mixing two different point:
>
>* How should a RP interpret Next Update field in a CRL? Is it an
>expiration date?

the short answers is NO, it it not an expiration date, even if a lot
of folks have misinterpreted it as such.

>* What should be en Next Update field in the last CRL? This scenario
>is different than the previous one because there is not going to be
>any next CRL in any time. There are many choices here and I really
>think that's a problem. If there would not be so many applications
>already in the market I would recommend a NULL value. But
>unfortunately, I think making a choice is hurter than that. No choice
>is going to be perfect, but there should be only one way to fill Next
>Update field of the last CRL.
>
>Best regards,
>
>Roberto Opazo

You have received several suggestions based on other aspects of the
EOL of the CA, e.g., whether there are subordinate certs that will
still be valid, whether the certs are used for auth vs.
non-repudiaiton, etc. So there is not one, right answer for all of
these contexts. Also, since the problem you raise also is made worse
by folks misinterpreting the standards re next update, it is not
clear what a standards body ought to do.

Steve
Mike Helm
2011-02-18 20:56:07 UTC
Permalink
"Sill, Alan" writes:
> This is exactly what I tried to point out earlier. It is surely up
> to each relying party, but all production infrastructure
> implementationd of which I am aware treat things this way: if a CRL
> is not available after the time of the "next update" value of the
> most current one expires, then no certificates from that CA are
> considered valid.

(One of ) the guilty party/ies here is openssl, so the problem
is both more widespread than the infrastructure we support,
and not completely that infrastructure's fault. openssl has some
other crl quirks, at least some versions do.


The idea is very widespread, tho. I think I remember it was
part of a security PKI checklist that NIST provided - I don't have
a copy of it any more & I don't know that it reached final publication
in NIST. However many PKI specialists also seem to believe this
is the correct behavior. I suppose it could be considered
correct behavior in the right framing, I wish it wasn't,
but it seems we have to treat it so.

Thanks, ==mwh
Michael Helm
ESnet/LBNL
Michael StJohns
2011-02-20 02:42:24 UTC
Permalink
*sigh*

http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/PKITS.pdf

Items 4.4.11 and 4.4.12.

Somewhere the idea that "undetermined" equaled "not validated" crept into the process rather than being treated as a per acceptor policy decision.

Mike








At 03:56 PM 2/18/2011, Mike Helm wrote:
>"Sill, Alan" writes:
>> This is exactly what I tried to point out earlier. It is surely up
>> to each relying party, but all production infrastructure
>> implementationd of which I am aware treat things this way: if a CRL
>> is not available after the time of the "next update" value of the
>> most current one expires, then no certificates from that CA are
>> considered valid.
>
>(One of ) the guilty party/ies here is openssl, so the problem
>is both more widespread than the infrastructure we support,
>and not completely that infrastructure's fault. openssl has some
>other crl quirks, at least some versions do.
>
>
>The idea is very widespread, tho. I think I remember it was
>part of a security PKI checklist that NIST provided - I don't have
>a copy of it any more & I don't know that it reached final publication
>in NIST. However many PKI specialists also seem to believe this
>is the correct behavior. I suppose it could be considered
>correct behavior in the right framing, I wish it wasn't,
>but it seems we have to treat it so.
>
>Thanks, ==mwh
>Michael Helm
>ESnet/LBNL
David A. Cooper
2011-02-22 17:39:36 UTC
Permalink
_______________________________________________
pkix mailing list
***@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Michael StJohns
2011-02-22 19:03:35 UTC
Permalink
Hi David -

Issue isn't 4.4, but 4.4.11 and 4.4.12 text which says:

>Expected Result: The path should not validate successfully since the status of the end
>entity's certificate can not be determined.

without reference back to the text you cite.

It's true that 4.4 has the "local decision to treat the CRL as being sufficiently up-to-date", but the "should not validate successfully" in the test text is going to be or was what gets/got implemented. Testable criteria always wins...

Mike


At 12:39 PM 2/22/2011, David A. Cooper wrote:
>As the author of <http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/PKITS.pdf>http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/PKITS.pdf, I would like to note that it was not the intention of this test suite to imply that nextUpdate must be treated as an expiration date for a CRL. Version 1.0 of PKITS came out in September 2004, and the CRLs for tests 4.4.11 and 4.4.12 had nextUpdate times of January 2002 and January 1999, respectively. An application could be configured to allow for a CRL to be used after its nextUpdate time had passed, as long as it verified that the nextUpdate time was not too far in the past, and still get the correct results for the tests, and that was intentional.
>
>Section 4.4 of that document contains the introduction to the basic certificate revocation tests and it says:
>
>The application must be able to retrieve valid revocation data for each certificate in the path. For a CRL to be considered to contain valid revocation data for a certificate, the CRL must at a minimum: (1) be signed by the issuer of the certificate or by an entity that has been authorized by the certificate issuer to provide status information for the certificate; (2) have a scope that includes the certificate of interest; and (3) be sufficiently up-to-date.
>
>In general, if the current time is before the time specified in the nextUpdate field of a CRL, then that CRL should be considered sufficiently up-to-date since the CRL issuer has indicated that this CRL may contain the most up-to-date information available. Similarly, if the current time is after the time specified in the nextUpdate field of a CRL, then the CRL should not be considered to be sufficiently up-to-date since the CRL issuer has indicated that more up-to-date information should be available.
>
>Even if the current time is after the time specified in the nextUpdate field of a CRL, an application may still make a local decision to treat the CRL as being sufficiently up-to-date. The
>application may, for example, be configurable to allow CRLs to be treated as sufficiently up-to-date, even if the current time is after the nextUpdate time, if the CRL was issued recently (e.g., the user or administrator configuring the system could indicate that a CRL may be used as long as the current time is within 72 hours of the thisUpdate time in the CRL, no matter how frequently the CRL issuer chooses to issue CRLs).
>
>In this section, there are only two tests in which the nextUpdate time in a CRL is before the current time. In each case, the nextUpdate time (and thisUpdate time) is more than two years before the current time. So, it is expected that applications will be configured so that these CRLs are not considered to be sufficiently up-to-date.
>
>Even if an application is unable to find valid revocation data (that is considered to be sufficiently up-to-date) for every certificate in the path, the application may still make a local decision to use the certification path. The application may, for example, allow the user or an administrator to configure the application to ignore the unavailability of revocation data. In the case of an interactive application, the application may display a warning to the user and then allow the user to decide whether to proceed to use the certification path despite the lack of revocation data. However, the application may not be designed in such a way that the unavailability of revocation data is always ignored, whether the user (or administrator) wants the application to behave that way or not. When running the tests in this section, the application should be configured in such a way that the certification path is not accepted unless valid, up-to-date revocation data is available for every certificate in the path. Thus, when run in this configuration, when the application is unable to find valid, up-to-date revocation data for every certificate in the path, the application must either reject the certification path or at least display a warning to the user indicating that the status of the certificate can not be determined.
>
>
>
>Dave
>
>On 02/19/2011 09:42 PM, Michael StJohns wrote:
>>
>>*sigh*
>>
>><http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/PKITS.pdf>http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/PKITS.pdf
>>
>>Items 4.4.11 and 4.4.12.
>>
>>Somewhere the idea that "undetermined" equaled "not validated" crept into the process rather than being treated as a per acceptor policy decision.
>>
>>Mike
>>
>>At 03:56 PM 2/18/2011, Mike Helm wrote:
>>
>>>
>>>"Sill, Alan" writes:
>>>
>>>>
>>>> This is exactly what I tried to point out earlier. It is surely up
>>>>to each relying party, but all production infrastructure
>>>>implementationd of which I am aware treat things this way: if a CRL
>>>>is not available after the time of the "next update" value of the
>>>>most current one expires, then no certificates from that CA are
>>>>considered valid.
>>>>
>>>
>>>
>>>(One of ) the guilty party/ies here is openssl, so the problem
>>>is both more widespread than the infrastructure we support,
>>>and not completely that infrastructure's fault. openssl has some
>>>other crl quirks, at least some versions do.
>>>
>>>
>>>The idea is very widespread, tho. I think I remember it was
>>>part of a security PKI checklist that NIST provided - I don't have
>>>a copy of it any more & I don't know that it reached final publication
>>>in NIST. However many PKI specialists also seem to believe this
>>>is the correct behavior. I suppose it could be considered
>>>correct behavior in the right framing, I wish it wasn't,
>>>but it seems we have to treat it so.
>>>
>>>Thanks, ==mwh
>>>Michael Helm
>>>ESnet/LBNL
>>>
David A. Cooper
2011-02-22 22:18:56 UTC
Permalink
_______________________________________________
pkix mailing list
***@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Michael StJohns
2011-02-23 03:25:13 UTC
Permalink
At 05:18 PM 2/22/2011, David A. Cooper wrote:
>Mike,
>
>I don't understand your point. These tests don't involve CRLs with nextUpdate times are a few hours or days in the past, they involve CRLs with nextUpdate times that are several years in the past.


This (how old is too old) isn't going to be all that visible from a testing POV - all the tester knows is that the last known CRL is stale - later than the nextUpdate time. There's no discussion in 4.4.11 of how late is too late (even though 4.4 notes the CRLs are at least 2 years out of date). So for 4.4.11 and 4.4.12 it doesn't matter whether the CRL is 1 day out of currency or 10 years. Indeed, the text of 4.4.11 simply says "CRL has a nextUpdateTime that is in the past". Also, as I read it, 4.4.12 was a "pre 2000" test - or more simply a Y2K completeness test.


> If "should not validate successfully" is an acceptable outcome for tests such as 4.4.1and 4.4.4, where no valid CRL is available, then why isn't is also an acceptable outcome for tests 4.4.11 and 4.4.12, where the only CRLs that are available are so out-of-date?

In neither case is this acceptable always. In both it should be a matter of configuration. E.g. a CA may choose not to issue a CRL *ever* making 4.4.1s assumption that a missing CRL means the cert is invalid overreaching.


>Conforming CAs are not required to issue CRLs if other revocation or
> certificate status mechanisms are provided.


> If an application is configured to reject a certification path when some revocation information is missing, should it accept a certification path if some of the revocation information is out-of-date by several years? What's wrong with implementing "should not validate successfully" for these tests?

Because that's not what 3280 or 5280 says (and they are both silent on that as near as I can tell). It's also not PKITS.pdf seems to test.

See above. Each of these test cases should have noted that the testing was against a specific assumption - that CRLs are mandatory and that if the CRL is stale then all certificates are invalid - and should have noted that the acceptor could configure an alternate acceptance model. The fact these cases were stated as an absolute probably led to various implementations making similar absolute choices.

Mike



>Dave
>
>On 02/22/2011 02:03 PM, Michael StJohns wrote:
>>Hi David -
>>
>>Issue isn't 4.4, but 4.4.11 and 4.4.12 text which says:
>>
>>>Expected Result: The path should not validate successfully since the status of the end
>>>entity's certificate can not be determined.
>>
>>without reference back to the text you cite.
>>
>>It's true that 4.4 has the "local decision to treat the CRL as being sufficiently up-to-date", but the "should not validate successfully" in the test text is going to be or was what gets/got implemented. Testable criteria always wins...
>>
>>Mike
>>
>>
>>At 12:39 PM 2/22/2011, David A. Cooper wrote:
>>>As the author of <http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/PKITS.pdf>http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/PKITS.pdf, I would like to note that it was not the intention of this test suite to imply that nextUpdate must be treated as an expiration date for a CRL. Version 1.0 of PKITS came out in September 2004, and the CRLs for tests 4.4.11 and 4.4.12 had nextUpdate times of January 2002 and January 1999, respectively. An application could be configured to allow for a CRL to be used after its nextUpdate time had passed, as long as it verified that the nextUpdate time was not too far in the past, and still get the correct results for the tests, and that was intentional.
>>>
>>>Section 4.4 of that document contains the introduction to the basic certificate revocation tests and it says:
>>>
>>>The application must be able to retrieve valid revocation data for each certificate in the path. For a CRL to be considered to contain valid revocation data for a certificate, the CRL must at a minimum: (1) be signed by the issuer of the certificate or by an entity that has been authorized by the certificate issuer to provide status information for the certificate; (2) have a scope that includes the certificate of interest; and (3) be sufficiently up-to-date.
>>>In general, if the current time is before the time specified in the nextUpdate field of a CRL, then that CRL should be considered sufficiently up-to-date since the CRL issuer has indicated that this CRL may contain the most up-to-date information available. Similarly, if the current time is after the time specified in the nextUpdate field of a CRL, then the CRL should not be considered to be sufficiently up-to-date since the CRL issuer has indicated that more up-to-date information should be available.
>>>
>>>Even if the current time is after the time specified in the nextUpdate field of a CRL, an application may still make a local decision to treat the CRL as being sufficiently up-to-date. The
>>>application may, for example, be configurable to allow CRLs to be treated as sufficiently up-to-date, even if the current time is after the nextUpdate time, if the CRL was issued recently (e.g., the user or administrator configuring the system could indicate that a CRL may be used as long as the current time is within 72 hours of the thisUpdate time in the CRL, no matter how frequently the CRL issuer chooses to issue CRLs).
>>>In this section, there are only two tests in which the nextUpdate time in a CRL is before the current time. In each case, the nextUpdate time (and thisUpdate time) is more than two years before the current time. So, it is expected that applications will be configured so that these CRLs are not considered to be sufficiently up-to-date.
>>>Even if an application is unable to find valid revocation data (that is considered to be sufficiently up-to-date) for every certificate in the path, the application may still make a local decision to use the certification path. The application may, for example, allow the user or an administrator to configure the application to ignore the unavailability of revocation data. In the case of an interactive application, the application may display a warning to the user and then allow the user to decide whether to proceed to use the certification path despite the lack of revocation data. However, the application may not be designed in such a way that the unavailability of revocation data is always ignored, whether the user (or administrator) wants the application to behave that way or not. When running the tests in this section, the application should be configured in such a way that the certification path is not accepted unless valid, up-to-date revocation data is available for every certificate in the path. Thus, when run in this configuration, when the application is unable to find valid, up-to-date revocation data for every certificate in the path, the application must either reject the certification path or at least display a warning to the user indicating that the status of the certificate can not be determined.
>>>
>>>
>>>
>>>Dave
>>>
>>>On 02/19/2011 09:42 PM, Michael StJohns wrote:
>>>>
>>>>
>>>>*sigh*
>>>>
>>>>
>>>>http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/PKITS.pdf
>>>>
>>>>Items 4.4.11 and 4.4.12.
>>>>
>>>>Somewhere the idea that "undetermined" equaled "not
>>>>validated" crept into the process rather than being treated as a per
>>>>acceptor policy decision.
>>>>
>>>>Mike
>>>>
>>>>At 03:56 PM 2/18/2011, Mike Helm wrote:
>>>>
>>>>
>>>>>
>>>>>
>>>>>"Sill, Alan" writes:
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> This is exactly what I tried to point out earlier. It is
>>>>>>surely up
>>>>>>to each relying party, but all production infrastructure
>>>>>>implementationd of which I am aware treat things this way: if a CRL
>>>>>>is not available after the time of the "next update" value of
>>>>>>the
>>>>>>most current one expires, then no certificates from that CA are
>>>>>>considered valid.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>(One of ) the guilty party/ies here is openssl, so the problem
>>>>>is both more widespread than the infrastructure we support,
>>>>>and not completely that infrastructure's fault. openssl has some
>>>>>other crl quirks, at least some versions do.
>>>>>
>>>>>
>>>>>The idea is very widespread, tho. I think I remember it was
>>>>>part of a security PKI checklist that NIST provided - I don't have
>>>>>a copy of it any more & I don't know that it reached final
>>>>>publication
>>>>>in NIST. However many PKI specialists also seem to believe this
>>>>>is the correct behavior. I suppose it could be considered
>>>>>correct behavior in the right framing, I wish it wasn't,
>>>>>but it seems we have to treat it so.
>>>>>
>>>>>Thanks, ==mwh
>>>>>Michael Helm
>>>>>ESnet/LBNL
>>>>>
Kemp, David P.
2011-02-25 15:50:17 UTC
Permalink
-----Original Message-----
From: pkix-***@ietf.org [mailto:pkix-***@ietf.org] On Behalf Of
Michael StJohns

> It's true that 4.4 has the "local decision to treat
> the CRL as being sufficiently up-to-date", but the
> "should not validate successfully" in the test text
> is going to be or was what gets/got implemented.
> Testable criteria always wins...
>
> Mike


Agree completely.

Years ago when the Microsoft extension was discussed here, an
alternative proposal (an extension carrying the CA's preferred value of
epsilon, the time after nextUpdate at which a CRL should be considered
expired) was also discussed. Even in the absence of such an extension,
it would have been nice if the PKI test suite had included an
RP-configurable value of epsilon. Passing the test would require
applications to support accepting certs while in possession of a CRL
that is "fresh enough" after nextUpdate while rejecting certs if no CRL
is fresh enough.

But that's water under the bridge now, unless the test suite is ever
updated.

Dave
Tom Gindin
2011-02-18 23:36:35 UTC
Permalink
In a practical sense, if nextUpdate is taken literally an RP
should not expect to see a fresh CRL in the first few seconds after it
because publication is not instantaneous. So an RP can't really use that
field as a CRL expiration time to fine granularity. Treating nextUpdate
+ gracePeriod as an expiration, with a brief grace period (perhaps less
than an hour) is far likelier to work.

Tom Gindin

P.S. This is my opinion, and not necessarily that of my employer.




From:
Michael StJohns <***@comcast.net>
To:
Russ Housley <***@vigilsec.com>
Cc:
IETF PKIX <***@ietf.org>
Date:
02/17/2011 09:18 PM
Subject:
Re: [pkix] What should be in "Next Update" field of the last CRL?
Sent by:
pkix-***@ietf.org



At 08:46 PM 2/17/2011, Russ Housley wrote:
>Mike:
>
>>> If the CA certificate has been installed as a trust anchor, then the
expiration time in the self-signed certificate has no role in the
certification path validation.
>>
>> Is that true in reality? The typical trust anchor in a browser is a
self-signed cert. I'd have to check, but I'm pretty sure chaining fails
if the self-signed cert has expired.
>
>Browsers do this check, but nothing in RFC 5280 (or RFC 3280, or RFC
2459) imposes this requirement.
>
>Russ


Which is kind of funny because a number of implementations treat the
nextUpdate field as a CRL expiration date - and that's doesn't appear to
be the processing recommended by 5280.

I started researching this and found at least three implementations have
either a fixed or configurable behavior which treats ALL certs under a CA
as invalid if they don't receive a new CRL before the nextUpdate date. At
least one of these implementations does not have this behavior if it sees
a CRL without the nextUpdate field - but 5280 requires CRLs to have the
field.

Section 6.3.3 of 5280 is fairly silent on what to do if you don't have the
most recent CRL - I read it that certs not on the CRLs that are in your
posession have the status of "UNDETERMINED".

Is it time for a BCP on Certs as Trust Anchors and/or Cert Acceptance
Policies given incomplete CRL information?

Mike
Miller, Timothy J.
2011-02-17 14:01:45 UTC
Permalink
On Feb 16, 2011, at 9:44 PM, Roberto Opazo wrote:

> Well, the real situation is... Next Monday the CA certificate expires
> after 10 years of work. So CA certificate has not been expired yet and
> we have a little time to take some decisions.

Subscriber certs should have a notAfter date equal to the maximum validity period or the notAfter date of the issuer's certificate, *whichever is shorter*.

However, even this doesn't matter because subscriber certs are invalid when the CA cert expires no matter what notAfter date they assert. Any cert or CRL which claims dates past this date is moot.

"Proper" PKI planning would have each CA retire from active issuance but remain to issue CRLs until all subscriber certs have expired; this 'inactive' period is equal to the maximum validity period of the certs it issued. At that point the CA can simply be shut off (assuming you've archived all the artifacts you need for proving validity of historical signatures). This is an operational nicety rather than a technical one, as it's the only way to extract the full validity period for all issued certs; failure to do so means as the CA cert expiry time approaches the subscriber cert lifecycle gets shorter and shorter.

OTOH, you *could* simply resign the CA key, assuming you're OK with that key remaining in service. I don't recommend this option but I think it would technically work. As long as the SKID and Subject DN don't change, relying parties may still be able to build a valid chain.

-- Tim
Roberto Opazo
2011-02-17 14:58:19 UTC
Permalink
Tim:

> However, even this doesn't matter because subscriber certs are invalid when the CA
> cert expires no matter what notAfter date they assert. Any cert or CRL which claims
> dates past this date is moot.

After CA expiration date, it's still possible to need EE certificate
validation, not for a new SSL authentication, but for an electronic
document signed in the past, when the EE certificate was valid.

EE certificates expires, but electronic signatures persist and needs
to be validated.


2011/2/17 Miller, Timothy J. <***@mitre.org>:
> On Feb 16, 2011, at 9:44 PM, Roberto Opazo wrote:
>
>> Well, the real situation is... Next Monday the CA certificate expires
>> after 10 years of work. So CA certificate has not been expired yet and
>> we have a little time to take some decisions.
>
> Subscriber certs should have a notAfter date equal to the maximum validity period or the notAfter date of the issuer's certificate, *whichever is shorter*.
>
> However, even this doesn't matter because subscriber certs are invalid when the CA cert expires no matter what notAfter date they assert.  Any cert or CRL which claims dates past this date is moot.
>
> "Proper" PKI planning would have each CA retire from active issuance but remain to issue CRLs until all subscriber certs have expired; this 'inactive' period is equal to the maximum validity period of the certs it issued.  At that point the CA can simply be shut off (assuming you've archived all the artifacts you need for proving validity of historical signatures).  This is an operational nicety rather than a technical one, as it's the only way to extract the full validity period for all issued certs; failure to do so means as the CA cert expiry time approaches the subscriber cert lifecycle gets shorter and shorter.
>
> OTOH, you *could* simply resign the CA key, assuming you're OK with that key remaining in service.  I don't recommend this option but I think it would technically work.  As long as the SKID and Subject DN don't change, relying parties may still be able to build a valid chain.
>
> -- Tim
>
>
>



--
Saludos,

Roberto Opazo
David A. Cooper
2011-02-17 15:24:30 UTC
Permalink
Robert,

Yes, a relying party may wish to determine if an EE certificate was
valid at some time in the past, but such a relying party should not be
looking for a "current" CRL.

As has been noted, if a certificate has been revoked, its serial number
only needs to be included on CRLs issued before the certificate
expired. So, if a certificate expired 6 months ago, and a relying party
wants to know whether the certificate was valid a year ago when the
corresponding private key was used to sign a document, the relying party
would need to find a CRL that was issued at least 6 months ago. The
relying party may wish to check that the nextUpdate time in the CRL is
after the time that the signature was generated, but should not check
that the nextUpdate time in the CRL is after the current time, as in
most cases such a CRL would have been issued after the certificate
expired and so would not provide any information about the revocation
status of the certificate.

So, if all of the EE certificates issued by your CA expire no later than
February 21, 2011, it should be sufficient for the final CRL issued by
the CA to have a nextUpate time of February 22, 2011 (or some time on
February 21, 2011 that is later than the notAfter time in every
certificate issued by the CA). Such a CRL would work well for any
relying party trying to verify a certificate before its expiration, and
any relying party trying to verify a certificate after its revocation
wouldn't (or at least shouldn't) be comparing the nextUpdate time in the
CRL to the current time.

If the CA has issued certificates that expire after February 21, 2011,
then the situation is slightly more complicated, if the CA will shut
down and no longer issue CRLs after that date. The safe thing to do
would be to issue a final CRL with a nextUpdate time that is after the
expiration (notAfter) dates of all issued certificates that lists all of
the unexpired certificates as revoked. One could issue such a CRL that
does not list the unexpired certificates as revoked, but there is a risk
involved in that (if the CA that issued the certificates is used as a
trust anchor) since there would be no way to revoke these certificates
in the future if the need arose.

Dave

On 02/17/2011 09:58 AM, Roberto Opazo wrote:
> Tim:
>> However, even this doesn't matter because subscriber certs are invalid when the CA
>> cert expires no matter what notAfter date they assert. Any cert or CRL which claims
>> dates past this date is moot.
>>
> After CA expiration date, it's still possible to need EE certificate
> validation, not for a new SSL authentication, but for an electronic
> document signed in the past, when the EE certificate was valid.
>
> EE certificates expires, but electronic signatures persist and needs
> to be validated.
>
>
> 2011/2/17 Miller, Timothy J.<***@mitre.org>:
>
>> On Feb 16, 2011, at 9:44 PM, Roberto Opazo wrote:
>>
>>
>>> Well, the real situation is... Next Monday the CA certificate expires
>>> after 10 years of work. So CA certificate has not been expired yet and
>>> we have a little time to take some decisions.
>>>
>> Subscriber certs should have a notAfter date equal to the maximum validity period or the notAfter date of the issuer's certificate, *whichever is shorter*.
>>
>> However, even this doesn't matter because subscriber certs are invalid when the CA cert expires no matter what notAfter date they assert. Any cert or CRL which claims dates past this date is moot.
>>
>> "Proper" PKI planning would have each CA retire from active issuance but remain to issue CRLs until all subscriber certs have expired; this 'inactive' period is equal to the maximum validity period of the certs it issued. At that point the CA can simply be shut off (assuming you've archived all the artifacts you need for proving validity of historical signatures). This is an operational nicety rather than a technical one, as it's the only way to extract the full validity period for all issued certs; failure to do so means as the CA cert expiry time approaches the subscriber cert lifecycle gets shorter and shorter.
>>
>> OTOH, you *could* simply resign the CA key, assuming you're OK with that key remaining in service. I don't recommend this option but I think it would technically work. As long as the SKID and Subject DN don't change, relying parties may still be able to build a valid chain.
>>
>> -- Tim
Miller, Timothy J.
2011-02-17 15:29:14 UTC
Permalink
On Feb 17, 2011, at 8:58 AM, Roberto Opazo wrote:

> After CA expiration date, it's still possible to need EE certificate
> validation, not for a new SSL authentication, but for an electronic
> document signed in the past, when the EE certificate was valid.

Historical signature validation is a special case, and requires archived status statements--not final status statements. If a document was signed at T and revoked-for-compromise at T+n, the signature at T is still binding (though it may be more or less questionable depending on the magnitude of n). An historical signature algorithm would only use the CRL issued for the period covering T for validation.

-- Tim
Russ Housley
2011-02-17 14:42:39 UTC
Permalink
Roberto:

Another reasonable choice would be a date just after the expiration of every certificate issued by the CA. This will not disrupt certificates that are supposed to be valid, and the CRL will also have an end-of-life.

Russ


On Feb 16, 2011, at 10:44 PM, Roberto Opazo wrote:

> Well, the real situation is... Next Monday the CA certificate expires
> after 10 years of work. So CA certificate has not been expired yet and
> we have a little time to take some decisions.
>
> This is the first time for us on these situation. Next time is going
> to be in 20 years, so I expect there will be and standard way to
> finish CA live at that time.
>
> Have anybody an experience to share?
>
> How have other CAs ended?
>
> I think using a 24 hours valid period for the last CRL is not good
> choice. For instance, the next year a relaying party (RP) could try to
> validate a valid signature (like an XML signed last week) and the RP
> will get and expired CRL, I mean a CRL whit "Next Update" field
> expired. RP would have to note than "Next Update" is pointing to a
> date out of the CA's certificate validity period and assume that is
> the reason why there are no other CRL and then, decide to trust in an
> expired CRL. I think there are no many sw with this logic on the
> marked.
>
> That's why I prefer Rus recommendation, but I think It would be nice
> having an RFC with a sentence like "CAs conforming to this profile
> MUST create a final CRL with 99991231235959Z on "Next Update" field.
>
> After all, Rus is a guru to me, but I can't say to others "Rus told me
> to...". So I will have to repeat Rus argument, but It's not the same
> when it's me or the company I work for, the person saying that.
>
> Best regards,
>
> Roberto Opazo
>
> 2011/2/16 Sill, Alan <***@ttu.edu>:
>>
>>
>>
>>
>> On Feb 16, 2011, at 7:58 PM, "Michael StJohns" <***@comcast.net> wrote:
>>
>>> At 08:47 PM 2/16/2011, Alan Sill wrote:
>>>> A CA can become inactive for the purposes of issuing new credentials
>>>> without necessarily invalidating the certificates already issued.
>>>
>>> The specific question referred to a CA certificate that was expiring. If the CA certificate expires, then the certificates under that certificate (absent a re-signed replacement) are invalid by definition - or am I missing your point?
>>>
>>> Mike
>>
>> Woops -- you're right; if the CA certificate itself has expired, then the question is of course moot.
>>
>> Sorry, I missed that in the original question.
>>
>> Alan
>> _______________________________________________
>> pkix mailing list
>> ***@ietf.org
>> https://www.ietf.org/mailman/listinfo/pkix
>>
>
>
>
> --
> Saludos,
>
> Roberto Opazo
> _______________________________________________
> pkix mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
Andrews, Rick
2011-02-17 16:46:51 UTC
Permalink
> Have anybody an experience to share?
>
> How have other CAs ended?

Good question. In January 2010, we retired our "RSA Secure Server" CA,
but apparently we're still issuing empty CRLs with it. I suspect that if
we stopped, and simply removed the latest CRL from our download site, it
would have no effect whatsoever.

-Rick Andrews
Peter Gutmann
2011-02-19 00:19:51 UTC
Permalink
Roberto Opazo <***@opazo.cl> writes:

>This is the first time for us on these situation. Next time is going to be in
>20 years, so I expect there will be and standard way to finish CA live at that
>time.

Given that we've had this problem for 20-odd years so far and no-one's fixed
it (and indeed I don't know if anyone even knows how to fix it), I doubt it...

>Have anybody an experience to share?
>
>How have other CAs ended?

The first time, very badly. After that they set their root lifetimes to
longer than the career lifetime of the person who created the cert, so that
they'll be retired by the time it's a problem.

(I know that the above sounds like a tongue-in-cheek comment, but I'm being
serious, that seems to be the way to manage it, the first time it happens to
you you get burnt, then you set the lifetime to as long as you can to make
sure it never happens again).

Peter.
Denis Pinkas
2011-02-17 10:03:37 UTC
Permalink
Russ,

I don't believe that using 99991231235959Z is the best approach since this value is to be used for the certificate validity period only.
Its semantics is not appropriate either. Many implementations might fail with such a value.

Since there is no prefect solution, the best I can imagine is the following:

- place the end of validity of the root key as the nextupdate field of the last issued CRL.

All implentations will work nicely.
It is true that it is a lie, since no CRL will be issued at that date, but
since the CA will be dead one second after that date,
no one can comply about a dead authority.

Denis
----- Message reçu -----
De : pkix-bounces
À : Roberto Opazo
Date : 2011-02-16, 22:56:08
Sujet : Re: [pkix] What should be in "Next Update" field of the last CRL?


RFC 5280 says the following about a certificate notAfter field:

To indicate that a certificate has no well-defined expiration date,
the notAfter SHOULD be assigned the GeneralizedTime value of
99991231235959Z.

It seems to me that the same value is appropriate for a CRL.

Russ


On Feb 16, 2011, at 3:32 PM, Roberto Opazo wrote:

> CA being shut down forever.
>
> 2011/2/16 Russ Housley <***@vigilsec.com>:
>> Is the CA being shut down forever? Or, is a new CA taking over using the key rollover stuff specified in CMP?
>>
>> Russ
>>
>>
>> On Feb 16, 2011, at 1:49 PM, Roberto Opazo wrote:
>>
>>> Hello:
>>>
>>> I can't find an specification about what to put in the "Next Update"
>>> field of the last CRL issued by one CA in its last day. I mean, the
>>> day when this CA certificates expires.
>>>
>>> Is there any recommendation?
>>>
>>> Without a recommendation you could chose very different options:
>>>
>>> * NULL. The field is optional after all, but RFC5280 states
>>> "Conforming CRL issuers MUST include the nextUpdate field in all
>>> CRLs."
>>>
>>> * 24 hours, as all other CRL's. But that's a lie, CA is going to be
>>> expired in 24 hours, son It can't sign.
>>>
>>> * Year 2999. So no one alive today is going to be alive that they, but
>>> it's a lie any way and there could be systems not prepared to process
>>> that date.
>>>
>>> So, could you help me with an official recommendation?
>>>
>>> --
>>> Best regards,
>>>
>>> Roberto Opazo
>>> _______________________________________________
>>> pkix mailing list
>>> ***@ietf.org
>>> https://www.ietf.org/mailman/listinfo/pkix
>>
>>
>
>
>
> --
> Saludos,
>
> Roberto Opazo

_______________________________________________
pkix mailing list
***@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Jean-Marc Desperrier
2011-02-17 16:11:26 UTC
Permalink
Russ Housley wrote:
> RFC 5280 says the following about a certificate notAfter field:
>
> To indicate that a certificate has no well-defined expiration date,
> the notAfter SHOULD be assigned the GeneralizedTime value of
> 99991231235959Z.
>

I recently saw an implementation that actually uses that date, and it's
not really a convenient choice.

The use of the date 9999 seems to be in order to use the highest value
that doesn't have a 5 digits year. But given that the date is 23h 59:59
on the 31 december, it will result in a date in the morning of 1 january
10.000 for all locales that have a positive offset to GMT.
I think 99991231120000Z would be more convenient so that the year stays
9999 whatever the local time used to display it is.
Peter Gutmann
2011-02-19 02:04:13 UTC
Permalink
Jean-Marc Desperrier <***@free.fr> writes:
>Russ Housley wrote:
>> RFC 5280 says the following about a certificate notAfter field:
>>
>> To indicate that a certificate has no well-defined expiration date,
>> the notAfter SHOULD be assigned the GeneralizedTime value of
>> 99991231235959Z.
>
>The use of the date 9999 seems to be in order to use the highest value that
>doesn't have a 5 digits year. But given that the date is 23h 59:59 on the 31
>december, it will result in a date in the morning of 1 january 10.000 for all
>locales that have a positive offset to GMT. I think 99991231120000Z would be
>more convenient so that the year stays 9999 whatever the local time used to
>display it is.

Given that many time routines are going to reject this magic-value date anyway
because it exceeds the range of a 32-bit time_t (and/or should fall outside
sanity-check ranges for any sensible implementation), I don't think this will
be a problem, you'd need to implement it as:

read date string;
if( !memcmp( string, "9999...", length ) )
return( special_date );
convert string -> date;
return( date );

Peter.
Tom Gindin
2011-02-20 15:06:58 UTC
Permalink
Signed 32-bit times will be a problem soon enough for real
certificates. Issuers use 20-25 year root lifetimes all the time. and
2**31 on Unix is Jan. 18 or 19, 2038. There are a LOT of 2037 root
expirations in a current standard XP store, but nothing later yet. We can
recommend that nobody go beyond rollover until exactly 20 years before it,
and thus put off the evil day until seven years from now, but that's about
it. I'm sure most of the members of this list will still be working in
2018.

Tom Gindin




From:
Peter Gutmann <***@cs.auckland.ac.nz>
To:
***@free.fr, ***@ietf.org
Date:
02/18/2011 09:04 PM
Subject:
Re: [pkix] What should be in "Next Update" field of the last CRL?
Sent by:
pkix-***@ietf.org



Jean-Marc Desperrier <***@free.fr> writes:
>Russ Housley wrote:
>> RFC 5280 says the following about a certificate notAfter field:
>>
>> To indicate that a certificate has no well-defined expiration date,
>> the notAfter SHOULD be assigned the GeneralizedTime value of
>> 99991231235959Z.
>
>The use of the date 9999 seems to be in order to use the highest value
that
>doesn't have a 5 digits year. But given that the date is 23h 59:59 on the
31
>december, it will result in a date in the morning of 1 january 10.000 for
all
>locales that have a positive offset to GMT. I think 99991231120000Z would
be
>more convenient so that the year stays 9999 whatever the local time used
to
>display it is.

Given that many time routines are going to reject this magic-value date
anyway
because it exceeds the range of a 32-bit time_t (and/or should fall
outside
sanity-check ranges for any sensible implementation), I don't think this
will
be a problem, you'd need to implement it as:

read date string;
if( !memcmp( string, "9999...", length ) )
return( special_date );
convert string -> date;
return( date );

Peter.
Andrea Caccia
2011-02-20 18:16:22 UTC
Permalink
After all, why not simply stop the CA when its certificate expires with the last CRL next update generated with the same rules of previous ones?
Advantages:
- no special effort to generate a specific CRL
- no RFC 5280 rule breaking
- every CRL next update is somehow a lie, so the better is to choose the most effective
- there could be the need to generate an additional CRL in the unlikely event that some certificate has been revoked in the time frame between issuance of last CRL and CA cert expiration (also those certificates MUST be present at least in one CRL)
- verification software should correctly manage correctly without modifications the situation and discard signatures because the CA cert is expired and/or no fresh CRL is available within the grace period after CRL next update
- no problem to manage the date (signed 32bit times, local time >31/12/9999, …)

Disadvantages?

Andrea Caccia


Il giorno 20/feb/2011, alle ore 16.06, Tom Gindin ha scritto:

> Signed 32-bit times will be a problem soon enough for real
> certificates. Issuers use 20-25 year root lifetimes all the time. and
> 2**31 on Unix is Jan. 18 or 19, 2038. There are a LOT of 2037 root
> expirations in a current standard XP store, but nothing later yet. We can
> recommend that nobody go beyond rollover until exactly 20 years before it,
> and thus put off the evil day until seven years from now, but that's about
> it. I'm sure most of the members of this list will still be working in
> 2018.
>
> Tom Gindin
>
>
>
>
> From:
> Peter Gutmann <***@cs.auckland.ac.nz>
> To:
> ***@free.fr, ***@ietf.org
> Date:
> 02/18/2011 09:04 PM
> Subject:
> Re: [pkix] What should be in "Next Update" field of the last CRL?
> Sent by:
> pkix-***@ietf.org
>
>
>
> Jean-Marc Desperrier <***@free.fr> writes:
>> Russ Housley wrote:
>>> RFC 5280 says the following about a certificate notAfter field:
>>>
>>> To indicate that a certificate has no well-defined expiration date,
>>> the notAfter SHOULD be assigned the GeneralizedTime value of
>>> 99991231235959Z.
>>
>> The use of the date 9999 seems to be in order to use the highest value
> that
>> doesn't have a 5 digits year. But given that the date is 23h 59:59 on the
> 31
>> december, it will result in a date in the morning of 1 january 10.000 for
> all
>> locales that have a positive offset to GMT. I think 99991231120000Z would
> be
>> more convenient so that the year stays 9999 whatever the local time used
> to
>> display it is.
>
> Given that many time routines are going to reject this magic-value date
> anyway
> because it exceeds the range of a 32-bit time_t (and/or should fall
> outside
> sanity-check ranges for any sensible implementation), I don't think this
> will
> be a problem, you'd need to implement it as:
>
> read date string;
> if( !memcmp( string, "9999...", length ) )
> return( special_date );
> convert string -> date;
> return( date );
>
> Peter.
> _______________________________________________
> pkix mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
>
>
>
> _______________________________________________
> pkix mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
Peter Gutmann
2011-02-20 19:44:51 UTC
Permalink
Tom Gindin <***@us.ibm.com> writes:

>I'm sure most of the members of this list will still be working in 2018.

That's OK, I'm sure most of the rest of us will still be waiting for PKI to
start working in 2018 too :-).

Peter.
s***@lockstep.com.au
2011-02-21 01:14:17 UTC
Permalink
For completeness, here is a boring answer to a very boring quip ...

PKI has been working great for a couple of decades but in closed communities for authorization rather than in open utopian communities for authentication.

See:

- the GSM system
- EMV DDA cards
- cable TV set-top boxes
- ID cards in Malaysia, Hong Kong, Estonia ...
- health smartcards in Austria, Italy, France, Germany, Taiwan ...

I have argued that closed PKI should be actually be regarded as the general case, while the old idea of open PKI (which is what I presume you're referring to) for stranger-to-stranger trust is a special case, not very useful, and unsurprisingly unsuccessful.

See "Public Key Superstructure" (easily Googled).

Cheers,

Steve Wilson
Lockstep
http://lockstep.com.au




-----Original Message-----
From: "Peter Gutmann" <***@cs.auckland.ac.nz>
Sent: Monday, 21 February, 2011 6:44am
To: ***@cs.auckland.ac.nz, ***@us.ibm.com
Cc: ***@ietf.org
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?

Tom Gindin <***@us.ibm.com> writes:

>I'm sure most of the members of this list will still be working in 2018.

That's OK, I'm sure most of the rest of us will still be waiting for PKI to
start working in 2018 too :-).

Peter.
Miller, Timothy J.
2011-02-21 14:05:01 UTC
Permalink
On Feb 20, 2011, at 7:14 PM, <***@lockstep.com.au> wrote:

> I have argued that closed PKI should be actually be regarded as the general case, while the old idea of open PKI (which is what I presume you're referring to) for stranger-to-stranger trust is a special case, not very useful, and unsurprisingly unsuccessful.

SPKI/SDSI, anyone? :)

-- T
Miller, Timothy J.
2011-02-17 13:50:04 UTC
Permalink
Simple answer: the notAfter date of the issuing CA. No cert issued by the CA is valid after this date anyway, so the CRL is moot thereafter.

-- Tim

On Feb 16, 2011, at 12:49 PM, Roberto Opazo wrote:

> Hello:
>
> I can't find an specification about what to put in the "Next Update"
> field of the last CRL issued by one CA in its last day. I mean, the
> day when this CA certificates expires.
>
> Is there any recommendation?
>
> Without a recommendation you could chose very different options:
>
> * NULL. The field is optional after all, but RFC5280 states
> "Conforming CRL issuers MUST include the nextUpdate field in all
> CRLs."
>
> * 24 hours, as all other CRL's. But that's a lie, CA is going to be
> expired in 24 hours, son It can't sign.
>
> * Year 2999. So no one alive today is going to be alive that they, but
> it's a lie any way and there could be systems not prepared to process
> that date.
>
> So, could you help me with an official recommendation?
>
> --
> Best regards,
>
> Roberto Opazo
> _______________________________________________
> pkix mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
Nuno Ponte
2011-02-17 14:11:07 UTC
Permalink
Hi,

That was also the first thing that came to my mind when I read this
question.

However, if a certificate is revoked meanwhile, that means it will
never show up in an issued CRL. What about having a last and definitive
CRL created at exactly the CA expire date, i.e. CRL_thisUpdate =
CRL_nextUpdate = CA_notAfter ?

Regards,

Nuno Ponte

Em 17-02-2011 13:50, Miller, Timothy J. escreveu:
> Simple answer: the notAfter date of the issuing CA. No cert issued by the CA is valid after this date anyway, so the CRL is moot thereafter.
>
> -- Tim
>
> On Feb 16, 2011, at 12:49 PM, Roberto Opazo wrote:
>
>> Hello:
>>
>> I can't find an specification about what to put in the "Next Update"
>> field of the last CRL issued by one CA in its last day. I mean, the
>> day when this CA certificates expires.
>>
>> Is there any recommendation?
>>
>> Without a recommendation you could chose very different options:
>>
>> * NULL. The field is optional after all, but RFC5280 states
>> "Conforming CRL issuers MUST include the nextUpdate field in all
>> CRLs."
>>
>> * 24 hours, as all other CRL's. But that's a lie, CA is going to be
>> expired in 24 hours, son It can't sign.
>>
>> * Year 2999. So no one alive today is going to be alive that they, but
>> it's a lie any way and there could be systems not prepared to process
>> that date.
>>
>> So, could you help me with an official recommendation?
>>
>> --
>> Best regards,
>>
>> Roberto Opazo
>> _______________________________________________
>> pkix mailing list
>> ***@ietf.org
>> https://www.ietf.org/mailman/listinfo/pkix
>
>
> _______________________________________________
> pkix mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
Miller, Timothy J.
2011-02-17 14:17:02 UTC
Permalink
On Feb 17, 2011, at 8:11 AM, Nuno Ponte wrote:

> However, if a certificate is revoked meanwhile, that means it will never show up in an issued CRL. What about having a last and definitive CRL created at exactly the CA expire date, i.e. CRL_thisUpdate = CRL_nextUpdate = CA_notAfter ?

"Meanwhile" is meaningless in this case. Expired certs can be removed from a CRL with zero impact because the validation algorithm discards expired certs *before* status is checked. Checking status prior to expiry is far, far less efficient; software that checks status before validity should be fixed.

Choosing to keep expired certs on a CRL may be required for legal or policy reasons, but there is no technical requirement to do so.

-- Tim
Loading...