Re: Expired certificates

On 16 May 2011, at 18:20, Henry Story wrote:

> 
> On 16 May 2011, at 17:52, Peter Williams wrote:
> 
>> Henry indicated that conforming systems are required to process expired fields. They are not required to enforce them.
> 
> Well if we use IETF language I would say they SHOULD process those fields. If the certificate is expired then that is an important signal to take account of. As I mentioned previously, the certificate could have been made for temporary life for a reason - such as the friend's computer scenario. 
> 
> If there is spec language that is needed to make this clearer that would be useful.
> 
> Currently Clerezza tests for dates being valid.

But the issuer here is that if these are self signed certificates, then as Peter Williams pointed out a few weeks ago, it would be perfectly possible for someone who got hold of the browser to use the private key to make a new certificate. But in that case one might as well make the thief work a bit and get him to learn to sign and date his certificates correctly. 

If the cert on the other hand is signed by some other known public key then the meaning of the fields becomes a bit clearer. The time stamp then and all the other extensions  then set limitations on what the other party (the sigining party - the Issuer) affirms in the certificate.  So that if the time stamp fails one can no longer rely on those statements as coming from that third party.

> 
> 
>> 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.
> 
> Yes, what one then has is identity without the cert. But it would clearly be better if certs did not have critical extensions, and were valid. They are more likely to be acceptable everywehere.
> 
> We need to work on clarifying this for the spec.
> 
>> Similarly, one can ignore expiry (notafter).
> 
> of the two fields this seems like the one that should not be ignored.
> 
> 
>> 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.
> 
> I think X509 certificate tests are going to take time to build correctly. But we should start
> by warning users not to use critical extensions, as that will limit their ability to log in.
> I think we can add tests there as time goes on.
> 
> 
>> 
>> 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). 
> 
> yes, so for them, and people who deal with them, you should make sure your certificates are in good order. 
> 
> Henry
> 
> 
>> 
>> 
>> 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
>>> 
>>> 
>>> 
>> 
> 
> Social Web Architect
> http://bblfish.net/
> 

Social Web Architect
http://bblfish.net/

Received on Monday, 16 May 2011 17:21:56 UTC