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

Eric Rescorla <ekr@networkresonance.com> Wed, 17 May 2006 16:31 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgOw5-0006TO-2w; Wed, 17 May 2006 12:31:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgOw3-0006TJ-Q4 for tls@lists.ietf.org; Wed, 17 May 2006 12:31:43 -0400
Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgOw2-0001TX-Fh for tls@lists.ietf.org; Wed, 17 May 2006 12:31:43 -0400
Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 9811E22245C; Wed, 17 May 2006 09:38:05 -0700 (PDT)
To: Simon Josefsson <jas@extundo.com>
In-reply-to: Your message of "Wed, 17 May 2006 18:28:57 +0200." <87y7x0ipiu.fsf@latte.josefsson.org>
X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 19)
Date: Wed, 17 May 2006 09:31:41 -0700
From: Eric Rescorla <ekr@networkresonance.com>
Message-Id: <20060517163805.9811E22245C@laser.networkresonance.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Cc: tls@lists.ietf.org
Subject: [TLS] Re: Review of draft-ietf-tls-openpgp-keys-08
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

Simon Josefsson <jas@extundo.com> wrote:
> Eric Rescorla <ekr@networkresonance.com> writes:
> > It's not undocumented. It's "add these certs to your bucket of certs"
> > and use them in whatever resolution mechanism you have.
> 
> How are clients and servers, respectively, supposed to figure out
> which keys to include?
> 
> Presumably, they should not send their entire key ring, right?  Some
> properties of the resolution algorithms appear to be needed to pick
> the "appropriate" keys, and limit the set of keys to send.
> 
> Compare RFC 4346, which says on X.509 certs:
> 
>    certificate_list
>       This is a sequence (chain) of X.509v3 certificates.  The sender's
>       certificate must come first in the list.  Each following
>       certificate must directly certify the one preceding it.  Because
>       certificate validation requires that root keys be distributed
>       independently, the self-signed certificate that specifies the root
>       certificate authority may optionally be omitted from the chain,
>       under the assumption that the remote end must already possess it
>       in order to validate it in any case.
> 
> What I'm looking for are similar guidelines to decide which OpenPGP
> keys to include, but I'm skeptical about the existence of useful such
> guidelines.

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?

-Ekr


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