Re: Certificate Expiry

On 26 Jan 2012, at 16:22, Joe Presbrey wrote:

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

Why "only"? X509 allows you to put it in your certificate. So since
we are suing a tool that allows that, why not apply the X509 rules here?


> Or you can remove the public key from the LD. We need something that works
> with ALL WebIDs, not only signed WebIDs.

If there is an OR here it is not an XOR. It is both. You can do both. 
Currently the X509 method is already specified. And it can be useful to stick 
with  it. 

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

Why? Seems perfectly ok to me, for someone else to sign my cert.
Hey if we had PGP SSL more widely deployed why we could have more
than one person/box sign the 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).

Just as each of these additional signatures don't create each one additional
single points of failure, so does having your certificate signed not create
an additional point of failure. It's the same. S

> 
> Consider the direction even major CAs (should be / are) taking, eg.
> http://www.links.org/files/CertificateAuthorityTransparencyandAuditability.pdf:

yes, those are policies for certificates in the browser, which is where the
centralisation problem comes from.  But I am speaking of a distributed CA if you
want. I am speaking of using the Issuer Alternative Name which is also available.
We can put a WebID there too. Click on the IAN and you can get a WEbID Profile 
for the issuer, which can also be linked in a network of trust. 

Think about that :-)

> 
> "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" :)



Social Web Architect
http://bblfish.net/

Received on Thursday, 26 January 2012 15:46:02 UTC