Subject: Re: [openpgp] The DANE draft

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 05 Aug 2015 00:01:45 -0400

On Sat 2015-07-25 08:56:09 -0400, Paul Wouters wrote:
> [ dkg wrote: ]
>> I looked at it with Petr Spacek after the meeting, and i plan on
>> providing Paul with a more detailed review shortly.
>
> Greatly appreciated!

heh, fsvo "shortly" :/

i'm not subscribed to [email-masked], feel free to forward if you think
this would be useful.

key discovery vs key validation
-------------------------------

As an optional key discovery mechanism for OpenPGP, i think this
proposal has merit.  I share Watson's concerns about "smuggling in a
different trust model", but i have no complaints about DNSSEC validation
being used as a corroborative validation mechanism, should clients
choose to accept it for validation purposes.  For clients that *don't*
choose to accept it for validation purposes, they should validate the
keys via their usual mechanisms, and rely on OPENPGPKEY records solely
for discovery purposes.

metadata leakage
----------------

I'm a little concerned about the potential for metadata leakage -- i
don't want my MUAs to do DNS lookups every time i try to send mail to
someone whose keys i dont have.  Until DPRIVE is a reality (and maybe
even after that) the DNS leaks much more information than my typical MUA
-> MSA connection.  (i like the metadata channel minimization offered by
draft-moore-smtp-addrquery for that reason).

localpart mangling
------------------

I have no strong preference for base32 vs. digested localpart for the
hostname.  Digested localparts require a little bit more work to invert
than base32, but given the low entropy of typical normalized localparts,
they don't provide a lot of protection against a determined attacker.

I'm slightly more concerned with e-mail address length limits on base32
than on digested localparts -- a long localpart plus a long domain name
could make for a very large DNS label, whereas a fixed digest should
give us a fixed bound on size.

In either case, some canonicalization will be required (before base32 or
digest, whichever is chosen).  fwiw, i believe that case normalization
of the localpart is pragmatic for today's networks, despite not being
within the letter of the RFC.  I would advise clients to downcase before
doing a lookup.

The main advantage for base32 over digested localpart seems to be for
synthesized OPENPGPKEY records in an online-signing DNSSEC-capable
server.  I don't believe this is a significant advantage for a key
discovery mechanism for OpenPGP, because i believe some people will want
to verify the OpenPGP certificate itself, regardless of its DNSSEC
status, and the OpenPGP certificate won't have wildcards in it.

RDATA content/structure
-----------------------

The -03 spec §2.1 currently suggests that the RDATA should be an
"RFC4880 OpenPGP public keyring", but RFC 4880 doesn't define a "public
keyring" in any reusable way (see
https://tools.ietf.org/html/rfc4880#section-3.6).

§ 2.2 says:

   The RDATA Wire Format consists of a single OpenPGP public key as
   defined in Section 5.5.1.1 of [RFC4880].  Note that this format is
   without ASCII armor or base64 encoding.

But 5.5.1.1 is *just* a public key packet.  This is not a useful record
to store.

Instead what you want is probably exactly one "Transferable Public Key"
(https://tools.ietf.org/html/rfc4880#section-11.1), which is the
standard for the composable OpenPGP certificate format.  But see the
"Filtered Certificates" section below for more detail.

Key Transitions
---------------

While i say "exactly one" Transferable Public Key, i'm assuming that the
DNS is OK with serving multiple OPENPGPKEY records at a single label.

This would be necessary for people to be able to handle a key
transition.  Some examples are:

 0) Alice makes a new stronger primary key that she wants people to know
    about, while she continues to use her older, better-known key for
    several months.

 1) Bob makes a new primary key using a new key algorithm (e.g. ECC)
    that he knows won't be universally supported.  He publishes it
    alongside his more traditional (e.g. RSA) key.

 2) Carol's longstanding key has been compromised.  She revokes it,
    makes a new key, and wants to publish both the revoked certificate
    as well as her new cert.

I think all of these cases can be served by multiple OPENPGPKEY records.

Filtered Certificates
---------------------

Given that some users have aggregated OpenPGP certificates that are
quite large (my own is currently ~475KB), we don't want to require
people to publish their entire certificate in the DNS.  Because OpenPGP
certificates ("transferable public keys) are composable (they consist of
a series of packets, many of which can be dropped), a reasonable policy
for filtering the certificate for size purposes should be suggested.

At a minimum, the OPENPGPKEY record for [email-masked] MUST contain:

 * primary key X
  - one User ID Y, SHOULD match [email-masked]'
   - self-signature from X, binding X to Y.

[ note: I do not believe we need to require that the User ID MUST match
  the looked-up record, though it's obviously preferable to a validator
  if it does. ]

This extremely minimal record might not provide an encryption-capable
subkey, though, and the primary key may not be encryption-capable
itself.

So a more sensible transferable public key would also include all
relevant subkeys:

 * primary key X
  - one User ID Y, SHOULD match [email-masked]'
   - self-signature from X, binding Y to X.
  - encryption-capable subkey Z
   - self-signature from X, binding Z to X.
  - [ other subkeys if relevant ...]

Owners of the record may also want to include some up-to-date
third-party certifications which they think would be helpful for
validation, which would result in:

 * primary key X
  - one User ID Y, SHOULD match [email-masked]'
   - self-signature from X, binding Y to X.
   - third-party certification from V, binding Y to X
   -  [ other third-party certifications if relevant ...]
  - encryption-capable subkey Z
   - self-signature from X, binding Z to X.
  - [ other subkeys if relevant ...]

So when preparing these records for a specific OPENPGPKEYDATA with the
goal of minimizing certificate size, a normal user would normally want
to:

 0) where one User ID from their cert matches the looked-up address,
    strip away non-matching User IDs and any certifications (self-sigs
    or third-party certs) associated with them

 1) strip away all User Attribute packets and associated certifications

 2) strip away all expired subkeys (may want to keep revoked subkeys if
    they were revoked prior to their preferred expiration to ensure that
    correspondents know they are properly revoked)

 3) strip away all but the most recent self-sig for the remaining user
    IDs and subkeys

 4) (optionally) strip away any uninteresting/unimportant third-party
    User ID certifications.  This is a value judgement that will be made
    imperfectly, since the person creating the record doesn't know the
    trust model of the recipient.  At the very least, the RDATA owner
    should strip all third-party ceritifcations which have been
    superceded by other certifications from the same third-party, as
    well as any expired third-party certs.  Other useful filtering rules
    might include the date of the third-party cert (recent certs are
    better), strength of the third-party cert (stronger keys are
    better), the size of the third-party cert (smaller certs are
    better), "connectedness" of the third-party making the cert
    (e.g. based on some measurement of presence in the WoT strong set),
    or some domain-specific policy (e.g. always include third-party
    certs from the organization's internal CA key)

With GnuPG, you can achieve a rough minimization with:

  gpg --export-options export-minimal,no-export-attributes $PGPFPR > opengpgpkey.pgp

(this still exports expired subkeys and alternate User IDs, so further
filtering could be done to make the record even smaller)

Applying the most extreme of these minimization rules (with no
third-party certifications whatever) my own OpenPGP certificate (with a
single large primary key, a relatively long User ID, and three large
subkeys) is < 4KiB.

For even the largest ECC keys (nistp521) with a cert with distinct
primary key and subkey, the filtered/minimized cert is well below 1KiB.

does this make sense?  I'm happy to discuss it further.

Regards,

   --dkg

---

From: Paul Wouters <[email-masked]>
Date: Wed, 5 Aug 2015 04:14:42 -0400 (EDT)

> i'm not subscribed to [email-masked], feel free to forward if you think

[ I added dane back to the CC: as I think it will be useful to keep the
   openpgp discussion there too, as some people there also wanted a
   different specification of the RDATA ]

> key discovery vs key validation

The text does make it clear that you have that choice:

    The proposed new DNS Resource Record type is secured using DNSSEC.
    This trust model is not meant to replace the Trust Signature model.
    However, it can be used to encrypt a message that would otherwise
    have to be sent out unencrypted, where it could be monitored by a
    third party in transit or located in plaintext on a storage or email
    server.  This method can also be used to obtain the OpenPGP public
    key which can then be used for manual verification.

So there is no "smuggling".... DNSSEC is used to protect the transport,
and as a poor man's better-than-nothing web-of-trust alternative.

> someone whose keys i dont have.

The MUA can present you with information to manually verify or put a trust
level to the key. The MUA should also cache negative attempts to get a
key and limit these so avoid fingerprinting email send times by looking
at DNS queries. That part is not in the current RRtype specification,
but should go into the openpgpkey-usage document (co-authors wanted!)

> localpart mangling

And as clearly stated, were never meant to provide security.

> give us a fixed bound on size.

Do you forsee email addresses > 256/2 to be common use?

> within the letter of the RFC.  I would advise clients to downcase before

Thanks. I share that belief.

> status, and the OpenPGP certificate won't have wildcards in it.

Other people believe there is some use. If the only downside is not
supporting insanely long email addresses, which I think are a more
rare event, I think that it is okay.

> RDATA content/structure

I will update the reference to refer to that section. Thanks. That
does look better.

> Key Transitions

What is the advantage of multiple DNS records with 1 key over one DNS
record with multiple keys? While I'm all four specifying one method to
increase chances of interop, I'm not particularly set on one or the
other solution.

> Filtered Certificates

We mention this in Section 5:

https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-03#section-5

>  - [ other subkeys if relevant ...]

[...]

>  gpg --export-options export-minimal,no-export-attributes $PGPFPR > opengpgpkey.pgp

The idea was not to specify these policies in the DNS RRtype. Just tell
people to keep to small keys. It did include an example gpg command
in appendix A, but your command seems even better so I will update it.

I would prefer not to mention specific key elements as those might
change and are not really relevent for the DNS specification. Or perhaps
these recommendations could go in the openpgpkey-usage document.

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 05 Aug 2015 12:28:26 +0100

> And as clearly stated, were never meant to provide security.

Hmm.

With no hats, I gotta say I prefer the harder to invert local part
(i.e. hashed) to the reversible one (b32).

If this experiment ends up successful, then I think we'll be setting
a precedent for other per-user identifiers to be used as part of a
DNS name so I do not believe that arguments about this aspect ought
be decided solely based on PGP or SMIME or DANE. We should also
consider that some other protocol is highly likely to follow what
seems to have worked (just as _blah.example.com has been mimicked)
and where we don't now know the privacy consequences of copying
the pattern we're setting here.

For that reason, I really would prefer that we stick to the hash and
not go for the reversible per-user identifier.

(Separately, I also don't buy that there will be much use for actually
reversing the b32 encoding and if there were then the relevant work
could just as easily be done in advance by a server that is willing
to answer for a few known alternatives.)

So sorry to continue an argument but shouldn't this experiment be
a more conservative about privacy just in case it ends up wildly
successful?

Ta,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 05 Aug 2015 16:25:08 +0100

On 05/08/15 16:12, Paul Hoffman wrote:
> Wearing my author hat: I don't care between b32 and hashing. Both are
> equally easy to document. However:
> 
> On 5 Aug 2015, at 4:28, Stephen Farrell wrote:
> 
> How is using the hash more conservative about privacy, except in zones
> that are signed with NSEC instead of the more common NSEC3? If you
> assume zones signed with NSEC3, both options are equally susceptible to
> dictionary-based guessing attacks, given that the effort to create
> search dictionaries for the billion of common LHS names is pretty low
> even for hashes.

Tempora. That on-path attacker has a far easier time reversing the
b32 than anything based on the hash. Even with DPRIVE, we don't know
how to handle the recursive to authoritative part.

So a "putative other protocol that copies this" could well do a great
job on hiding identifiers only to be caught out by following this b32
convention.

I do accept that hashing doesn't make much difference for PGP or SMIME
since the DNS answer in the success case almost certainly gives the
game away, but I don't think that has to be true in general.

The failure case may also be of interest though, with hashing, that DNS
answer doesn't immediately tell the attacker to whom I'd like to send
email. And I guess if some MUA adopts this there'll be quite a few
negative answers for quite some time, so there's a privacy difference
there I think. (Not sure if that was raised before - apologies if so.)

S.

> --Paul Hoffman

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 05 Aug 2015 08:12:06 -0700

--Paul Hoffman

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 05 Aug 2015 08:55:58 -0700

> how to handle the recursive to authoritative part.

Thanks, I was only thinking of off-path attackers.

I agree that, if we are concerned with on-path watchers, hashes would 
preserve much more privacy than Base32 encodings.

--Paul Hoffman

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 05 Aug 2015 15:06:28 -0400

> and as a poor man's better-than-nothing web-of-trust alternative.

ah, right.  Please don't use the term "Trust Signature model" here.
While RFC 4880 does specify "trust signatures", they're not commonly
used, and they don't represent the most common implementations of how
people interact with OpenPGP's network of identity assertions (aka "web
of trust") -- we don't want to conflate "Trust Signature" with "web of
trust".

> The MUA can present you with information to manually verify or put a
> trust level to the key.

i think you are referring to the validity of a key for a given e-mail
address here.  in OpenPGP-land, "trust" usually means something
different (e.g., how much you're willing to rely on identity assertions
made by the key itself, analogous to "is this X.509 cert a trust
anchor?")

> The MUA should also cache negative attempts to get a key and limit
> these so avoid fingerprinting email send times by looking at DNS
> queries. That part is not in the current RRtype specification, but
> should go into the openpgpkey-usage document (co-authors wanted!)

Sounds far more reasonable than query-on-every-message, though i'm not
just worried about fingerprinting e-mail send times -- i'm also worried
about tracking user associations directly by lookup.

> And as clearly stated, were never meant to provide security.

Digested local parts provide a little more privacy, not security.  But i
agree it's only a little bit, given the low entropy of most localparts.

Is it conceivable that someone wants to use a high-entropy localpart to
avoid address leakage via key lookup? In that case, it seems like you'd
do just as well to have your high-entropy localpart uniquely identify
your key in the first place, with something like
[email-masked].

> Do you forsee email addresses > 256/2 to be common use?

you've dropped the units here -- 256/2 what?  are we talking about
characters or octets?  if octets, under what encoding?  I agree that
e-mail addresses are rarely this long today, but we should be cautious
and explicit about any additional constraints when we're proposing to
mapp a limit from one domain (DNS) onto another domain (e-mail
localparts).

> rare event, I think that it is okay.

Steven's point about raising the cost slightly for passive attackers
(e.g. TEMPORA) seems at least as relevant to me as the feasibility of
online-signed zones serving up end-user OpenPGP certificates that can't
possibly match the requested address exactly.

That said, there's a separate scenario, where as a domain administrator
i want to mint and sign an OpenPGP certificate on each query (even ones
where i have no user), to avoid the possibility of someone enumerating
all my actual users by walking the localpart space.  minting a matching
certificate would be creatable with the base32 approach

(how would this work?  something like the following: the DNS server
responsible for these records would keep a domain-wide long-term secret.
upon a query that it finds it has no legitimate record for, it would
hash the query name and the long-term secret into a seed for a PRNG.
from the PRNG output, it would deterministically derive secret key
material and any other variable metadata (like creation date) needed to
derive a new certificate.  it could cache or discard these certificates
as requested, because it could always re-generate them exactly from a
new query.  when a user opens a matching account, the user's personal
key would replace the domain-generated one.  i'm not saying this is a
great system, just outlining how it might be done for a system that
wants to keep its userbase hidden)

I'm still on the fence here, as you can tell :P

> increase chances of interop, I'm not particularly set on one or the

Hm, the more i think about it i find i prefer it aesthetically, but i'm
not sure i have a good engineering argument.  I don't see a great way to
effectively prevent people from doing either one -- are there any DNS
record types explicitly prohibit multiple records in response to a given
query?

OpenPGP composable certificates are just a series of OpenPGP packets
concatenated; two certs concatenated together are themselves also just a
series of OpenPGP packets by induction.  We could say that the RDATA
"MUST start with a Public Key Packet and MUST NOT contain more than one
Public Key Packet".

> https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-03#section-5

looks sensible, though i think some of the terminology is slightly off
there.  i could try to provide patches for that section if you like.
how is the draft developed -- how do you prefer edits sent to you?

> these recommendations could go in the openpgpkey-usage document.

That seems OK to me as well.

     --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 05 Aug 2015 15:32:14 -0400

> there I think. (Not sure if that was raised before - apologies if so.)

yep, i raised that concern too, thanks for reinforcing it :)

the cost of inverting a digest is definitely more than the cost of
inverting b32, but it's unlikely to be difficult for an interested
attacker to invert otherwise low-entropy domain names or localparts of
e-mail addresses.

see djb's writeup on nsec3walker for a related example of how low the
bar is for doing large-scale hashing with the kind of low-entropy input
spaces found in DNS:

 http://dnscurve.org/nsec3walker.html

It's not exactly the same problem, but a good example of how small the
protection is against a motivated adversary in this context.

           --dkg

---

From: Paul Wouters <[email-masked]>
Date: Thu, 6 Aug 2015 04:23:54 -0400 (EDT)

On Wed, 5 Aug 2015, Carsten Strotmann wrote:

> for OPENPGPKEY/SMIMECERT zones, operators could (maybe SHOULD) use
> NSEC/NSEC3 "narrow" signing to prevent "zone-walking".

email addresses are not secret. That is not the privacy you can protect
at all. Anyone can either do a internet search or just attempt to
deliver an email to figure out if the email address is valid.

The only realy privacy concern is learning who is querying, meaning who
is interested in mailing a particular user - assuming everything else on
the email path is secureb by TLS, and the domain is large enough to
actually hide the userbase (that is, nohats.ca is already a lost cause,
because everyone knows a TLS connection to mx.nohats.ca means you are
going to email me)

> Breaking hashes requires much more "willful intent" than decoding BASE32.

But that difference these days is basically zero as soon as someone puts
up a module for johntheripper or hashcat or something on github.

> The hashing communicates a "don't go here" message, even though it is
> technically not a strong protection.

If the sysadmin does not respect privacy on base32, they will not
respect privacy on hash(very simple names) or even hash(former-lover)

> It is like having a closed door vs. no door at all. No door communicates
> "come in, no secrets, we're open" while the closed door (even if it can
> be opened by minor force) communicates "private space".

I might agree but I think the gain for this is so incredibly small, that
I think the gain for use of online signers plus email address
corrections by the smtp+dnssec combined server is actually a more likely
and minorly useful thing to have.

And don't get me wrong. I'd rather see zonefiles with a hash than with
base32 cut from an esthetical point of view.

Paul

---

From: Hosnieh Rafiee <[email-masked]>
Date: Thu, 6 Aug 2015 08:49:53 +0000

> -----Original Message-----
> From: dane [mailto:[email-masked]] On Behalf Of Paul Wouters
> 

Disagree! This really depends on the person and scenarios. 
For some people maybe it is not a problem to share their email addresses or put them on their public websites because it is a part of their job. For example a company shares its email to others so that other can contact them. But for someone like a president of a country or a politician  it is important because a criminal can bug them by threatening them, try to hack their email by sending messages with fake links to do phishing attack or send codes inside html body of the email to access their computer and infect it. Therefore, from privacy point of view, as much information as I can have about a victim, the chance of attack is higher. 

> is interested in mailing a particular user - assuming everything else
> on the email path is secureb by TLS, and the domain is large enough to

Nope, some people who really care about their privacy uses different emails for different purposes (business, family, friends).

> But that difference these days is basically zero as soon as someone
> puts up a module for johntheripper or hashcat or something on github.

Again disagree. 

Hosnieh

---

From: Paul Wouters <[email-masked]>
Date: Thu, 6 Aug 2015 04:54:24 -0400 (EDT)

On Thu, 6 Aug 2015, Jiankang Yao wrote:

> if there is a "email zone walking", the email spammer can use this feature to get the valid addrees easily and send trash emails.
> If we hope to prevent the spammer from getting the email address easily, the email address should be regarded as secret.

So if you use NSEC3 and base32, they need to break the NSEC3 hashing,
which has various parameters to make it easier or harder, but all are
basically in the range of a few days of GPU cracking.

If you use NSEC3 and sha256(LHS) then the work increase is basically
making a table for every 8 letter combination and dictionary names which
should be far less computations than the NSEC3 breaking. And to defend
your email address against this, you have to make it so it is not easilly
guessable with known names and that makes it harder to convey your email
address verbally to other people - the exact opposite of what you want.

Also, the only current alternative for people is to push their email
address plaintext to a keyserver. So even with base32, we are
increasing the privacy of email addresses of openpgp users.

I really do believe that the hashing is not an affective security
meassure.

Paul

---

From: Hosnieh Rafiee <[email-masked]>
Date: Thu, 6 Aug 2015 08:56:01 +0000

From: dane [mailto:[email-masked]] On Behalf Of Jiankang Yao
 
>If we hope to prevent the spammer from getting the email address easily, the email address should be regarded as secret.

This is, IMO, a nightmare when using IPv6....  spammers sending email with new IP and sometimes they know how to bypass the content filtering antispamming ...

Hosnieh

---

From: Hosnieh Rafiee <[email-masked]>
Date: Thu, 6 Aug 2015 09:04:23 +0000

Paul,

> I really do believe that the hashing is not an affective security

By using hash, we make it harder for an attacker to find email addresses of another person. Of course, we cannot prevent the attack. 

Let me give you a real example from a real person that I name him Bob. Bob hasn't published any email address on his personal website but he used a form so that others can send me email only via form.
The spammer also tried to send hiim message via this form in a hope that they can receive an answer so that they can have his email address. But Bob also used other approaches such as captcha. 

After that, he no longer received any spamming email because it was too efforts for spammer to check the captcha and take more of their time. 

I hope it is clear,
Hosnieh

---

From: Vincent Breitmoser <[email-masked]>
Date: Thu, 06 Aug 2015 11:30:12 +0200

On 6 Aug 2015, Paul Wouters wrote:

> I might agree but I think the gain for this is so incredibly small,

The same could be said about NSEC vs NSEC3 for a motivated attacker, and
still NSEC received strong opposition.

 - V

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 06 Aug 2015 10:58:18 +0100

Paul,

> deliver an email to figure out if the email address is valid.

That doesn't address my issue with this as a precedent. Nor the
case of negative DNS responses trivially leaking that someone at
my IP address wants to send a mail to <here> at this time. (And
yes, the trivially is a required part of the argument.)

And "are not secret" isn't, I think, the right comparison. For me,
the question is "if we want to experiment with user identifiers in
DNS names, can we do it in the least privacy unfriendly, but yet
practical, way as possible?"

Yes, some people may oversell the benefits of hashing or may believe
hashing is stronger than it is. Such mistaken beliefs however do not
make hashing worse than b32. Hashing is still a bit better.

> and minorly useful thing to have.

Can you point me at a DNS server (or real specification for one)
that generates responses in any similar fashion? I'm not aware of
any that actually do, (even if they could do), but that my just be
my ignorance.

IMO even if there is a niche of DNS authoritative servers that
can operate in that manner, requiring that that niche be used
for the experiment makes it highly likely the experiment will
fail.

So my logic would be: if b32 is needed, the experiment will
likely fail as you can't do it on many servers. If b32 is not
needed, then let's just hash since that is less bad.

> base32 cut from an esthetical point of view.

Well, let's do that then:-)

S.

> 
> Paul
> 
> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp
>

---

From: Paul Wouters <[email-masked]>
Date: Thu, 6 Aug 2015 06:43:31 -0400 (EDT)

> still NSEC received strong opposition.

Actually, most users of NSEC3 care more about the OPT-OUT feature than
the hashing feature. And there is no OPT-OUT with NSEC.

Paul

---

From: "Jiankang Yao" <[email-masked]>
Date: Thu, 6 Aug 2015 16:39:20 +0800

From: Paul Wouters
Date: 2015-08-06 16:23
To: dane WG list
CC: IETF OpenPGP
Subject: Re: [dane] [openpgp] The DANE draft

Jiankang Yao

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 06 Aug 2015 16:19:12 -0400

On Thu 2015-08-06 05:04:23 -0400, Hosnieh Rafiee wrote:

> Let me give you a real example from a real person that I name him
> Bob. Bob hasn't published any email address on his personal website
> but he used a form so that others can send me email only via form.
> The spammer also tried to send hiim message via this form in a hope
> that they can receive an answer so that they can have his email
> address. But Bob also used other approaches such as captcha.
>
> After that, he no longer received any spamming email because it was
> too efforts for spammer to check the captcha and take more of their
> time.

He will also receive no mail from me, because i prefer to mail from my
own mail user agent, and not from webforms with a captcha, which have
their own set of privacy concerns in common implementations, not to
mention UI/UX issues. :P

Plus, how does Bob reply to any of his mail?  Does his reply use an
e-mail address?  What stops one recipient from publishing his e-mail
address?

But this all seems like quite a digression: how is this an argument
about which form to use for publication of the OPENPGPKEY record?

        --dkg