- From: Henry Story <henry.story@bblfish.net>
- Date: Tue, 12 Apr 2011 19:09:03 +0200
- To: WebID XG <public-xg-webid@w3.org>
- Cc: Peter Williams <home_pw@msn.com>, Andrei Sambra <andrei@fcns.eu>
On 12 Apr 2011, at 18:33, Henry Story wrote: > On 12 Apr 2011, at 18:14, peter williams wrote: > >> >> What's the point of step 4? >> >> (a) It’s a self-signed certificate, in concept, so I can stick any date in, I want. Its self-asserted, and thus rather meaningless. This goes to the heart of another issue below (see extensions). > > I think we had the notion that it would be useful to have short lived certs when working on less reliable machiens, so that they would be released if needed. It's not because it's self signed that one should not take my desire for my cert to be short lived lightly. > >> (b) there was no step to check the self-signature on the cert (or any signature on the cert). Do not assume TLS server implementations do in the SSL stream handling, during client authn! > > The signature of the cert is not important right here (though it could be, if we have certificate chains). > What is important is that the TLS has verified that the privte key matches the public key in the cert. the above two don't quite fit together come to think of it. It makes sense to check the date, as explained above. But if one does that one must also check the signature. And if it is a self signed certificate then of course the signature is not worth checking, as Peter pointed out. It is not worth checking either if it is signed by an open cert, such as the one currently shipped by Clerrezza. So checking the date makes sense for the reasons given if the above two are not true. This is where the idea of signing the certificates with the private key tied to the public keys of the TLS end point that generated the key does start to make sense. Henry Social Web Architect http://bblfish.net/
Received on Tuesday, 12 April 2011 17:09:33 UTC