Subject: Ideas on new user attribute types and image formats

From: Peter Thomas <[email-masked]>
Date: Thu, 29 Jan 2009 19:23:04 +0100

Hi list.

This is not an official proposal or request. I haven't read RFC2434 yet ;-)

Just wanted to ask about opinions and ideas for new user attribute
types and image formats.

First perhaps the image formats as these are easier to discuss:
Of course JPEG is in principle enough and it's probably a very bad
idea to include any image type GIMP can open ;-) but I think the
following might be worth thinking about:
1) PNG (ISO 15948, RFC 2083)
Advantages:
- just as JPEG, nearly everybody can open these image format in the
meantime (even MS IE as far as I know)
- well standardized (ISO/IETF RFC)
- "We" call our "product" OpenPGP but JPEPG is - as far as I know -
patent encumbered, but PGP is fully free.
- Is providing an alpha-channel an argument?! ;-)
- lossless compression

Disadvantages:
- lossless compression leading to much bigger packets than with JPEG

2) JPEG 2000 (ISO/IEC 15444)
Advantages:
- well standardized (ISO) ... ok one could question that ^^
- provides even better/smaller quality/image sizes than JPEG
(And I think to keep image-packets small was the main reason for choosing JPEG)

Disadvantages:
- no widespread support
- standard is still incomplete (at least some additional parts, but
that wouldn't hurt "us" anyway)

3) SVG
Probably my most adventurous suggestion ^^
RFC 4880 say in chapter 5.12.1 that the image is not necessarily that
of the key owner.
I'm not fully sure what this means, but could it mean that an image
attribute subpacket is used to store for example an heraldic device
("I'm the king of Belgium and I'd like to include my emblem in my key"
*G*)?
If so, SVG would be useful file format (see Wikipedia for dozens of
heraldic devices in hight quality).

Second, ideas for user attributes:
This is more a: "Has anybody ideas how usage of user attributes could
be extended?" than a "I have this and that proposal.", so I'd really
love to see your ideas.

I personally think of the user ID packet (not the user attribute
packet) as kind of primary key (in the sense of databases).
The RFC says in chapter 5.11. that it is "intended to represent the
name and email address of the keyholder"; it doesn't say it must
(which is good in my opinion).
That way some organization, a company or university could use the User
ID like primary keys and set them to some staff or student number.

Most people surely follow the recommendation to use name/email with
RFC 2822 style.
This also fit's with my thinking of user IDs as some kind of primary
key as the email address makes the whole thing unique.

The user attribute packet introduced ways to better represent
properties of the key-holder.
Take my name "Peter Thomas" from just the user ID "Peter Thomas"
<[email-masked]> you cannot definitely say whether "Peter"
or "Thomas" is the first- or family-name. The naming schemes in other
cultures might be even "worse", just consider Arabic names
(http://en.wikipedia.org/wiki/Arabic_name).
Having attributes like:
- common name
- family names
- given names
- Kunya (Arabic)
- Nasab (Arabic)
may be something worth to implement.

Consider the following two example: My full name would be "Peter Marvolo Thomas"
a) My User ID only has "Peter Thomas" and my passport has the full
name "Peter Marvolo Thomas"
When another person validates my identity he can either sign it and
accept that it's missing part of my official name, or he can decline
to do so.
With the above user attributes, he could decide to just sign the
family name, but not the given names filed.
b) The example above vice versa, with full name in the user id, but
not in the passport.

Think of similar examples with Arabic names where it is much clearer
that this would be an advantage (as for example most western
government documents simply drop parts of Arabic names).

Other attributes that might be worth to implement:
-birthday (perhaps as UNIX time code ^^)
-birthplace/country/etc.
-other fixed body attributes like natural color of eyes and hairs

One could even think of stuff like:
- Jabber ID
- etc.

When you comment on this please remember that these are just ideas and
not proposals that I've thought about hours ;-)

Looking forward to see your comments,
Peter

---

From: Jon Callas <[email-masked]>
Date: Thu, 29 Jan 2009 11:28:53 -0800

> Just wanted to ask about opinions and ideas for new user attribute

I think you understand the pros and cons well enough. My personal  
opinion is that there's an argument for PNG, but not much else. And so  
far as I know, JPEG is not encumbered by patents at all, but there are  
people who would like it to be, especially if it's their patent.

I have no idea why you'd want to do SVG, and you seem to know anything  
I could say as to why not. So I'll just say that anything you put in  
would be a MAY, and if you put in something that no one's going to  
implement, you are arguably wasting your time.

However:

Write it up! Especially your thoughts about structured user  
information. The Jabber one is also good, since Jabber directly  
supports OpenPGP.

Do it informally here first, but also start looking at how to edit up  
an Internet Draft. The XML tools make it a lot easier than it used to  
be.

Oh, and you can't do birthday as a time_t. As shocking as it may  
sound, there are still living people who were born before 1-Jan-1970.  
Some of them even use computers.

	Jon

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 30 Jan 2009 10:23:47 -0500

> 1) PNG (ISO 15948, RFC 2083)

I fully agree that we should be supporting PNG here.  That's long
overdue, and you don't have to do lossless compression in png, iiuc.

> 2) JPEG 2000 (ISO/IEC 15444)

Given how ill-specified and implemented this is, i suggest waiting on
this until it is more mature.

> 3) SVG

SVG can potentially contain way more than images; it can contain
javascript, for example, and other semi-executable nastiness.  As much
as i love svg, I think it might be a can of worms best left unopened
until we're prepared to seriously think through the potential security
consequences.

> be extended?" than a "I have this and that proposal.", so I'd really

Duane Groth has proposed making a new User Attribute type that just maps
to the possible values of the X.509 subjectAltName specification:

http://open-pgp.info/wiki/index.php?title=Standardisation_of_OpenPGP_Keys_for_Server_Purposes#New_User_Attribute_Type_--_subjectAltNames

What's nice about this proposal is that it doesn't require the creation
of a new registry, implementors can potentially piggyback on existing
ASN.1 parsers (they wouldn't need to write their own), and the
specification can cover a range of ideas automatically.

	--dkg

---

From: David Shaw <[email-masked]>
Date: Fri, 30 Jan 2009 11:23:47 -0500

> overdue, and you don't have to do lossless compression in png, iiuc.

We need (in the abstract) a way to store a picture in an OpenPGP user
ID, and we have that now.  What does adding a second way to store that
picture buy us that we don't have already?

I'm not really for or against PNG in OpenPGP, but I don't yet see the
point here.

David

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 30 Jan 2009 12:42:38 -0500

> picture buy us that we don't have already?

hpng supports features that jpeg doesn't, including at least:

 * indexed colormaps
 * alpha-channel transparency

Both of these are useful features in some not uncommon circumstances
(e.g. logos and "hackergotchi"/floating-head images that discard
background/non-identity information).

I'm not suggesting that OpenPGP is worthless without PNG, of course.
But it would be useful to support it.

	--dkg

---

From: Jon Callas <[email-masked]>
Date: Fri, 30 Jan 2009 16:54:01 -0800

> But it would be useful to support it.

I'll add in that I think adding PNG is fine with me, and that's why  
I'll also be devil's advocate. So what?

I think that "because it would be cool" is a fine answer. We should  
say it, if that's why.

	Jon

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sat, 31 Jan 2009 11:27:29 -0500

> I think that "because it would be cool" is a fine answer. We should  

Good point!  FWIW, i actually have a couple specific implementation
possibilities in mind, because i'm interested in seeing an expansion of
places where OpenPGP is used [0].  The following ideas don't have
anything close to a concrete implementation yet, but transparent PNGs
would make them even more aesthetically appealing.

 * instant messaging: OTR [1] is a platform-agnostic IM
encryption/authentication layer, which currently uses RSA keys for
mutual authentication.  I'd love to see OTR be able to use the OpenPGP
web of trust to handle the actual authentication (though it currently
does not).  If it did, then PNG User Attribute support would allow
graphical OTR-compliant IM implementations to automatically select
hackergotchi-style images for pretty IM conversation displays (think
"word-balloon" style).

 * I'd like to see better cryptographic verification tools that take
advantage of OpenPGP's WoT to display human-comprehensible descriptions
of relevant trust paths to an attempted validation.  Since most people
use graphical environments, and most people recognize people by their
faces even more quickly than by their names, it would be great to show
such trust paths with images in them (e.g. "Mary says that this is Joe"
is useful, but a picture of Mary saying "this is Joe" would be even more
appealing to many users).

Plus, it would be cool ;)

These are just some ideas to chew on.  i wish i had more time to work on
such craziness.

	--dkg

[0] http://web.monkeysphere.info/ is the furthest advanced
implementation of any push to extend the reach of the OpenPGP
web-of-trust that i'm involved in.

[1] http://www.cypherpunks.ca/otr/

---

From: David Shaw <[email-masked]>
Date: Sat, 31 Jan 2009 22:46:55 -0500

> appealing to many users).

I like this one in particular.  The WoT is one of the least understood  
parts of OpenPGP.  Doing it graphically would help.

> Plus, it would be cool ;)

Yes.

David