Re: Person to key naming contest

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.

Happy for the to be brain storming.

Suggest we go with cert:publicKey unless a better idea presents itself.

Or if it's going to rejected anyway, then why have it as one of the votes :P

Henry, if you pick the one you think is most appropriate, I'm happy to
go with that.  I do think cert:identity should be inverted, yes.

BTW any thoughts on including privateKey too (or privKey perhaps in
the other notation)?

> 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 23:03:58 UTC