Re: Person to key naming contest

On 12 Oct 2011, at 01:03, Melvin Carvalho wrote:

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

only if we can find a reason as to why the name clash is not a big deal. I find it
worrying that one have two relations that differ by just the upper and lower case 
of one character.

Now you mentioned http://payswarm.com/vocabs/security#publicKey

It has the following example (which does not seem to use the publicKey relation?!)

{
   "@subject": "https://payswarm.example.com/i/bob/keys/1",
   "@type": "sec:Key",
   "ps:owner": "https://payswarm.example.com/i/bob",
   "sec:publicKeyPem": "-----BEGIN PRIVATE KEY-----\nMIIBG0BA...OClDQAB\n-----END PRIVATE KEY-----\n"
}

what is that in N3 by the way? Is that the same as

<https://payswarm.example.com/i/bob/keys/1> a sec:Key;
  ps:owner <https://payswarm.example.com/i/bob>
  sec:publicKeyPem "..." .

I am not sure if sec:publicKey is meant to be the same type of relation as publicKeyPem ... Anywhere there is something that is not clear there...



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

It was close to public_key which is what we have on the web now. 

Votes help get some general idea of  where people stand, but reasons are more important than 
votes in my view. 

cert:publicKey does have a lot of pro votes, but votes cannot by themselves overcome the potential spelling type issues
between PublicKey and publicKey . I am more waiting arguments there.

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

I don't know what the most appropriate is.

cert:identity is good because everybody has implemented it. Anything that makes things
more complex is by default a bad idea. This is why we need the buy in of library implementors on 
the solution, as well as of people publishing profiles.

It is easy to make things more complex, and very easy to make them infinitely complex.
But when we ask people to help build test suites for their implementations I get a lot less participation. Every complexity we add is more tests to add to the test suites, more chance of us not working with older implementations, etc...


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

yes, one could. But I suppose a use case would be useful.

Henry


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

Social Web Architect
http://bblfish.net/

Received on Wednesday, 12 October 2011 00:00:03 UTC