- From: Dan Brickley <danbri@danbri.org>
- Date: Tue, 11 Oct 2011 23:27:06 +0200
- To: Henry Story <henry.story@bblfish.net>
- Cc: WebID XG <public-xg-webid@w3.org>
On 11 October 2011 23:13, Henry Story <henry.story@bblfish.net> wrote: > So it looks like there is not that much of a consensus on naming the inverse > of cert:identity. > cert:publicKey is the closest, but it is just too close to cert:PublicKey > the class name for the moment, and other ontologies have made that a > relation between the certificate and its public key, rather than between the > person and the key he knows, owns, controls, possesses.... > So some brainstorming is needed. FWIW here is some older discussion around putting related things also into FOAF ns, for simpler single-namespace deployment in RDFa markup. http://openetherpad.org/fXuqiu8nem ... I'm totally unsure what the best thing to do here is, but just wanted to re-mention the possibility. Dan > Henry > > Begin forwarded message: > > From: Henry Story <henry.story@bblfish.net> > Subject: Re: Vote: public_key, publicKey, hasPublicKey, pubKey > Date: 11 October 2011 23:03:47 CEST > To: Peter Williams <home_pw@msn.com> > Cc: public-xg-webid@w3.org > > > On 11 Oct 2011, at 18:32, Peter Williams wrote: > > How about cert:owns. Or some other social relationship name addressing the > "control" of "ownership" > > yes, indeed moving to the social/ownership relationship is somewhat better. > Of course you can't own a cert or a public key as you point out below since > those are mathematical structures. > cert:controls > > is another one, but one does not really control anything in life. > So would > cert:knows > be better, as I suggested to move towards an epistemological relation? Well > that would be odd, because everybody who looked at that relation would > wonder how come that person knew the public key better than them. > What about if given that we are speaking of keys, we speak in terms of > abilities to do something with those keys? > cert:unlocks > seems closer. The user can unlock what should have been called a public lock > with his private key. > Henry > > > Some people believe, depending on CA, they own the cert. Typically, they > dont. Only with the better CAs does it even matter. > > What folks typically own is the private key (which implies the public key, > in RSA math). As bankcrupcy proceeding REGULARLY show, private keys are > among the assets transferred to new owners by court processes involving > public auction, along with their containers and any arming devices. Often, > the private key is a file on a UNIX file system used by a cern-grade > webserver (agumented with openssl(3) typically), accesible by anyone with > root privileges - including the new "owner". The disk drive is the key > container, and crackable using typical police-style forensic methods used > every day. These may well include reading disk blocks...using the IDE > interface, into RAM; which again happens a thousand times a day in US > policing. > > Sometimes, the new owner gets confused about the status of the cert [file], > and tries to use it on their web server. They may receive a polite note, > about governance conditions over the cert as IP (that typically do NOT > inure to the benefit of the new owner of the public key). THough the > previous owner was a subscriber, with obligations to report to the CA why a > cert's valid status shoudl be revoked, this often does not occur (and the > bankcrupcy proceeding may well make it almost impossible to enforce, > legally, former-subscriber opbligations, even when, as is common, they > continue after termination/severance of the contract due to a default. Thus, > contact with the new key owner, now mis-using the cert, is often the first > opportunity to do a clean up of the cert:own relationships. > > Of course, none of this happens with your $10 dollar cert from certs-are-us, > or one minted yourself. But, these service exist in the SSL market so > vendors can compete with the assurnace of your typical PGP and SSH keys, and > appeal to those who are perfectly happy with PGP/SSH type assurances. A > large market exists for this, and I can see no reason why it should not. How > cert:owns works in this "commodity crypto" world, I cannot really say. Its > probably got something to do with some vague "social" convenant involving > someone licensing IP licenses. > > In the better world of TTPs, the (public) authority maintains the assurance > for client ids as much as server ids. > > > > > > >> Date: Tue, 11 Oct 2011 08:24:53 +0200 >> From: sergio.fernandez@fundacionctic.org >> To: henry.story@gmail.com >> CC: public-xg-webid@w3.org; scorlosquet@gmail.com >> Subject: Re: Vote: public_key, publicKey, hasPublicKey, pubKey >> >> 2011/10/10 Henry Story <henry.story@gmail.com>: >> > cert:knows >> > cert:knowsKey >> > cert:controlsKey >> > is there a better name for that type of relation? >> >> An what about a simple cert:controls [ cert:Key ] ? >> >> -- >> Sergio Fernández >> CTIC - Technological Center >> Parque Científico y Tecnológico de Gijón >> C/ Ada Byron, 39 Edificio Centros Tecnológicos >> 33203 Gijón - Asturias - Spain >> Tel.: +34 984 29 12 12 >> Fax: +34 984 39 06 12 >> E-mail: sergio.fernandez@fundacionctic.org >> http://www.fundacionctic.org >> Privacy Policy: http://www.fundacionctic.org/privacidad >> > > Social Web Architect > http://bblfish.net/ > > Social Web Architect > http://bblfish.net/ >
Received on Tuesday, 11 October 2011 21:27:46 UTC