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