[Help-gnutls] Re: Semantics of `gnutls_openpgp_key_check_hostname ()'

[Simon Josefsson]

address@hidden (Ludovic Courtès) writes:

> Simon Josefsson <address@hidden> writes:
>
>> Daniel Kahn Gillmor <address@hidden> writes:
>
> [...]
>
>>> I agree that it feels strange!  But i'm really hoping to see OpenPGP
>>> keys used in place of X.509 certs for TLS, so we need to think about
>>> what's the appropriate thing to put there, and how various Certificate
>>> authorities and clients should interpret it.
>
> [...]
>
>> I just realized: Do we have to use the ID packet for this purpose?
>> Can't we define a new OpenPGP packet, similar to the X.509 Subject
>> Alternative Name extension?  I think this is similar to how X.509
>> evolved: first you placed the server name in the CN, then you invented
>> an extension packet to hold it.
>
> In any case, I believe the user ID packet should just be thought of as a
> human-readable hint, no more.  You don't make authorization decisions
> based on what the user ID packet contains, but rather, for instance,
> based on whether that key is in your list of authorized keys for the
> purpose at hand.

Hm.  That's true.

> So I don't clearly understand what specifying new textual packets would
> buy us.  I don't know much about what X.509 does, though.

The difference here is that you can look at a X.509 certificate and
tell whether it is intended for use as a server certificate for a
particular hostname.

However, the difference between X.509 and OpenPGP is that for X.509,
it is the CA who signed the server certificate who has to agree that
the server certificate is responsible for that particular server, so
the information has to be in the server certificate.  There is no
similar concept in OpenPGP.

This logic suggests that GnuTLS should not check the hostname against
the OpenPGP ID packet at all.  All authorization decisions should be
based on the trusted key list.

I think you convinced me.  I don't have time to think about code
changes right now though.  Possibly we could just improve
documentation.

/Simon