ietf-openpgp
[Top] [All Lists]

Re: [openpgp] User ID conventions (it's not really a RFC2822 name-addr)

2019-09-19 13:10:12
I'd like to have a clearer undersatnding about the actual conventions
for OpenPGP User IDs in the context of e-mail.  The standards currently
say that the convention is an RFC2822 "name-addr", but (as detailed
below), that does not appear to be the actual convention in practice.

A simple place to start is that RFC 6531 seems to be the present 
upgrade/replacement for RFC2822. There have been interim ones and I didn't 
spend a lot of time sorting out details. Whatever the present successor is, 
let's just call it R.


While we're updating RFC 4880, we should fix the standards to reflect
reality.  There are two proposals at the end that i'd love feedback on.
I prefer proposal 2.

I think I do, too, with your addenda. 

Rewinding to history and second if not first principles, the User ID field is 
ideally free-form text. The most common free-form text is an email address, and 
that's described by R, and I think your proposal 2.

However, there are a lot of places where people have put human-readable text in 
(e.g. "XYZ Group Release Signing Key") that doesn't have a machine readable 
context at all. There have also been X.500 Distinguished Names, Common Names, 
and so on put there. There have been other outré uses as well. As long as we 
don't end up with it being *precisely* an email address, meaning that we outlaw 
just plan text, I think it's fine.

At one time, I really wanted User Attribute Packets (created for having images 
as IDs), to have other types of structured data including email addresses. The 
reasons for not doing it then (it's a pain, and who's going to support it) 
apply today. It's still a good idea, though.

If whatever you come up with precludes text with no machine meaning, I think 
you hit the flip side of having a defined type of ID: there's lots of things 
that already don't meet it, and people will just ignore what's there because 
history.

Operationally, I think that supporting Just Text merely means that if the field 
fails parsing rules (like Proposal 2) then it's Just Text and we're moving on.

        Jon


_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp