help-gnutls
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "known in advance" public key authentication?


From: Ivan Shmakov
Subject: Re: "known in advance" public key authentication?
Date: Thu, 08 Nov 2012 10:18:26 +0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

>>>>> Florian Weimer <address@hidden> writes:

[…]

 > Make sure your certificates are valid X.509v3.  GNUTLS is extremely
 > forgiving, and if you've got a widely deployed certificate which
 > cannot be used with Java (for instance), this can be annoying.

        Even if I'd choose to follow this path, the certificates will be
        generated “on demand”, using the information the application has
        access to.  Should such certificates be found unsuitable for a
        particular TLS implementation, I'd only need to amend the
        generation procedure, and regenerate the offending certificates.
        (Though, indeed, that may take a good deal of time should the
        application in question become widely deployed.)

        That being said, I've got an impression that OpenPGP
        certificates and keys are much more simple to generate (from C
        code, at the least.)  Do I understand it correctly that the
        support for OpenPGP certificates isn't implemented as widely as
        that for X.509 ones?

        The other idea would be to use “anonymous” authentication, and
        then perform a kind of a “check” against MitM on the already
        established channel.  Is there a way to initiate a “re-keying”
        using a caller-provided symmetric key, for instance?

        OTOH, most of the data transferred over such a channel will
        either be public (and then either self-certifying or signed) or
        already encrypted anyway.  Thus, for a start, I may forget about
        authentication altogether.  Unfortunately, some fraction of the
        data is likely to be at least mildly sensitive, and apart from
        that, an authenticated channel opens a possibility of a DoS.

-- 
FSF associate member #7257




reply via email to

[Prev in Thread] Current Thread [Next in Thread]