On 05/28/2018 02:44 AM, Jon Callas wrote:
The aim of this proposal being to make OpenPGP easier to use by
introducing ways to reduce the work required for setting up a secure
channel, while leaving control over these to the user (or to the
implementer, for opinionated implementations)
Sure! If there's anything OpenPGP needs it's more ease of use and work
reduction.
What do you think about this?
I am not sure what you're really proposing, though. I think you might be
proposing the very thing I described, but I'm not sure.
You're right, now that I understand that the RFC already meant what I
was trying to do, my message didn't make much sense.
If that's not what I described, then do me a favor and describe the problem
you want solved.
The problem I want solved is “no-one is using regular expressions and
thus implementations are likely non-existent or broken”. At first I
assumed it was because of what I thought was an issue of wording in the
RFC that would make it useless (hence my first post), but upon more
thought I think it is due to the following:
The scoping feature is there so you can say, "Whatever Alice signs
about our club is okay with me." It limits Alice's power.
I think the issue here is this “Whatever Alice signs about our club is
okay with me”. It can't really be encoded well in regular expressions: I
can not even say “Alice is only allowed to sign UIDs that end with
@myclub.example.org>”, because that would allow Alice to sign keys with
any name in it, and I would then implicitly trust Alice to have verified
the real-world identity of the key.
So upon more thought, I think the issue I'm feeling is there is better
described by my forked-from-this-thread “[openpgp] Overhauling User IDs
/ Standardizing User Attributes (was: Re: Scoped trust (signatures))”,
as with these changes it would become possible to scope the trust of
Alice to verify email addresses in @myclub.example.org and roles ending
with “at my club”, and even to scope the trust of a government's key to
sign any name whatsoever (as they already can issue any state-provided
ID thus make anyone fall for it at a keysigning party) but not any email
or role.
That said, it is a big change and I'm not sure it could gather enough
momentum to be accepted. But I think (hope?) that with such a
simplification in the way User IDs are handled (ie. without coupling of
unrelated parts of a user's identity), regex filtering (or by-domain
filtering) would become a tool adapted to the problem to solve, that is
delegating limited trust. This way, automated CA-like systems for
OpenPGP could appear without having issues with signing real names,
mailbox providers could sign their user's email addresses without having
to fear the risk that a user's real name is not the one on the User ID, etc.
Does what I'm saying make sense?
Anyway, thank you for this information on the background of this RFC!
Leo
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp