Re: Certificate Expiry

On 26 January 2012 15:39, Henry Story <henry.story@bblfish.net> wrote:
>
> On 26 Jan 2012, at 15:29, Joe Presbrey wrote:
>
>>>>> On 26 Jan 2012, at 08:33, Joe Presbrey wrote:
>>>>>> The notion of self-signed WebID certificates (securely) expiring is invalid and quite easily misunderstood. There are no assurances for start/end dates (or any other properties, eg. WebID URI!) within the certificate itself.
>>
>>>> On 26 January 2012 10:57, Henry Story <henry.story@bblfish.net> wrote:
>>>>> Not all WebID certificates are self signed. They can be signed by the service that creates them.
>>
>> So you agree then about not checking dates on self-signed certs.
>
> 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.

I'm kind of a believer in using the right tool for the right job.

Although webid can *theoretically* be used for short lived
certificates.  I doubt anyone has ever tried this.

On the other hand services like oauth, facebook connect and browserid
issue almost exclusively short lived tokens.

The UI for managing certs is right now so complex in WebID that I
think, although an intellectually interesting exercise, WebID should
shift focus away from short term certs or until people start
clamouring for the use case.

I'd love to see WebID as a great option in a selection of
authentication methods.  Maybe you use it on your favourite browser at
home.  Perhaps one day someone will build a robot using WebID.

But as an example flow, lets say you were demoing something at your
friends house, you could log in with, say, with your gmail account
with a one time token.  ie get the best of all worlds but at the same
time encourage growing use of WebID.

>
>>
>>>>> 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.
>>
>> Yes, it is a bad thing. Asking services to sign users so you can trust
>> the X509 properties increases "total fail" significantly when the
>> service is compromised [1].
>
> 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.
>
>> When starting from zero, there is no
>> reason to trust a stand-alone "service" WebID if you can't trust a
>> stand-alone "user" WebID, and therefore their respective assurances do
>> not compound. The only time I can see signed WebIDs being useful is if
>> you want a managed/corporate/closed WebID environment. Henry, please
>> help us stay free and open!
>
> 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.
>
>> X509 and CAs are not the good parts of WebID we should be
>> exploring/extending. eg. SSH and GPG-generated keys are also great for
>> WebID, as proven by Melvin. At Web scale, its best to strive for
>> decentralization.
>
> Yes, having limited number of CAs in the browser is what is problematic.
> But if each of us can be a "CA" then you know what's wrong with that :-)
>
>>
>>>>>> This is precisely why we resolve the WebID URI: to check if the claims in the certificate are true. We could also check the URI/LD to see if dates match, but we don't currently have schema for that
>>
>>> On 26 Jan 2012, at 11:01, Melvin Carvalho wrote:
>>>> Perhaps validFrom and validTo would make more sense than oldKey as a predicate
>>
>> I agree. Surely I meant: don't *yet* have schema for that :)
>>
>> [1] http://tech.slashdot.org/story/11/10/28/1954201/four-cas-have-been-compromised-since-june
>
> Social Web Architect
> http://bblfish.net/
>

Received on Thursday, 26 January 2012 15:49:38 UTC