- From: Mo McRoberts <Mo.McRoberts@bbc.co.uk>
- Date: Thu, 29 Dec 2011 12:09:45 -0000
- To: "Melvin Carvalho" <melvincarvalho@gmail.com>, "Henry Story" <henry.story@bblfish.net>
- Cc: "WebID XG" <public-xg-webid@w3.org>
it's worth noting also that a PGP fingerprint is composed entirely of key material... along with, I recently discovered, the "key creation timestamp" (relative to unix epoch), which is included in a PGP pubkey packet. the combination of some well-known constants + RSA or DSA primitives + timestamp (dct:created ?) is enough to generate a key ID/fingerprint for v4. For v3 keys, you'll want an expiry timestamp as well (v4 moved it into the signature packets instead). Applications "SHOULD" [RFC2119 parlance] be generating v4 keys, but the packet dumps I have in front of me just now suggest that GnuPG generates v3 by default, though it can read v4 without issue. M. (apologies for top-posting) -- Mo McRoberts - Technical Lead - The Space, 0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E, Project Office: Room 7083, BBC Television Centre, London W12 7RJ > -----Original Message----- > From: Melvin Carvalho [mailto:melvincarvalho@gmail.com] > Sent: Thursday, December 29, 2011 12:05 PM > To: Henry Story > Cc: Mo McRoberts; WebID XG > Subject: Re: PGP aside > > On 29 December 2011 13:03, Henry Story > <henry.story@bblfish.net> wrote: > > > > On 29 Dec 2011, at 12:17, Melvin Carvalho wrote: > > > >> On 29 December 2011 10:31, Mo McRoberts > <mo.mcroberts@bbc.co.uk> wrote: > >>> A brief aside, which may or may not be of interest to WebID folk. > >>> > >>> I was reading through the OpenPGP spec last night, and > noticed section 5.2.3.18 which describes the “Preferred Key > Server” signature subpacket: > >>> > >>> “5.2.3.18. Preferred Key Server > >>> > >>> > >>> (String) > >>> > >>> This is a URI of a key server that the key holder > prefers be used for > >>> updates. Note that keys with multiple User IDs can > have a preferred > >>> key server for each User ID. Note also that since this > is a URI, the > >>> key server can actually be a copy of the key retrieved > by ftp, http, > >>> finger, etc.” > >>> > >>> It strikes me that as the spec explicitly provides for > serving up a static resource (rather than the target being > the URI of an HKP or LDAP server), it could quite easily be > an endpoint which performs content negotiation and returns a > variety of formats, for example PGP key data *and* linked > data (which might contain, for example, a WebID profile). > >> > > > > yes, very cool. I have been wondering about this for a long time. > > > >> Nice find. I already do this using the wot: vocal. > > > > You could do this with the cert ontology too no? What is missing? > > fingerprint? > > > > > Henry > > > >> > >>> > >>> M. > >>> > >>> -- > >>> Mo McRoberts - Technical Lead - The Space, > >>> 0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E, > >>> Project Office: Room 7083, BBC Television Centre, London W12 7RJ > >>> > >>> > >>> > >>> http://www.bbc.co.uk/ > >>> This e-mail (and any attachments) is confidential and may > contain personal views which are not the views of the BBC > unless specifically stated. > >>> If you have received it in error, please delete it from > your system. > >>> Do not use, copy or disclose the information in any way > nor act in reliance on it and notify the sender immediately. > >>> Please note that the BBC monitors e-mails sent or received. > >>> Further communication will signify your consent to this. > >>> > >>> > >> > > > > Social Web Architect > > http://bblfish.net/ > > > http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this.
Received on Thursday, 29 December 2011 12:10:29 UTC