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.
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
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.
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>").
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.
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.
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)
What do you think about this?
Cheers,
Leo
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp