[Swan-commit] Changes to ref refs/heads/main

Andrew Cagney cagney at vault.libreswan.fi
Sat Sep 19 01:52:02 UTC 2020

New commits:
commit c49aae0e0108181a9bb3fdf520a70a8d3a1b9a01
Author: Andrew Cagney <cagney at gnu.org>
Date:   Fri Sep 18 16:56:24 2020 -0400

    crypto: during "whack add", save the rsasigkey's CKAID and then, later, use that to find the private key
    Follow-up 1bc63884ed4a71a531217c51a045e0ce971b172d which fixed
    selecting a raw private key using the CKAID.
    This code:
    - modifies whack so that the "connection add" message includes the raw
      key specified by {left,right}rsasigkey=
      Previously this information was only sent later.
    - modifies pluto to capture {left,right}rsasigkey='s CKAID and save it
      in the connection's end
      Provided the raw key's type (RSA ECDSA) is specified, the code is
    - code added by 1bc63884ed4a71a531217c51a045e0ce971b172d then uses the
      CKAID to find the private key during IKE_AUTH (i.e., on demand).
      Previously the (possibly generated) left/right id was used
    This means a config file containing just:
      conn west-rsasigkey-east-rsasigkey
            # other stuff
    works (no, there's no smoke and mirrors aka ipsec.secrets).
    Open issues ....
    (Keep in mind that this change only affects config files containing
    *rsasigkey=.  It can't affect keys loaded explicitly using whack
    and/or ipsec.secrets.  It isn't even possible to specify rsasigkey=
    from the command line.)
    - given a config file containing both rsasigkey= and rsasigkey2=, this
      code always uses the former's raw key to generate the CKAID and,
      thence, find the private key
    - given a config file containing rsasigkey= and/or rsasigkey2=, whack
      will still send messages to add these raw public keys to the public
      key list; this means code trying to verify using both public keys
      will still work
      However, being able to specify two rsasigkeys in the config file,
      doesn't appear to be tested.  Can the feature be dropped and,
      instead support this using ipsec.secrets?
    - pluto will use the first of: cert=, rsasigkey= and ckaid=, any
      latter fields are warned but ignored (whack might also reject some
      combinations making this mute)
    - because the end's private key is pinned down using the config files
      rsasigkey='s CKAID, selecting the wrong private key isn't possible
      Hmm, this is sounding a lot like "`pluto` chooses wrong raw RSA key
    - because the end's private key is pinned down using the config file's
      rsasigkey='s CKAID, it isn't possible to roll over the private key
      I don't think this has ever worked with raw keys - they get loaded
      once and are then stuck.  The reload feature only works with
      Anyone wanting to roll over keys should probably use ipsec.secrets
      or real PKI.
    - this new code does not check that a private key matching the CKAID
      exists; that happens much much later when the code tries to use the
      key during IKE_AUTH
      See the discussion "can add connection require a private key?" for
      why (short answer: connection isn't oriented).  The current working
      theory is that any code checking for the private key should go in

More information about the Swan-commit mailing list