Re: Expired certificates

Henry indicated that conforming systems are required to process expired fields. They are not required to enforce them.

Thus means that, when presented with a critical extension that is unknown, one may designate the cert as valid ( for local purposes). This is non conforming x509, non conforming pkix, but conforming webid cert handling.

Similarly, one can ignore expiry (notafter).

This is webby, and the same as browsers - that allow expired server certs, or ssl names in certs not to agree with what the socket reports the name to be (usually having relied upon dns to map ip to domain name.

Im not sure how one writes a test suite for such webiness. Formally, the test is: local rules dominate fields.

The same culture stands when the foaf agent retrieves data from an https endpoint (with expired dates, or unknown critical extensions). Local rules determine if non conforming or conforming behaviors are installed into the stack.

The same goes for http signals. If the caches foaf card has expired and no update can be obtained from the source, webid requires local control - allowing the expired cache to be used.

This is webiness (as I understand it) as it relates to control properties of crypto and security services. The philosophy is at odds with ietf note, even. It's probably unusable by most corporate users (needing to pass auditors correctness tests). 


On May 15, 2011, at 5:36 PM, Sarven Capadisli <sarven.capadisli@deri.org> wrote:

> Hi,
> 
> I think I'm experiencing an issue where an expired certificate appears
> to be functional i.e., it still lets me sign in to services like
> http://data.fm/ , http://identi.ca/ (via openid4.me).
> 
> I have:
> 
> Validity Not After:
> 11-05-14 16:55:23
> (11-05-14 20:55:23 GMT)
> 
> Tested in Firefox 4 / Ubuntu 10.10.
> 
> Am I overlooking something?
> 
> -Sarven
> 
> 
>

Received on Monday, 16 May 2011 15:51:57 UTC