48300 - Allow application to customize Cert Verification slop

Status: RESOLVED FIXED

(NSS :: Libraries, enhancement, P3)

Description

[Steve Parkinson]

There is code in the certdb.c to verify that a certificate is valid
at a particular time, but allows 24 hours of slop-time when performing
the check.

I understand that originally, this was to reduce the incidence of
problems occuring due to an incorrectly configured clock on the client.

However, there is currently no way to turn off, or change this slop time,
and so it makes many applications (for example, verifying certs that are
only isued for an 8-hour workday) more difficult to write.

I propose a new API such as:

        CERT_SetCertCheckSlopTime(int64 newSlopTime)

Which would set the slop time as a global variable.



There may also be a case for reducing the default slop time to something
more 'expected'. I know people are very surprised when I tell them that
this slop time exists - maybe 1 hour is more reasonable.

http://lxr.mozilla.org/mozilla/source/security/nss/lib/certdb/certdb.c#788

Comment 1

[Wan-Teh Chang]

Can one of you look at this feature request?

I understand that the 24-hour slop time is
to allow for the ambiguity of GMT or local time
if time zone is not specified.

The data type for the 'newSlopTime' argument
should be PRTime.  (By the way, 'int64' is
deprecated.  Use PRInt64 instead.)

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Before we make any changes, I think we all need to be clear 
about certain things:

1. This slop ONLY affects the _begining_ of the validity period.
It doesn't allow a cert to live on after it has expired.
It DOES allow a cert to be considered valid up to 24 hours before
its validity period is supposed to begin.  That's ALL it does.

2. The reason this was/is done is that Windows 95 has a terrible
problem where it gets confused about what time zone it is in.
It gets into a state where its TimeZone GUI panel shows you the
time zone you expect it to be in, but internally it's really 
in either the GMT or PST zone.  If a PC is in this condition,
and (a) the PC's internal time zone is not between its real time 
zone and the international date line (e.g. the PC is in Europe or
australia and the internal time zone is PST), and (b) it gets a 
new cert from a CA with a validity period that starts with the 
true time (GMT) that the cert was issued, that PC will think 
that the validity period for that cert is in the future.  
It will think that the cert is not yet valid. Software on that 
PC will report to the user that the cert has expired (because
we don't have a message that says "is not yet valid"). 

This problem with Win95 PCs is SO COMMON that Netscape employees 
in Europe and Australia used to run into it daily.  It was a 
major impediment to the initial roll-out of Netscape employee 
certs.  It drove a guy in IT named Lord to ask for a fix in 
the browser to work around this problem.  (I have the emails).
At that time, NSS did not exist separately from the browser.
NSS was simply another part of the application.  Hence there was
no basis on which to say "it should be done in application code
not in the library", because the library was application code.

AFAIK, Win95's problem was never fixed.  The only reason this
"cert isn't valid yet" problem is no longer perceived to be 
a problem is this hack.

3. IMO, the existing NSS API does NOT need to be changed.
There is no need for the library's API to have a new explicit 
slop API. It already has an explicit time in the API.  That is, 
the function answers the question: "Was/is this cert valid at 
the time specified in this argument?"

The slop should be removed from the NSS library completely.  
The algorithm that an application should use, if it wants to 
handle the "cert validity hasn't started yet" problem is this:
   Ask if the cert is valid NOW.  
   if not, and the reason is that it's not in the validity period,
     then ask if it will be valid 24 hours from now.
   if so, treat it as valid now.

PSM should probably employ this algorithm, as least in Win95 builds.

Comment 3

[Wan-Teh Chang]

Need to coordinate with the PSM team when we
remove the slop from the NSS libraries.

Comment 4

[Wan-Teh Chang]

Reassigned the bug to Nelson.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

I propose to address this RFE as described below.  If you object
to this solution, speak up quickly.

Instead of being purely a compiled-in constant, the "slop time"
will be a single static variable, initialized to the value that
is now compiled in (24 hours).  There will exist two new 
accessor functions, CERT_GetSlopTime() and CERT_SetSlopTime().
This single value will be used in all functions that verify
cert and CRL validity periods.  

Since there is only one variable, it will not generally be 
possible for different threads to each have different slop 
times in an application.  Only a single-threaded app will
be able to safely use different slop times for different
cert validity checks within the same process.

Sound OK?

Comment 6

[Wan-Teh Chang]

This "slop time" issue does not need to be
resolved in NSS 3.2.  Defer to 3.3.

Nelson, it seems that your proposal is
essentially what Steve proposed, correct?

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Attachment: Proposed patch

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

Wan-Teh, in answer to your question, yes, this is similar to what 
Steve proposed (insert red-faced icon here ;-). 

I have the patch ready to check in, with your review and permission.
If you'd rather I defer it, I will.  Pls let me know.

Comment 9

[Wan-Teh Chang]

Nelson, I reviewed your patch.  It correctly implements
Steve's proposed solution.  However, I would like to
suggest that we do not check it in before we agree that
this is the right solution.  I am concerned about your
first comment on this bug (2000-08-09 18:41), in which
you said that there is no need for NSS to have a new
explicit slop API...

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

Wan-Teh,  While I do believe that it would be possible to 
solve this problem by eliminating "Cert verification slop"
and having applications do two verifications, if necessary,
that change would require changes to existing applications
that rely on cert verification slop.  

The approach taken in the attached patch maximizes 
compatibility with existing applications.  

How do we get closure on the decision about this bug?
If we're going to add this new function, then 
I'd like to get the new function call into NSS 3.2 .

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

Today I spoke with Bob Relyea, Terry Hayes, and Steve Parkinson,
the submittor, about this.  I think we agreed that:
a) for application compatiblity, the existing interfaces must
continue to use slop, and the slop must continue to default to 
24 hours.
b) nothing in this proposal prevents us from later adding a 
new set of cert verification functions do not use the slop,
or that use explicitly supplied slop values, e.g.
CERT_VerifyCertNowWithSlop or CERT_VerifyCertNowWithoutSlop.

So, I have checked in the patch attached above.