Re: Certificate Expiry (summary)

hi,

is there a final conclusion on this issue yet,
which an implementor can rely on?

i think it would be a good idea to write a couple 
of lines into spec about this. from only reading 
the spec now, i have no clue what to do with the dates
in a certificate.

at current the best solution for WebIDRealm seems
to simply have some boolean flags that get read on startup.

mindCertificateNotYetValid (=true|false)
mindCertificateExpired (=true|false)

wkr j

----- Original Message -----
From: "Kingsley Idehen" <kidehen@openlinksw.com>
To: public-webid@w3.org
Sent: Thursday, January 26, 2012 8:02:27 PM
Subject: Re: Certificate Expiry (summary)

On 1/26/12 1:32 PM, Henry Story wrote:
> On 26 Jan 2012, at 19:12, Kingsley Idehen wrote:
>
>> On 1/26/12 12:08 PM, Joe Presbrey wrote:
>>> Hi all,
>>>
>>> I caught up with Henry in a quick chat earlier about this and will let
>>> you know a quick summary. Of course we all agree on extending the
>>> trust network via URIs, resolving, issues and signers, cosigners,
>>> freedom and liberty boxes, server clients, etc. all day long. In
>>> addition:
>>>
>>> 1) we should distinguish old keys from current keys with status,
>>> issuer, date, and/or other properties of the key in our profiles
>> Okay, so do we tweak the Cert. Ontology accordingly? Or make an adjunct
>> Assurance Ontology?
> I don't see a problem adding a few notBefore/notAfter relations to the
> cert ontology. We would want to state somehow that the relation between
> the user and the public key as being one of identification was only valid
> for a certain amount of time.
>
> What I am wondering is if that would make a difference to your argument
> outlined in the thread. If someone were to use certificate with a WebID
> that was backed up by a Profile whose key was described as being
> expired, would not the argument you had outlined in the thread still
> hold? Ie, that this is an issue with authorisation and not
> authentication?

Grey area that sits between the realms of Authentication and Authorization.

Tweaking the ontology solves the problem.  Solomon was an ontologist :-)


Kingsley
>
>>> 2) expired self-signed WebIDs should not "go out with the trash", if a
>>> hacker finds it, they can pretend they are you unless (1)
>>>
>>> 3) we should regard x509 properties in addition to (1) while WebID is
>>> delivered via x509, but prefer LD mechanisms to be compatible with
>>> other containers and transports
>> Yes.
>>
>> Kingsley
>>
>>> Best,
>>>
>>> --
>>> Joe Presbrey
>>>
>>>
>>> On Thu, Jan 26, 2012 at 11:40 AM, Henry Story<henry.story@bblfish.net>   wrote:
>>>> yes make sense +1 - just add Summary to front of the e-mail subject.
>>>> I think it would be good if each thread had a little summary.
>>>>
>>>> On 26 Jan 2012, at 17:35, Joe Presbrey wrote:
>>>>
>>>>> I drafted this summary email, if it looks good to you, do you want to send it?
>>
>> -- 
>>
>> Regards,
>>
>> Kingsley Idehen 
>> Founder&   CEO
>> OpenLink Software
>> Company Web: http://www.openlinksw.com
>> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
>> Twitter/Identi.ca handle: @kidehen
>> Google+ Profile: https://plus.google.com/112399767740508618350/about
>> LinkedIn Profile: http://www.linkedin.com/in/kidehen
>>
>>
>>
>>
>>
>>
> Social Web Architect
> http://bblfish.net/
>
>
>


-- 

Regards,

Kingsley Idehen 
Founder&  CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen







-- 
| Jürgen Jakobitsch, 
| Software Developer
| Semantic Web Company GmbH
| Mariahilfer Straße 70 / Neubaugasse 1, Top 8
| A - 1070 Wien, Austria
| Mob +43 676 62 12 710 | Fax +43.1.402 12 35 - 22

COMPANY INFORMATION
| http://www.semantic-web.at/

PERSONAL INFORMATION
| web       : http://www.turnguard.com
| foaf      : http://www.turnguard.com/turnguard
| skype     : jakobitsch-punkt
| xmlns:tg  = "http://www.turnguard.com/turnguard#"

Received on Friday, 27 January 2012 12:47:50 UTC