Re: [openpgp] Possible ambiguity in description of regular expressions: [^][]

[Ángel <[e-mail]>]

On 2021-01-09 at 08:42 -0500, Daniel Kahn Gillmor wrote:
> On Sat 2021-01-09 01:08:10 +0100, Ángel wrote:
> > Finally, another point to consider would be whether to match only
> > the email address portion. Yes, User ID could contain something
> > else, but this delegation of partial trust only seem useful when
> > combined with a hierarchical structure, such as those to be found
> > on the email address part. It seems rare to require a matching on
> > the display name part. And allowing that would greatly decrease its
> > security. Basically a wildcard not on the left-most side could be
> > bypassed by including the required characters on the display name.
> 
> This stuff is very rarely used in the wild, and to the extent that it
> is, it's used as a hierarchical match on the domain side of an e-mail
> address, as found in the user ID (which itself is not typically
> treated as a true RFC 2822 name-addr, despite the text in the spec,
> see id:[e-mail] and related discussion).

(Hint for future references: that's the “User ID conventions (it's not
really a RFC2822 name-addr)” thread.)

Yes. I am aware of that packet not exactly being a formal name-addr.
The mention "User ID could contain something else" was trying to convey
that there could be completely unstructured User ID packets but in
order for this to be useful you would need to be dealing with "common"
ones.

Looking again at that thread, I would recommend including some plain
text examples (non-normative, perhaps) on how User ID would be expected
to look like at your MR
https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_r
equests/23/diffs?commit_id=a300afb3aebd1f5645dd3fbdcf14a420c5bc2090
(does gitlab support creating a merge request of a merge request?)

Realistically, there are some things that can only be achieved with
"structured User ID", and rfc4480bis should probably have some more
focus on that.
Particularly, if there is an uid has an email address associated, it is
crucial that all clients find the same one.


> Seems like the right way to address the most common (though still
> uncommon) use case is to make a new explicit subpacket that is just
> about handling a DNS suffix; to clearly define the interaction
> between multiple subpackets; and to deprecate the regex for that
> particular use case. (maybe deprecate the regex subpacket in general,
> as i've not seen any other legit use, and there are clearly gaps in
> the spec for it)

I would probably consider that subpacket over en email address,
although it would be very rare for one of them not to begin with "*@"


> That work is not really in-scope given our current charter, but if
> someone wants to write something like that down in a more formal way,
> i can imagine it being something for the WG to take on after we
> finish the cryptographic refresh and consider re-chartering.
> 
>               --dkg

Are you thinking on a separate RFC or as an amendment that could be
combined later into the same document?

Best regards