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

Eric Rescorla <ekr@networkresonance.com> writes:

> Simon Josefsson <jas@extundo.com> wrote:
>
>> Eric Rescorla <ekr@networkresonance.com> writes:
>> 
>> > "Steven M. Bellovin" <smb@cs.columbia.edu> writes:
>> >
>> >> On Tue, 16 May 2006 19:07:51 +0200, Nikos Mavrogiannopoulos
>> >> <nmav@gnutls.org> wrote:
>> >>
>> >>> On Tue 16 May 2006 16:50, Eric Rescorla wrote:
>> >>> 
>> >>> > > I'd disagree that it is that simple to fix that: If the draft
>> >>> > > permit more than one key, I believe it has to describe how
>> >>> > > implementations are supposed to use more than one key to build the
>> >>> > > chain, or at least mandate some specific behaviour.
>> >>> > I don't agree with this. PGP at least theoretically knows how
>> >>> > to build cert chains from a "bucket of keys".
>> >>> 
>> >>> Maybe but I still find no point in sending a bucket of keys just like 
>> >>> that. If it is to be sent it has to be clearly defined what it is 
>> >>> expected in this bucket and so on. I'm quite reluctant to do it because 
>> >>> I don't need nor find a use for this functionality. It can be easily 
>> >>> added by anyone that need it[0], and I would be willing to include the 
>> >>> required changes in this or a future update, if somebody needs it and 
>> >>> defines the semantics of a key list.
>> >>> 
>> >> The problem is that you don't know the recipient's trust anchors or trust
>> >> metrics.  Without that, you have to send the whole graph (or at least as
>> >> much of it as you have), to maximize the chances of the key being accepted.
>> >
>> > Right, I understand that this is a problem in principle, but I'm
>> > not sure that it's a problem in practice. In particular, I'm not
>> > sure that it's so bad a problem in practice that the protocol should
>> > be explicitly designed to prohibit people who think they understand
>> > the trust graph from giving hints.
>> 
>> I believe that protocol fields with undocumented semantics, and where
>> the algorithms that make use of those fields are not documented [1],
>> leads to poor interoperability.
>
> 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.

Regards,
Simon

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