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

<Pasi.Eronen@nokia.com> Thu, 18 May 2006 07:31 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgczE-0006sk-S6; Thu, 18 May 2006 03:31:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgczD-0006sf-Pj for tls@lists.ietf.org; Thu, 18 May 2006 03:31:55 -0400
Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgczD-0004P3-0u for tls@lists.ietf.org; Thu, 18 May 2006 03:31:55 -0400
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4I7VbBF014703 for <tls@lists.ietf.org>; Thu, 18 May 2006 10:31:54 +0300
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 10:30:55 +0300
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 10:30:54 +0300
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [TLS] Re: Review of draft-ietf-tls-openpgp-keys-08
Date: Thu, 18 May 2006 10:30:54 +0300
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F2402AACCCE@esebe105.NOE.Nokia.com>
In-Reply-To: <20060517163805.9811E22245C@laser.networkresonance.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Re: Review of draft-ietf-tls-openpgp-keys-08
Thread-Index: AcZ5z3waoJvRqQNES1y65ZwOSWN74gAel48g
From: Pasi.Eronen@nokia.com
To: tls@lists.ietf.org
X-OriginalArrivalTime: 18 May 2006 07:30:54.0837 (UTC) FILETIME=[FF718250:01C67A4C]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
X-BeenThere: tls@lists.ietf.org
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." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

Eric Rescorla wrote:

> Rather than arguing about whether such rules are possible (though 
> I think they are in practice), why don't we see if Pasi wants to
> try to write something?

As far as I know, there is no RFC that really describes how PGP key
validation works (RFC 2440 describes the on-the-wire formats, but not
much more). Thus, even the current version of
draft-ietf-tls-openpgp-keys 
can't do any better than saying "The key validation procedure is a 
local matter outside the scope of this document".

So if we're really worrying about unspecified semantics, that's
certainly one huge missing part...

If the key validation rules would be described somewhere, I think
handling multiple keys/certificates could be as simple as saying "the 
sender MAY include additional keys/certificates it believes to be useful

to the recipient (how this is determined is a matter of local policy and
configuration)" and "the recipient incorporates all the received
keys/certificates (not just the first one) in the key validation
procedure".

Best regards,
Pasi

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls