On 18/01/18 16:49, Selva Nair wrote: > Hi > > On Wed, Jan 17, 2018 at 3:53 AM, Steffan Karger <steffan.kar...@fox-it.com > <mailto:steffan.kar...@fox-it.com>> wrote: > > Hi, > > On 17-01-18 05:24, Selva Nair wrote: > > Also I'm toying with the idea of renaming ecdsa-sig/ECDSA-SIGN by > > pkey-sig/PKEY-SIGN so that eventually we may be able to use it for > > all types of keys and retire rsa-sig. Any thoughts on that? > > This was my first though when looking at these patches. Haven't looked > at the code yet, but functionally I think that's the way to go. Even if > it were that Ed25519 / Ed448 sigs are technically not ECDSA sigs. > > > I was waiting for the chatlog before finalizing v2. Looks like there are a > number of opinions > that seem to converge towards the same view. > > This is what I have in my current v2 ready to go out: > > (i) Current behaviour for rsa signatures stays for now: daemon sends >>RSA_SIGN client responds > with rsa-sig > (ii) Daemon sends >PK_SIG client responds with pk-sig [*] > Initially this will be used only for EC, but trivial to switch RSA to this in > future. > So document that new mgmt clients should be prepared to handle all supported > key types via >PK_SIGN/pk-sig and >RSA_SIGN will be eventually removed. > > As a nice side effect, clients are allowed to respond with pk-sig even if the > challenge was >>RSA_SIGN. As a not so nice side effect, the daemon will reply with "SUCCESS > rsa-sign > succeeded" because that's what it asked for -- I suppose we can live with > that. > > We can deprecate and remove >RSA_SIGN at a later date by a hard switch when > all known clients are capable of handling >PK_SIGN > > Does this sound like an acceptable solution? > > Question: while at it should we alter the syntax to >>PK_SIGN,xxx,<base64> > > where xxx will be empty for now, but it reserves space for extra info that may > come handy for some future signature types (like use PSS padding for RSA or > use PureEdDSA or whatever).
Hi, I've discussed this quickly with James quite recently. We are concerned about breaking existing front-end integrations by doing too much funky stuff with RSA_SIGN for EC support. That in particular touches the signal renaming to PK_SIGN. So we have another suggestion. For external keys to be used, --management-external-key is needed. Add an optional argument to this option, which indicates a version. If this argument is not provided, everything works as it is today - without EC support. If using: --management-external-key 2 ... for version 2, do a hard-shift to PK_SIGN with RSA and EC support. This way we ensure we don't break any existing implementations, we can allow a period of transition to the new version, and we can in the future when we are sure PK_SIGN works well and has seen deployment elsewhere start a deprecation process if the legacy version 1. But we're not put in a situation where anything changes suddenly and abruptly. Any thoughts? -- kind regards, David Sommerseth OpenVPN Inc
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
