Re: PGP aside

On 29 Dec 2011, at 13:30, Mo McRoberts wrote:

>> Another question with PGP: Is there something like a Subject 
>> Alternative Name in PGP? How does PGP identify the user? What 
>> other ways of identifying a user do they have?
> Sort of.
> The canonical method is to search for keys by e-mail address or key ID (derived from a hash of the key material) and then check the fingerprints.
> The e-mail address conventionally forms part of a "User ID" packet in a PGP certificate -- although technically its contents are completely free-form UTF-8 text (if you want it to be indexed by a key-server, you stick to the convention). There's no reason why this can't consist of or contain a URI.
> A public key will usually be carried alongside one or more user ID packets, each of which is followed by a signature binding the user ID to the key -- at the very least, for a user ID to be considered valid in the slightest it'll need a self-signature (WoT works by other people providing *additional* signatures to those user IDs).
> In effect, then, a user ID packet is a claim, which is initially self-asserted and may be supported by others. Conventionally, you can think of the content of a user ID packet as being a composite of foaf:name, foaf:mbox and rdfs:comment (ish), but it really is only convention which dictates that. If you wanted to publish a user ID packet consisting solely of "<>", you can -- whether anybody pays attention to it or not is a different matter (and if they do, they can opt to support your assertion by signing that user ID).
> Note however that the key server preference subpacket I described earlier is part of the signature itself, and would be part of the "hashed subpackets" portion (i.e., it forms part of the material being signed). So, you could do:
> Key 4096R/ABCDEF12
>  - User ID "Henry Story
>  - Signature
>    - Hashed subpackets:
>      - <blah>
>      - Key server preference:
>        ""
>    - Unhashed subpackets
>      - <blah>
>    - Truncated hash
>    - Signature value
> At this point, you've got the direct equivalent of a large RSA-bearing self-signed X.509 certificate with /CN=Henry Story/ as its DN and some extension or other referencing <> (be it as a SAN or as a key-distribution point, doesn't matter).
> What you could do, I guess, is apply a WebID-style approach to consumers such that:
> - If a Key server preference subpacket forms part of the hashed data on the self-signature; and
> - the key server preference contains an HTTP or HTTPS URI; and
> - linked data can be retrieved from that URI; and
> - the data states that one of the keys for that subject URI matches that used to create the self-signature
> ...then use that subject URI to identify the agent.
> The potential snag is that if any PGP software out there generates KSP subpackets without being explicitly told to (i.e., unwittingly giving some unknown third party the ability to 'be' you). A more likely potential snag is that nothing knows how to write that subpacket in the first place.
> Of course, if you wanted to go down this path, you could just define a "WebID subpacket" which works exactly the same way and has no such ambiguity.

Thanks, this is very interesting information.

As I see it now there are two sides to the PGP / LinkedData story

1. A way to tie a PGP certificate into linked data
  a. using the Key Server Preference
  b. creating a WebID sub-packet extension
2. a way to tie linked data into PGP
  - wot does this
  - the cert ontology can do this with a relation from WebID to certificate cert:ificate perhaps ;-)
  - indirectly by just expressing the public (RSA) keys that someone knows

So the answer to the question I asked Melvin "why is the fingerprint important" is presumably that he has a use case where some server knows linked data but finds it important to use PGP key servers that require the fingerprint to be able to find the right key, otherwise just pointing to the PGP key on disk would presumably be a lot more RESTful and simple.

There is no software currently that does 1(a) with linked data understanding. For either 1(a) and 1(b) one would have to find usage scenarios where the tying into linked data would be very useful. Currently 1(a) in the best situation points to a PGP certificate, which is not natively a linked data format. So one needs to find a way to jump out of the PGP space into the linked data space.

In the case of 2. I imagine that there are use cases where a linked data server can be interested in a user's PGP key/certificate, with signatures and all. (i.e. where just the cert:key relation is not enough).

That's what I understand of the problem for the moment.


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

Received on Thursday, 29 December 2011 13:29:18 UTC