Hi Leo,
On Fri, 18 May 2018 22:26:03 +0200,
Leo Gaspard wrote:
As I understand it, RFC4880 already has a provision for such a model,
with §5.2.3.14 _Regular Expression_.
However, there is from my reading an issue with (the wording of) this
section: it only restricts one-level trust signatures. In other words,
from my reading, if:
* User U trusts(255, r".*<.*@ca-a.com>") "A <root(_at_)ca-a(_dot_)com>"
* root(_at_)ca-a(_dot_)com trusts(255, r".*<.*@example.org>") "B
<b(_at_)ca-a(_dot_)com>"
* b(_at_)ca-a(_dot_)com signs "C <c(_at_)example(_dot_)org>"
Then, from A's point of view:
* root(_at_)ca-a(_dot_)com has trust(255, r".*<.*@ca-a.com>")
* b(_at_)ca-a(_dot_)com has trust(254, r".*<.*@example.org>")
* c(_at_)example(_dot_)org is valid
For reference, here's the relevant text:
5.2.3.14. Regular Expression
Used in conjunction with trust Signature packets (of level > 0) to
limit the scope of trust that is extended. Only signatures by the
target key on User IDs that match the regular expression in the body
of this packet have trust extended by the trust Signature subpacket.
I interpret this differently. I interpret "to limit the scope of the
trust that is extended" to mean that the source extends *its* trust to
the target. That is, trust is not somehow reset when following an
edge in the graph, but either passed on as is or narrowed.
However, I don't think c(_at_)example(_dot_)org should be valid, as user U
only
wanted to give permissions on r".*<.*@ca-a.com>" to root(_at_)ca-a(_dot_)com.
So I
think all regular expressions in the trust chain should have to match in
order to not be rejected -- in a similar fashion as the DNSSEC model.
So the “wrong” line here would be b(_at_)ca-a(_dot_)com's trust, which should
be
calculated as trust(254, r".*<.*@example.org>" AND r".*<.*@ca-a.com>").
Even if the standard is wrong here, this is definitely a more useful
and non-broken approach, and, I suspect, almost certainly what was
intended.
Another issue of this scheme, obviously, is that noone “in the wild”
currently uses regular expression subpackets (that I know of).
Not only does almost no one use regular expressions, but regular
expression support is not very widely supported (GnuPG doesn't support
regular expressions on Windows), and until recently broken in GnuPG
(see https://dev.gnupg.org/T2923).
I would like to make a counter proposal, that Vincent and I came up
with at FOSDEM: I think that we should deprecate Regular Expression
support and replace it with a list of domains (optionally prefixed
with "*." to indicate any subdomain). First, most users don't
understand regular expressions. And, although it would be possible to
allow users to enter one or more domains and then convert them to a
regular expression, it is not easy to reverse this process, which is
essential for explanatory purposes and editing. Second, not including
an RE engine reduces complexity.
:) Neal
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp