On May 18, 2018, at 1:26 PM, Leo Gaspard
<ietf=40leo(_dot_)gaspard(_dot_)ninja(_at_)dmarc(_dot_)ietf(_dot_)org> wrote:
Hello,
I have subscribed to this list only recently (late 2016), so please
forgive me if this has already been discussed, as I couldn't find it in
the ML archives. I also hope I didn't miss something fundamental while
writing down this idea.
No problem. Since I wrote that text, I can provide some color. I think gentle
persons can also disagree, so I'm not saying what I think is law, merely that I
wrote it, and therefore I think I can give some indication of what the group
consensus meant. Group consensus is often vague, wishy-washy, etc.
As I understand it, currently, with OpenPGP, it is possible to simulate
the Certificate Authority model:
* The clients wishing to use it assign full trust to the root CAs
* Root CAs use 255-trust trust signatures for subordinate CAs
* Subordinate CAs sign the verified OpenPGP keys
That's pretty much the intent. The idea is that you should be able to mark a
key as being something like a CA.
Two important things to remember about OpenPGP philosophy are: (1) OpenPGP
democratizes being a CA. All keys can sign, endorse, etc. and (2) Trust is also
democratized in that trust is in the eye of the beholder. Also note that in
many cases the beholder might be an organization. That organization might push
its policy to its members, and be polite enough to scope that trust only to
keys operating in that environment.
I think it would be great to also be able to simulate the DNSSEC model,
so that as a client I would be able to say “I trust [this key] to make
statements about [this set of keys].” I see it as, is in a way, a
logical follow-up of Web Key Directory.
I suppose.
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
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>").
Well, I think I disagree. I think that if I am trusting ca-a.com with scope at
the root, subordinates cannot widen that scope. Scope is supposed to be
narrowed only through subordinates. If that weren't true, then your subordinate
that issues trust for example.org could just as easily issue it for ".*" and
now all of a sudden the subordinate gets to sign everything, and that's the
opposite of what scoping even means.
Another issue of this scheme, obviously, is that noone “in the wild”
currently uses regular expression subpackets (that I know of). However,
I hope this could change, were this change to allow creation of scoped
CAs, that would interact nicely with WKD.
Yup, it's a little-used feature. So little used that I don't know of anyone
using it, either.
For instance, a mail provider could set up such a “CA”, that would
automatically sign all keys that would pass the WKD test, and for which
the UID would be confirmed as valid by the internal database. Then,
users could start trusting such mail-provider-provided CAs, for
additional validation of the user ID (in addition to the localpart
already “validated” by HTTPS), while still restricting them for only
being valid for the domain(s) they own. For easy discovery,
mail-provider-provided CAs could have a path at
.well-known/openpgpkey/mail-provider-key, and the user could decide to
add some trust to this CA.
I believe that is pretty much the intended use case. The idea is that if I'm a
member of an club (or company, etc.), then that club can bring in new members
and I don't have to go to the trouble of trusting their keys, it happens for me.
In the naive trust model, I can say, "Whatever Alice signs is okay with me."
This is obviously giving Alice a lot of power.
The trust-extension feature says, "Alice can deputize others to sign for her"
and also permits those deputies to have deputies to some specified depth. This
is obviously extending Alice's power in huge ways. Even with a level of only
one, the only limit on Alice's power is that she has to deputize new deputies,
but she has unbounded power to deputize.
The scoping feature is there so you can say, "Whatever Alice signs about our
club is okay with me." It limits Alice's power. This is a reasonable and
arguably important thing, especially if you're going to let Alice deputize
people who can deputize people. It's so that the second assistant to the deputy
undersecretary of the membership committee can't just go sign anything and I'll
believe it.
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.
If that's not what I described, then do me a favor and describe the problem you
want solved.
Jon
Cheers,
Leo
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp