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

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.

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.

Regards,
Simon

[1] I'm guessing here.  If what PGP does is documented and part of
some standard, the situation would be different.

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