Re: Odd/bad sentence in 5.4.1

Thomas Roessler wrote:
> Actually, you can't tell the difference.  If a certificate has is
> beyond its validity period, the CA takes no responsibility to make
> status information available; the certificate may even have been
> removed from the CRL.

There's a corner case - if it was revoked the CA should include
that information on a few CRLs after the expiry.

> The basic idea of relaxed path validation is actually in the
> "Otherwise..." phrase of the same paragraph:
> 
>   Otherwise, the fact that a certificate is outside its validity
>   period SHOULD be communicated using error signalling of class
>   warning (6.4.3 Warning/Caution Messages ).
> 
> Maybe that should actually say "at most warning" or "just
> notification" or something like that.

Or even less. I preferred the earlier text where we defined
relaxed validation and said not to bother people with any
warnings about time. Honestly - why should a web UA care about
cert expiry really? Its mainly a hang-over from the original
intent of X.509 (user login to the directory) that turned into
a business model for CAs. [Note - I do think a UA should care
about expiry/not-yet-valid for AACs and the like, since the
"augmented" aspect does involve timeliness, but not for
vanilla certs, and certainly not SSCs.]

> The text that Stephen spotted is the flip side: *If* there are
> validity checks, then please do them thoroughly and treat expiration
> as the hard error.  If you don't do the validity checks, then don't
> bother with expiry checks.

If a certificate is expired, or not yet valid, a sensible UA won't
bother asking about revocation (modulo the corner-case) because there's
no guarantee of an answer. So no status check need be performed for
that certificate.

With the current text, if the UA ever checked status for any cert,
then its supposed to consider all not-yet-valid and expired certs
to be revoked.

So, even if we stick with the current intent, wordsmithing will be
needed. (But let's thrash on the intent first.)

Stephen.

Received on Friday, 4 April 2008 11:20:59 UTC