- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Fri, 16 Dec 2011 16:54:17 -0500
- To: Henry Story <henry.story@bblfish.net>
- CC: public-xg-webid@w3.org
- Message-ID: <4EEBBE09.50009@openlinksw.com>
On 12/16/11 4:40 PM, Henry Story wrote: > > On 16 Dec 2011, at 22:20, Kingsley Idehen wrote: > >> On 12/16/11 3:33 PM, Peter Williams wrote: >>> Cert refers not to certificate but the certificate type... In the >>> ssl spec. Todate, there are 2 blobs/types: x509 and pgp (see gnu tls >>> libraries for the pgp cipher suites) >>> >>> If u look at my code, it distinguishes referencing the cert type >>> from the x509 cert type specifically. Interpreting the context >>> property as x509 required a specific cast (which would throw type >>> checking errors if infact a pgp cert type was tied to the property). > > Currently we don't use the X509 and PGP classes in the WebID > specification. They were in the ontology initially to help me think > about how these pieces related to one another. So if you are using > them I don't think it is something defined. Remember, we extended the ontology in our own namespace. My response was more to do with reading the ontology and how it describes crytpo components. Ditto the separation of x.509 and PGP certs. > >>> >>> Subtle. But it's the difference between code designed to type check >>> as part of the assurance requirements and code that is a script >>> parsing strings. >>> >>> Sent from my iPhone >> >> Yes, it's always easier when the ontology and the world is defines is >> readable. >> Others see: >> >> 1. >> http://uriburner.com/describe/?url=http%3A%2F%2Fwww.w3.org%2Fns%2Fauth%2Fcert%23 >> -- main Ontology > > I need to update the UML diagram there. It's out of date.... > That's another reason to keep things simple btw. Just having something > as simple as we have, is a lot of work to deal with! The more accessible and readable material is the easier it becomes to spot and fix issues :-) Kingsley > > Henry > > >> 2. >> http://uriburner.com/describe/?url=http%3A%2F%2Fwww.w3.org%2Fns%2Fauth%2Fcert%23Certificate >> -- Certificate definitions within Ontology . >> >> Kingsley >>> >>> On Dec 16, 2011, at 11:00 AM, "Bob Wyman" <bob@wyman.us >>> <mailto:bob@wyman.us>> wrote: >>> >>>> >>>> On Fri, Dec 16, 2011 at 1:20 PM, Henry Story >>>> <henry.story@bblfish.net <mailto:henry.story@bblfish.net>> wrote: >>>> >>>> >>>> On 16 Dec 2011, at 19:03, Bob Wyman wrote: >>>> >>>>> I'd really like to see a "publickey" link relation for >>>>> WebFinger which would point to one or more public keys that >>>>> are associated with the acct:. There doesn't seem to be >>>>> anything like this in the existing registry. Does anyone know >>>>> if such a thing is defined anywhere else? If not, should I >>>>> create an Internet Draft to register publickey? Is there some >>>>> reason that we should *not* have a publickey link relation? >>>> >>>> Well you can use WebID's cert:key relation to point multiple >>>> times to a number of public keys. >>>> There is an example in RDFa on http://webid.info/spec . (The >>>> spec has just got a very large overhaul, so check it out again ) >>>> >>>> As is clear from the name of the cert:key relation, it links to a >>>> certificate -- which is only one way to represent a key. >>>> Personally, I think this is the wrong way to do things. The link >>>> relation should indicate the semantic intent of the object which is >>>> linked to rather than its type, encoding, or whatever. >>>> Identification of media, encodings, etc. are, I believe, more >>>> appropriately handled via the "type" attribute. (Note: Salmon's >>>> Magic-Keys do not use certificates...) >>>> >>>> So, WebId's "cert"key" is close to what is needed, but not quite >>>> appropriate in that it lacks flexibility and imposes assumptions >>>> that aren't valid in all contexts. >>>> >>>> >>>> So I think Salmon being based on Atom does have space for you >>>> to put your WebId in your atom. >>>> >>>> Salmon Magic Signatures are not "based" on Atom and have no >>>> dependencies on Atom. Magic Sigs can be used with arbitrary >>>> payloads -- as long as that payload is base64url encoded in the >>>> Magic Signature. Both XML and JSON encodings are provided for the >>>> Magic Signature bits... >>>> >>>> I think one could argue that the >>>> atom:id field could play this role. >>>> >>>> The atom:id field is defined clearly in the Atom Syntax >>>> specification and should not be used for anything other than its >>>> defined purpose. >>>> >>>> I do that in my atom feed, which I am slowly reviving. >>>> >>>> http://bblfish.net/blog/blog.atom >>>> >>>> Then when you dereference the id you find in my atom you can >>>> get straight to any number of my keys. >>>> >>>>> >>>>> What I envision is something like the following: >>>>> >>>>> <Link rel="publickey" >>>>> type="http://salmon-protocol.org/ns/magic-key" >>>>> href="http://example.com/mymagic-keys.json"/> >>>>> >>>>> The idea is that, when using protocols like Salmon Magic >>>>> Signatures >>>>> <http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-01.html>, >>>>> you would be able to say "This was signed with >>>>> acct:bob@example.com <mailto:acct%3Abob@example.com>'s key" >>>>> and have people then use WebFinger to fetch the public key >>>>> that should be used to verify the signature. >>>> >>>> I think if web finger were reliably to be able to point people >>>> to your WebID then that would be a very good place to publish >>>> your public keys. >>>> >>>> >>>>> >>>>> (Yes, I am aware that Magic Signatures already defines a >>>>> Property serialization for magic-keys, however, I'd like to be >>>>> able to link to the keys as well as have a general mechanism, >>>>> not specific to Magic Signatures, for linking to keys that >>>>> might be in other formats -- such as X.509 certificates.) >>>>> >>>>> bob wyman >>>>> >>>>> >>>>> On Wed, Dec 14, 2011 at 2:17 PM, Peter Saint-Andre >>>>> <stpeter@stpeter.im <mailto:stpeter@stpeter.im>> wrote: >>>>> >>>>> On 12/14/11 12:11 PM, Gonzalo Salgueiro wrote: >>>>> > >>>>> > On Dec 14, 2011, at 12:26 PM, Peter Saint-Andre wrote: >>>>> > >>>>> >> On 12/14/11 10:18 AM, Paul E. Jones wrote: >>>>> >>>>> <snip/> >>>>> >>>>> >>> My thinking for the link relations is that we ought to >>>>> investigate >>>>> >>> using the registry that was established by RFC 5988. >>>>> So, rather than >>>>> >>> have link relations sprinkled around the web, should >>>>> we centralize >>>>> >>> them at IANA? >>>>> >> >>>>> >> s/investigate using/use/ >>>>> >> >>>>> > I'm in full agreement here and immediately see the >>>>> benefit of such >>>>> > centralization. >>>>> > >>>>> > Peter - What is the best way to kick that off? I >>>>> suppose a separate >>>>> > draft/RFC would be required to establish an IANA >>>>> registry for link >>>>> > relations. If so, I can get started on making that happen. >>>>> >>>>> Mark Nottingham (cc'd) already did that work for you... :) >>>>> >>>>> http://tools.ietf.org/html/rfc5988 >>>>> >>>>> The registry is here: >>>>> >>>>> http://www.iana.org/assignments/link-relations/link-relations.xml >>>>> >>>>> Instructions for registering new relations are here: >>>>> >>>>> http://tools.ietf.org/html/rfc5988#section-6.2.1 >>>>> >>>>> However, Mark might be simplifying those procedures (in >>>>> line with recent >>>>> thinking about making it easier to interact with IANA). >>>>> >>>>> Some examples of forthcoming relation registrations can be >>>>> found in >>>>> three documents that I'm currently shepherding at the IETF: >>>>> >>>>> https://datatracker.ietf.org/doc/draft-ohye-canonical-link-relation/ >>>>> >>>>> https://datatracker.ietf.org/doc/draft-amundsen-item-and-collection-link-relations/ >>>>> >>>>> https://datatracker.ietf.org/doc/draft-yevstifeyev-disclosure-relation/ >>>>> >>>>> Peter >>>>> >>>>> -- >>>>> Peter Saint-Andre >>>>> https://stpeter.im/ >>>>> >>>>> >>>>> >>>> >>>> Social Web Architect >>>> http://bblfish.net/ >>>> >>>> >> >> >> -- >> >> Regards, >> >> Kingsley Idehen >> Founder& CEO >> OpenLink Software >> Company Web:http://www.openlinksw.com >> Personal Weblog:http://www.openlinksw.com/blog/~kidehen >> Twitter/Identi.ca handle: @kidehen >> Google+ Profile:https://plus.google.com/112399767740508618350/about >> LinkedIn Profile:http://www.linkedin.com/in/kidehen >> >> >> >> > > Social Web Architect > http://bblfish.net/ > -- Regards, Kingsley Idehen Founder& CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Friday, 16 December 2011 21:58:48 UTC