- From: Joe Presbrey <presbrey@gmail.com>
- Date: Thu, 26 Jan 2012 10:22:18 -0500
- To: Henry Story <henry.story@bblfish.net>
- Cc: Melvin Carvalho <melvincarvalho@gmail.com>, Mischa Tuffield <mischa@mmt.me.uk>, public-webid@w3.org
On Thu, Jan 26, 2012 at 9:39 AM, Henry Story <henry.story@bblfish.net> wrote: > No, because I agree with Mo that if I sign the certificate myself, then > I have made a claim that should at the least be respected. Not respecting > it means I can't generate short lived certificates in public spaces, and it > also means we'll have more trouble integrating with other systems like > browserid. You can only generate short lived certificates in public spaces with additional notBefore/notAfter schema added to your WebID LD. Or you can remove the public key from the LD. We need something that works with ALL WebIDs, not only signed WebIDs. >>>>> This is probably not a bad thing, as the service that creates them can then have it's own WebID, >>>>> and would end up constituting an extra verification layer. There is no requirement on self signed >>>>> certificates in WebID. >> > I was not thinking of of major CAs. Rather consider that your Freedom Box > could generate it's own private key and Self Signed certificate and sign > your client certificate with it. I agree your "Freedom Box" should have its own WebID (like all servers), but we should not recommend it signs your cert. Just have your Freedom Box write your client cert/key in its own WebID LD if it wants to lend its assurance. Similarly, you could accumulate a list of several additional assurers/insurers/underwriters in your personal (have your friends FreedomBox' add assurance when you are visiting on their wifi) -- no need to limit it to your cert's single signer (single point of failure). Consider the direction even major CAs (should be / are) taking, eg. http://www.links.org/files/CertificateAuthorityTransparencyandAuditability.pdf: "Trust Model: Browsers will need to require (at some point in the future) that all public certificates are accompanied by an audit proof. This proof will be a proof that the certificate appears in one or more public logs..." LinkedData ~= "public log" ? OCSP? DNSSEC? Plenty of other good technologies to help us layer trust... "Similarly, there is no need to trust CAs - if they issue a certificate they should not, then one of three things can happen..." > There is no requirement that Certificates be not self signed. But it > turns out to be a lot more practical when they are not, as some of the > demos here have shown. 1 click signature by your web server (on your > freedom box) makes it easy to deploy. OK, and 1 click self-signature is just as easy to deploy. Sounds like we are in agreement here based on the basis of "no requirement" :)
Received on Thursday, 26 January 2012 15:23:14 UTC