ietf-openpgp
[Top] [All Lists]

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

2021-01-09 16:49:56
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:87woe7zx7o(_dot_)fsf(_at_)fifthhorseman(_dot_)net 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

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