- From: Henry Story <henry.story@bblfish.net>
- Date: Sat, 28 Jan 2012 10:04:36 +0100
- To: public-webid@w3.org
- Cc: Jürgen Jakobitsch <j.jakobitsch@semantic-web.at>, Carvalho Melvin <melvincarvalho@gmail.com>
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. > >> >>> >>> 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/
Received on Saturday, 28 January 2012 09:05:17 UTC