Re: Odd/bad sentence in 5.4.1

Dan Schutzer wrote:
> Wait, if a certificate does not say revoked, and the system checks for
> whether it is still has a valid expiration date, then we do know if it is
> expired. Doesn't a certificate have on it the expiration date? Can't that be
> checked? So if the certificate is not on a CRL and has an expired date can't
> a program deduce it is expired?

Yes it can. The field is called notAfter and is the cause of useless
and annoying warnings to users that just helps habituate users to
click "ok" thoughtlessly. In many cases, checking notAfter on an SSL
server cert is counterproductive, most especially for SSCs.

However, for sites that should, or are willing to, buy e.g. an EV
cert, then things are more managed, and so an expired cert should be
an error in that case. (Assuming the UA has a good clock.)

S.


> 
> Dan
> 
> -----Original Message-----
> From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org] On
> Behalf Of Thomas Roessler
> Sent: Friday, April 04, 2008 10:12 AM
> To: Stephen Farrell
> Cc: 'W3 Work Group'
> Subject: Re: Odd/bad sentence in 5.4.1
> 
> 
> On 2008-04-04 12:20:22 +0100, Stephen Farrell 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.
> 
> Yes.  But we can't guarantee that the user agent actually saw one of
> these.
> 
>>> 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.]
> 
> I'll look into reviving Relaxed Path Validation and linking to it
> from the error part.  Stay tuned.
> 
> (ACTION-414)
> 
>>> 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.)
> 
> So, to get the intent clear: If UA would do validation check during
> the certificate's validity period, then it must consider an invalid
> certificate as a hard error.  Does that make sense in your view?  Or
> are you suggesting a different approach?
>

Received on Friday, 4 April 2008 14:49:03 UTC