W3C home > Mailing lists > Public > public-xg-webid@w3.org > May 2011

Re: Expired certificates

From: Henry Story <henry.story@bblfish.net>
Date: Mon, 16 May 2011 18:20:21 +0200
Cc: Sarven Capadisli <sarven.capadisli@deri.org>, WebID XG <public-xg-webid@w3.org>
Message-Id: <A62680AD-2AB5-46CB-B61D-6B1F82EFA3D6@bblfish.net>
To: Peter Williams <home_pw@msn.com>

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.

> 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. 


> 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
Received on Monday, 16 May 2011 16:20:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:45 UTC