On Sat, Nov 10, 2018 at 11:25:21AM +0100, Werner Koch wrote:
On Sat, 10 Nov 2018 00:18,
bartbutler=40protonmail(_dot_)com(_at_)dmarc(_dot_)ietf(_dot_)org
said:
reasons previously mentioned in this thread and discussed in Brussels
(case sensitivity, +aliases/subaddresses, Unicode, catch-all
addresses). The hash would be ignored.
BTW, the sub-addressing does not seem to be a real problem. A cursory
inspection of some large keyrings showed that user-ids with
sub-addresses are quite rare and there is always the opportunity for the
user (or a tool) to create another user-id w/o the sub-address. Thus
the sub-addresses can be handled in the MUA and won't need protocol
support.
I think that long-term, two parameters that do the same thing and could
conflict is bad and that while compatibility is a good short-term goal, we
should try drop the hash and to migrate to this final form as soon as
possible:
..well-known/openpgpkey/hu/?l=Joe(_dot_)Doe(_at_)example(_dot_)org
I disagree but I don't think it is the time to discuss this now. Let us
first deploy a useful key discovery and then see how it can be
improved/changed.
should simplify this and simply mandate the 'wkd' subdomain, full
stop, rather than having a fallback mechanism to the main domain. The
I concur. Given that we need to drop the SRV records for silly reasons
anyway, we can also demand a fixed subdomain. Given that I don't like
the "wkd" acronym, I would prefer to use a different name, like
"openpgpkey".
I'll note that the IESG is generally not super-keen on reserved leaf names
in the DNS, though it is not something that is entirely disallowed when
there are not usable alternatives.
https://tools.ietf.org/html/draft-moonesamy-dnsop-special-use-label-registry-00
is (IIUC) supposed to be a way forward to at least provide a discoverable
registry of these "reserved" names.
-Ben
And regarding your other mail: Sure, a redirection can only be allowed
to use a http redirect and not with a CNAME.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
_______________________________________________
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