Re: Person to key naming contest

On Tue, Oct 11, 2011 at 5:13 PM, 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.
>

another suggestion, using the plural for the property:
- cert:publicKeys
- cert:keys

Steph.


> 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.
>
> 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/
>
>