Re: Person to key naming contest

On 11 Oct 2011, at 23:27, Dan Brickley 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.
> 
> FWIW here is some older discussion around putting related things also
> into FOAF ns, for simpler single-namespace deployment in RDFa markup.
> http://openetherpad.org/fXuqiu8nem  ... I'm totally unsure what the
> best thing to do here is, but just wanted to re-mention the
> possibility.

Yes, it covered a lot of ground.  Again the main aim is still to keep things simple for the reasons you mentioned recently on the foaf-dev mailing list - that is the more relations we support the more difficult it is to test them, and the more difficult it becomes to build applications that use these tools.

The good news is that according to this report sent to us by Ryan Sleevi "What really breaks SSL" [1], on page 21 it is shown that all but 9 server certificates found on the web use RSA. Since rsa is what ties most of the certs and in all formats together, we have simplified PGP and X509 down to what they are all based on in the end. We can always add DSA and other key formats as they really start getting adopted -- but that leaves us quite a bit of time.
 
Another reason for having this in RDF (as opposed to pointing to other formats) is that this then allows us to place the public key in the same file as the one describing the WebID so that having dereferenced the WebID the agent can then find links to all kinds of other files.

Now since a WebID Profile can also be thought of as a certificate - a self signed one I suppose - then one could use the 
rel:alternate links from the profile to the x509 and PGP versions of the certificate.

<link rel="alternate" type="application/pgp" href="card.pgp"/>


I don't buy too much into the single namespace argument, especially as the notion of rdfa profiles has now been accepted. 

    http://www.w3.org/TR/rdfa-core/#s_profiles

though I have not yet found a good example of its being used - I have not played with them yet. Still I would not be against merging the rsa ontology into the cert ontology, given that it is so small, and that they are so closely linked. But again this comes now at a cost of people developing the webid libraries yet again.

   Henry


[1] http://blog.ivanristic.com/Qualys_SSL_Labs-A_Study_of_Really_Breaks_SSL-HITB_Amsterdam_2011.pdf

> Dan
> 
>> 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 08:37:45 UTC