Re: photo support?

"Michael Young" <> Mon, 01 July 2002 22:07 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id SAA06588 for <>; Mon, 1 Jul 2002 18:07:22 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by (8.11.6/8.11.3) id g61LuOM17902 for ietf-openpgp-bks; Mon, 1 Jul 2002 14:56:24 -0700 (PDT)
Received: from ( []) by (8.11.6/8.11.3) with ESMTP id g61LuMw17897 for <>; Mon, 1 Jul 2002 14:56:22 -0700 (PDT)
Received: from ( []) by (AIX4.3/UCB 8.7/8.7) with ESMTP id RAA03920 for <>; Mon, 1 Jul 2002 17:44:05 -0400 (EDT)
Received: from mwyoung ( []) by (8.8.0/8.8.0) with SMTP id RAA29085 for <>; Mon, 1 Jul 2002 17:56:09 -0400 (EDT)
Message-ID: <010701c22149$f693b640$>
From: "Michael Young" <>
To: <>
References: <> <>
Subject: Re: photo support?
Date: Mon, 1 Jul 2002 17:55:04 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>
Content-Transfer-Encoding: 7bit

Hash: SHA1

Subject: Re: photo support?

From: "vedaal" <>
> this can lead to an overburdening of servers with 'bloated' keys, with
> whatever someone may decide to want to 'store'.

This is hardly unique to the "photo ID" field.  It would be easy to "store"
arbitary content in:
    a notation subpacket in a valid signature;
    signature MPIs;
    user names; or, even
    public key MPIs.

It is impossible to prevent this sort of abuse without seriously impairing
legitimate use of the public keyservers.

One man's garbage is another man's key.

> it might be worthwhile to consider some maximal size for a recommended
> standard, which can be implemented by the servers
> refusing to accept a key greater than a certain size.

A size recommendation seems reasonable, as an implementation guideline.
A strict limit in the protocol seems most unreasonable.

This kind of restriction alone won't prevent abuse.  It's only the tip
of the iceberg.

Key servers owners can always implement any restrictive policy they
want.  I would urge them not to hack at specific small holes unless
there is an actual problem.  If a bug in a widely used implementation
were to start generating this sort of junk, then I might act.  But
that hasn't been a serious problem yet.

Version: PGP Personal Privacy 6.5.3