- From: Dan Schutzer <dan.schutzer@fstc.org>
- Date: Fri, 4 Apr 2008 10:43:45 -0400
- To: "'Thomas Roessler'" <tlr@w3.org>, "'Stephen Farrell'" <stephen.farrell@cs.tcd.ie>
- Cc: "'W3 Work Group'" <public-wsc-wg@w3.org>
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? 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? -- Thomas Roessler, W3C <tlr@w3.org>
Received on Friday, 4 April 2008 14:44:35 UTC