"known in advance" public key authentication?

[Ivan Shmakov]

>>>>> Florian Weimer <fw at deneb.enyo.de> 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