- From: Peter Williams <home_pw@msn.com>
- Date: Mon, 16 May 2011 16:31:20 -0700
- To: Henry Story <henry.story@bblfish.net>
- CC: Henry Story <henry.story@bblfish.net>, Sarven Capadisli <sarven.capadisli@deri.org>, WebID XG <public-xg-webid@w3.org>
The most important thing to decide, first, is: should/must the validation agent confirm the signature on the cert. If yes, dates and other field have integrity (assuming the sig verifies). If so, one might/may process the fields. If not, no field present or otherwise has any value. Let's recall that ssl code (typically) has verified the public key in the cert against the ssl signatures. Thus the pubkey value in the cert has reliability - even if no other field does. Let's also recall that ssl signs even the cert blob indirectly. Thus every cert is, in done sense, self signed by ssl processes. If the va code has assurance that ssl verified the ssl signature, that the verification key came from the ee cert in the handshake message, and that the system is generally c2-level operating security, the user can be said to have asserted the dates, the extensions etc. If we rely on the ssl argument for field integrity, we need to be rigoros: the fields are self asserted. In my code I insist that the cert is self signed (going above and beyond ssl signing of the handshake). I also confirm that one of the San uri point to a https resource of mime type .../cert whose value must be bit identical to the Val reported by ssl. This step addresses the threat of the hijacked browser (generally assumed untrustworthy) signing client certs dynamically (in addition to signing ssl handshakes msgs). On May 16, 2011, at 10:21 AM, Henry Story <henry.story@bblfish.net> wrote: > > 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 23:31:21 UTC