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

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.

> As Nikos said, if someone wants this, it is easy to extend the
> PGPKeyDescriptorType enum to add a key_list(2), and then describe the
> semantics related to it.  If someone volunteers to write that, we
> could review that text to see if it seems correct, but, IMHO, the onus
> to write this should be on those who proposed this change in the
> document.

I don't agree that this should be an extension, but I am willing
to go along with the burden of work argument. Pasi, you want to
contribute text?

-Ekr

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