Web Key Directory
Werner Koch
wk at gnupg.org
Fri May 6 16:13:37 CEST 2016
On Fri, 6 May 2016 15:29, dgouttegattat at incenp.org said:
> Is this list (gnupg-devel) appropriate for discussing this draft, or
> should discussions take place elsewhere (e.g., on a IETF list)?
I don't known. I posted it only to here.
> There seems to be a contradiction between this paragraph (at the
> beginning of Section 4):
You are right; there is a problem. But also in the section above where
the return type for a key lookup is specified:
The server SHOULD return "application/pgp-keys" as the content-type
for the data but clients MUST also accept "application/octet-string"
as content-type. The server MUST NOT return an ASCII armored version
of the key.
Given that this is designed as an alternative to DANE, there should be
no ASCII armor. However, RFC-3156 requires the use of an ASCII armor
for application/pgp-keys. I think it is better to remove the need for
application/pgp-keys and go with "application/octet-string"
Back to section 4:
> She sends her key using SMTP [...]. The content-type SHOULD be
> "application/pgp-key" and the key being a binary attachement
> (which is then likely base64 encoded). Note that the OpenPGP
> ASCII armor is not used.
That is easy to fix:
She sends her key using SMTP (or any other transport mechanism) to
the provider using the submission address and the key format
specified by PGP/MIME.
> I also presume the "application/pgp-key" (singular) in the first
Yep. See
<http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg-doc.git;a=blob;f=misc/id/openpgp-webkey-service/middle.mkd>
for the latest version.
Thanks.
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
More information about the Gnupg-devel
mailing list