Re: Certificate Expiry (summary)

On 1/28/12 4:04 AM, Henry Story wrote:
> On 27 Jan 2012, at 14:10, Henry Story wrote:
>
>> On 27 Jan 2012, at 13:55, Melvin Carvalho wrote:
>>
>>> On 27 January 2012 13:47, Jürgen Jakobitsch
>>> <j.jakobitsch@semantic-web.at>  wrote:
>>>> 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)
>>> Isn't this logic delegated to the X.509 spec?
>> yes, but that does not mean we can't put a developer guide
>> on our wiki.
>>
>> I would argue very simply:
>>
>> - the client sends you a certificate which is a set of claims
>>    if those claims contain an assertion that the certificate is
>> expired there is prima facie reason to respect that assertion.
>>
>> - if that claim is non expired and you fetch the profile which
>>   does state that they key is expired (to be defined) then
>>   there is reason to believe that your supporting evidence states
>>   that the key is expired and hence that knowledge of the private key
>>   does not constitute proof of webid = knower of private key identity.
>>
>> People who wish never to have issues with (1) can create very long
>> lasting certificates. If people create short lasting certificates in
>> (2) there may be a reason. Perhaps they have a game they are playing
>> where n people each get 1 hour to accomplish a task. These n people
>> act as one agent.
> except that one should point out that such rules will not be enforceable
> cryptographically, and not just because some servers might not want to
> abide by what is written in the X509 Certificate, but even if all did,
> because any person who was able to get hold of the private key and the
> certificate - i.e.. any user in the game - could just make another
> (self-signed, or not) certificate and use that, and no server would be
> able to make a distinction. There is therefore a big difference between
> the statements in the certificate and those at the WebID Profile, because
> only the statement of identity to the public key at the WebID Profile
> has an epistemological weight.
>
>
> If the verifier were to use the Issuer Alternative Name, and trusted the
> Issuer, then things would be different. It would know that any claims in
> the certificate made were valid by the issuer for a certain amount of time.
> So the game would have to be played differently: it would have to be such
> that only certificates issued by an Issuer or a foaf:Group of Issuers were
> valid. The Access Control Rules then would be something along the following
> lines: Resources Rx can be accessed by any Agent whose valid certificate
> was signed by IssuerX.
>
>   So in conclusion then I think that
>
> 1. an outdated certificate SHOULD (MUST?) generate a warning
>     but need not be binding when using WebID authentication for
>     the verification. It should generate a warning for the reasons
>     given above, and also because it is quite possible that some
>     servers will drop the certificate automatically. (For example
>     those that rely on the Issuer, or simply software build with
>     CAs thinking exclusively in mind)
>
> 2. if the content of the certificate is trusted because of
>     trust in the Issuer then the X509 rules MUST apply.
>
>>    Does that make sense? If so perhaps we can put it up
>> in some part of the wiki (HOWTO section?)
> Ok, so I am back to what I think I was arguing initially a few years ago.
> I think this sounds better. In fact we should perhaps even add this to the
> spec, as this will be unusual to people dealing with X509 Certs normally.

Yes.

+1

Kingsley
>
>>>> 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#"
>>>>
>> Social Web Architect
>> http://bblfish.net/
>>
> 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