Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15

["Peter Rybar" <[e-mail]>]

The value of thisUpdate is important and must contain correct time value according to the time when information about the certificate status was updated from CA issuing certificates whose status CRL or OCSP provides.

When OCSP is based on database then thisUpdate contains the time when OCSP database was updated according to information from CA.
When OCSP is based on CRL then thisUpdate of OCSP contains the same value as is included in thisUpdate field of last CRL or delta CRL available for OCSP responder.
It means the value of thisUpdate is not actual time and must be also correct for non-issued cert status. But, which time is correct for non-issued cert status? It must be also the time value when white list was updated in OCSP database with data provided by issuer CA of certificates whose status OCSP provides.

Practical usage:

In case when the validation system must provide information about the certificate status which is stable and will not be later changed, then the system must provide also the point of the time in the past when such certificate status was declared as correct.

Such point of the time is indicated in CRL or in OCSP response by the time value in the field thisUpdate.

ITU-T X.509 defines rules for CRL about the time value of thisUpdate when the revocation time revocationDate is included in first CRL (subsequent CRL contains this value of revocationDate).

RFC 2560 defines semantics of thisUpdate field as:
   - thisUpdate: The time at which the status being indicated is known to be correct.

According to such semantics of thisUpdate fields in CRL or in OCSP the validation system provides the value of thisUpdate field in the validation result as the time to which the status of certificate is known as correct while any time later the certificate status can be changed if thisUpdate is not after the expiration time of the certificate.

Peter Rybar


-----Original Message-----
From: Martin Rex [mailto:[e-mail]] 
Sent: Monday, April 08, 2013 11:11 PM
To: Sean Turner
Cc: Peter Rybar; [e-mail]; [e-mail]; [e-mail]; 'Stefan Santesson'
Subject: Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15

Sean Turner wrote:
> 
> I don't see any requirement in RFC 2560 or 2560bis for clients to order 
> requests according to thisUpdate.

Correct observation.

After this discussion, I believe this lack of documented requirement(s)
(for OCSP response caching and updating of that cache) to be a defect
of rfc2560/rfc2560bis.

rfc2560 provides exactly zero guidance on OCSP response caching,
and when an OCSP responder obtains certificate serial status information
from different information sources, then this creates a potential and
non-obvious ambiguity for implementors.

rfc2560bis introduces the explicit notion of OCSP responders feeding
on multiple information sources (such as CRLs _plus_ direct access
to cert issue records), so I think continued silence on OCSP response
caching and the exact semantics of thisUpdate for OCSP cache updates
a bad idea that may result in real interop problems.

  http://www.ietf.org/mail-archive/web/pkix/current/msg32617.html

-Martin