RE: Person to key naming contest

 do you really want to assert the public in publicKey? remember, SSL is about public CAs - meeting civil society. The web is not about that (being its own thing). perhaps drop the unthinkable , the term publickey. After all, it just means the disclosableKeyComponent. There need be no assumption (as in the SSL design philosophy) that its part of the "public" space.> From: henry.story@bblfish.net
> Date: Wed, 12 Oct 2011 01:59:20 +0200
> CC: public-xg-webid@w3.org
> To: melvincarvalho@gmail.com
> Subject: 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/
> 
>