Re: Certificate Expiry

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