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"
<p4(_dot_)thomas(_at_)googlemail(_dot_)com> 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