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

From: Bruce Stephens <[email-masked]>
Date: Mon, 17 Dec 2012 10:31:52 +0000

Specifically, the NIST PIV infrastructure has CRLs (and presigned OCSP
responses) issued hourly (though the CRLs at least last for a day), and
that caused unexpected problems when testing: a non-trivial amount of
the time, the CRLs were not yet valid.

If it was that the nextUpdate time had passed, then there's advice in
RFC 5280 (one should try and get a new CRL or delta CRL, but (depending
on local situations) continuing to use the CRL may well be appropriate),
but I don't see any suggestions on what to do if it appears that the CRL
isn't yet valid. (I suppose waiting is one option...)

(SDN.705 gives guidance for X.500, but only for bind tokens and the
like. I imagine SDN.706 offers something for certificates and CRLs, but
I haven't seen that.)

---

From: "Piyush Jain" <[email-masked]>
Date: Mon, 17 Dec 2012 06:38:57 -0800

A few products that I have worked with had the option to configure a value
for clock skew.
If the time difference between the current time and thisUpdate on the CRL
was less than this configured value, CRL was considered valid.

-Piyush

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Bruce Stephens
> Sent: Monday, December 17, 2012 2:32 AM
> To: [email-masked]
> Subject: [pkix] Advice on (small amounts of) clock skew?
> 
that
> caused unexpected problems when testing: a non-trivial amount of the time,
> the CRLs were not yet valid.
> 
> If it was that the nextUpdate time had passed, then there's advice in RFC
> 5280 (one should try and get a new CRL or delta CRL, but (depending on
local
> situations) continuing to use the CRL may well be appropriate), but I
don't
> see any suggestions on what to do if it appears that the CRL isn't yet
valid. (I
> suppose waiting is one option...)
> 
> (SDN.705 gives guidance for X.500, but only for bind tokens and the like.
I
> imagine SDN.706 offers something for certificates and CRLs, but I haven't
> seen that.) _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 18 Dec 2012 17:34:23 -0800

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.  

In fact I now even have operational statistics that say network outages are way, way more likely than use of a revoked credential with one service I run.  (Admittedly, it's not in full production yet.)

On Dec 17, 2012, at 6:38 AM, Piyush Jain wrote:

> _______________________________________________
> pkix mailing list
> [email-masked]

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: "Ed Gerck, Ph.D." <[email-masked]>
Date: Tue, 18 Dec 2012 18:01:16 -0800

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

I suggest that a clock variance (skew) that the RP can accept, and taking into 
account the issuer's and validator's operational conditions,  is to be 
preferred over declaring it to be exactly zero -- which is *certainly* the 
least-likely answer.

If you can't get a fresh CRL and there is no clock variance that is acceptable, 
then shutdown may be mandatory although not needed because, as we know, DoS can 
be effective to compromise information when users cannot be trusted (as they 
should not be, as a rule).

For example, as seen in an unfortunate sport news recently, when the police 
dispatcher over the radio asks the officer in a patrol car if the "digital is 
on" before sending the suspect's private information, the officer responds 
something like: "at this point, forget about encryption and just send me 
information using voice". The recording is available online.

> In fact I now even have operational statistics that say network outages are way, way more likely than use of a revoked credential with one service I run.  (Admittedly, it's not in full production y…

Those are different risks, as apples and speedboats.  The risk of a network 
outage is "no signal" whereas the risk of an incorrect CRL can be a false 
approval. A higher risk of the former can be easily reduced by adequate redundancy.

Best regards,
Ed Gerck