Person to key naming contest

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.

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/