Subject: Re: [pkix] Advice on (small amounts of) clock skew?

From: Peter Gutmann <[email-masked]>
Date: Wed, 19 Dec 2012 02:05:37 +0000

"Henry B. Hotz" <[email-masked]> writes:

>If the service consuming certs is actually critical, then would you *ever*
>shut it down just because you couldn't get a fresh CRL?  That makes for a
>pretty easy DOS, and if it's critical, then protection from DOS is important.

Exactly.  Once you get into the real world, where certificates are (for
example) used with financial transactions where you lose money, potentially
lots of it, for each failed transaction, revocation checking is typically the
second thing that's turned off after checking for expired certs (quite
possibly the most pointless check in all of PKI, "we're going to shut down all
electronic trading because the certificate that was perfectly valid for
million-dollar trades five seconds ago is now regarded as invalid without
anything about it having changed").  This is why I have in the past sometimes
referred to certs as "bit-bagging mechanisms for public keys", because when
things are critical most of PKI gets thrown away because of the large amount
of brittleness it adds to anything it's used with.  So all the fields in the
cert are nicely decorated, but everyone carefully looks the other way when
they're processing it.

Peter.

---

From: [email-masked] (Martin Rex)
Date: Wed, 19 Dec 2012 16:17:31 +0100 (CET)

> cert are nicely decorated, but everyone carefully looks the other way when

When I first implemented code to create certs (and later also to sign/issue),
I decided to create certs with notBefore 24h into the past from current time,
so that I will _never_ encounter problems with clock skew about notBefore,
no matter how the code that validates it is actually implemented.

A CA that issues Certs with a notBefore sharp on the current
time is IMHO acting silly and didn't think about the consequences.

For CRLs, there is no "notBefore" validity date.  CRLs have a "thisUpdate"
field, but the way it is defined, it does _NOT_ limit validity.

  http://tools.ietf.org/html/rfc5280#section-5.1.2.4

-Martin

---

From: Bruce Stephens <[email-masked]>
Date: Wed, 19 Dec 2012 15:34:21 +0000

[email-masked] (Martin Rex) writes:

[...]

>   http://tools.ietf.org/html/rfc5280#section-5.1.2.4

Good point. Nothing in 6.3 (or the relevant X.509 descriptions)
contradicts that, so I think my check (which may come from OpenSSL,
actually) is erroneous. Hmm, yes, I think it is in OpenSSL. (It's
probably relatively harmless for the typical internet usage of OpenSSL.)

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 19 Dec 2012 16:00:31 +0000

IIRC, DoD issues with notBefore set to 0000Z of the day of issue.  Same reasoning.

-- T

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Martin Rex
>Sent: Wednesday, December 19, 2012 10:18 AM
>To: Peter Gutmann
>Cc: [email-masked]
>Subject: Re: [pkix] Advice on (small amounts of) clock skew?
>
>Peter Gutmann wrote:
>>
>_______________________________________________
>pkix mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pkix