Re: [TLS] Review of draft-ietf-tls-openpgp-keys-08

Nikos Mavrogiannopoulos <> Tue, 16 May 2006 17:33 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1Fg3Q2-0000tL-IW; Tue, 16 May 2006 13:33:14 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1Fg3Q1-0000tG-Dt for; Tue, 16 May 2006 13:33:13 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1Fg3Q0-00032l-49 for; Tue, 16 May 2006 13:33:13 -0400
Received: by with SMTP id k3so28312ugf for <>; Tue, 16 May 2006 10:33:11 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta;; h=received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=k9pIiVdi5pW2JWt4Y0sS7XOaePGb3QuK9cyKcMPB5ABnOkcDx6v9D3Lfki1h5IPRCtxsKz0Khk69pWUnu5rTFDpln1mNznGAEjiNoPdASi2N2JElZpod9WnkCxMUryz0l8QfSBvV2/+EE4g6LBVWR5npJEDJCsADjqRc1pj0Brc=
Received: by with SMTP id p4mr3492894ugl; Tue, 16 May 2006 10:33:11 -0700 (PDT)
Received: from ? ( []) by with ESMTP id m1sm1303544uge.2006.; Tue, 16 May 2006 10:33:10 -0700 (PDT)
From: Nikos Mavrogiannopoulos <>
Subject: Re: [TLS] Review of draft-ietf-tls-openpgp-keys-08
Date: Tue, 16 May 2006 19:32:41 +0200
User-Agent: KMail/1.9.1
References: <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <>
X-Spam-Score: 1.9 (+)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

On Tue 16 May 2006 13:59, wrote:

> Thus, I would not hard-code this limitation in the specification,
> especially when it's very easy to avoid (just allow a list just
> as in normal TLS), and there's just 3 bytes of overhead for
> implementations that send only one PGP key... (and in fact
> even this overhead could be avoided if we remove the redundant
> length field by stating that the "key descriptor type" is the
> first byte of the key data)

It is not about the byte overhead. It is about defining what a key chain
is how is it going to be used, what is an implementor going to put there 
etc. Otherwise it would be a pandoras box, waiting to be opened. 

Given the feedback I've got all the years this draft exists, it seems 
that nobody so far had a need for it. If in the future this proves to 
be a limitation, it is easy to add an extra key descriptor type with a 
key list, that follows some rules, or none. 

> > That approach follows the way openpgp keys are used in electronic
> > mail and I see no good reason to change it by introducing an
> > openpgp key chain in this draft.
> It does not follow the email way of using PGP: most email messages
> don't contain the public key at all (only the signature), and when

+ the fingerprint of the signer, because that's what is needed for 
authentication. The receipient is responsible for retrieving the
keys based on the fingerprint. 


ps. I hope I didn't get rude or personal in this or previous mails, but 
my point is that since we have no use of this functionality today, I 
see no point in adding it. If needed it might be better to be added 
from people who would use it because they will define it the way the 
really need it.

TLS mailing list