Werner, I just saw version -07 today. The advanced method:
WELLKNOWN := https://openpgpkey.example.org/.well-known/example.org/openpgpkey doesn't seem to make much sense to me. I tried it with posteo.de, and got: ale@pcale:~/tmp$ dig +short openpgp.posteo.de 89.146.220.134 ale@pcale:~/tmp$ curl --head https://openpgp.posteo.de/.well-known/posteo.de/openpgpkey/submission-address curl: (51) SSL: no alternative certificate subject name matches target host name 'openpgp.posteo.de' The subdomain is probably a star (*) DNS record. However, their certificate's Subject Alt Name doesn't have a star, but a list of subdomains. Certificates cost, albeit not much, so the need to set up a new subdomain may hamper implementation. I'm unable to get the "flexibility in setting up the Web Key Directory in environments where more than one mail domain is hosted". Say I host A.example and B.example. Then I need to set up both subdomains openpgpkey.A.example and openpgpkey.B.example. Internally, they can be redirected in a number of ways, but the server should hold the HTTP_HOST anyway. To repeat tha mail domain between .well-known and openpgpkey doesn't seem to help much. The openpgpkey folder can be implemented by plain files named after the 32 byte string and containing the key to be served. The l= parameter would just be discarded in that case. Otherwise, if the server side script is cute, should it verify whether the value of the parameter interpreted as a local part matches the 32 byte string? What if they don't match? To urlencode the local part might have been easier than Z-encoding its SHA1, but what's the point of doing both? Best Ale _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
