On Thu, Nov 15, 2018 at 2:22 AM Arne Schwabe <a...@rfc2549.org> wrote:
> > >> Unless I overlooked something, I don't see any situation in which we ask > >> for an unsupported signature. > > > > Consider this: > > (i) config has --management-external-key nopadding but client announces > version > > 2. We will not error out but send the signature request as > > PK_SIGN <base64data> > > without the ALG as client version is not 3 and fail > > We can error out on version on the management line. But this is also a > kind of obscure misconfiguration since why would add nopadding to the > config if you cannot support it? > True, but by same argument then we need not worry about backward compatibility of management protocol at all, do we? We could say, why would any one use openvpn.exe that speaks MI version 3 with a client that cannot support it. Anyway, for backward compat its enough to check client version and then either error out if ALG is not PKCS1 or ECDSA or add ALG to PK_SIGN. I fail to appreciate the utility of early erroring out feature -- it was meaningful in v1 where you had tried to downgrade to TLS 1.2 to plough along without causing an error. But that turned out to be not enough. > > (ii) tls version max is set 1.2 and openssl 1.1.1 is in use both on > > server and client. > > PSS signing will get negotiated but we will not error out early as TLS > > 1.3 is not in use. > > > > That's why I say that this extension of management-external-key is not > worth it. > > > > Am I missing something? > > > > tls_version_max will still report TLS 1.3 as it not affected by the > version set in config but really the max the library is capable of > irrespectable tls min/max version. > Aha, I missed that. Still I really do not understand the need for erroring here instead of when prompting for PK_SIGN based on client version. Much simpler. Selva
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
