CLI: rnpkeys does not support adding new additional subkeys to existing primary keys.

antonsviridenko commented 2 years ago

Description

Looks like this basic & important feature was discussed and planned to be implemented long time ago (like here https://github.com/rnpgp/rnp/issues/323) but is not implemented yet.

Steps to Reproduce

There is no rnpkeys command to add new subkeys. One has to use GnuPG command line tool for this task.

Expected Behavior

rnpkeys should support adding subkeys. This feature can be implemented in multiple ways:

Implement new command --add-subkey with primary key specified as a parameter.
Add new option --subkey to the --generate-key command.
Extend --edit-key command functionality.

antonsviridenko commented 2 years ago

@andrey-utkin are you interested to take this task?

andrey-utkin commented 2 years ago

Legit issue. Happy to take it. Would love to see what @ronaldtse or @ni4 think about its priority, though.

ni4 commented 2 years ago

@andrey-utkin it would be good to have this functionality, feel free to take this issue.

ronaldtse commented 2 years ago

Thank you @andrey-utkin @antonsviridenko !

antonsviridenko commented 1 year ago

So I want to implement --expert mode for subkey generation, now it looks like this for default primary & sub keypair.

Please select what kind of key you want:
        (1)  RSA (Encrypt or Sign)
        (16) DSA + ElGamal
        (17) DSA + RSA
        (19) ECDSA + ECDH
        (22) EDDSA + X25519
        (99) SM2

I want to implement something similar for subkey algo selection. What was the logic in assigning these numbers? RFC says

      ID           Algorithm
      --           ---------
      1          - RSA (Encrypt or Sign) [[HAC](https://www.rfc-editor.org/rfc/rfc4880#ref-HAC)]
      2          - RSA Encrypt-Only [[HAC](https://www.rfc-editor.org/rfc/rfc4880#ref-HAC)]
      3          - RSA Sign-Only [[HAC](https://www.rfc-editor.org/rfc/rfc4880#ref-HAC)]
      16         - Elgamal (Encrypt-Only) [[ELGAMAL](https://www.rfc-editor.org/rfc/rfc4880#ref-ELGAMAL)] [[HAC](https://www.rfc-editor.org/rfc/rfc4880#ref-HAC)]
      17         - DSA (Digital Signature Algorithm) [[FIPS186](https://www.rfc-editor.org/rfc/rfc4880#ref-FIPS186)] [[HAC](https://www.rfc-editor.org/rfc/rfc4880#ref-HAC)]
      18         - Reserved for Elliptic Curve
      19         - Reserved for ECDSA
      20         - Reserved (formerly Elgamal Encrypt or Sign)
      21         - Reserved for Diffie-Hellman (X9.42,
                   as defined for IETF-S/MIME)
      100 to 110 - Private/Experimental algorithm

So looks like 16 applies to the subkey algorithm, but for option 19 it is a primary key algo. looks inconsistent. And what document does define number 99 for SM2?

Is it ok if I just number selection options by successive numbers from 1 to 7? Like this

        printf("Please select subkey algorithm you want:\n"
               "\t(1) RSA\n"
               "\t(2) DSA\n"
               "\t(3) ElGamal\n"
               "\t(4) ECDSA\n"
               "\t(5) EDDSA\n"
               "\t(6) ECDH\n"
               "\t(7) SM2"
               "> ");

@ni4 @ronaldtse

ni4 commented 1 year ago

@antonsviridenko not sure about the real reasons, but for me it seems to resemble RFC numbers where it is applicable. 16 for DSA-ElGamal most likely was used to distinguish between DSA-EG and DSA-RSA keypairs. 99 (as far as I remember) was picked for SM2 using 'pre-experimental' number, to not interfere with other implementations could be using 100-110. OSCCA RFC marks it as TBD (to be defined): https://datatracker.ietf.org/doc/html/draft-ribose-openpgp-oscca-01

My suggestion would be to stick to the already existing behaviour, using the RFC-defined numbers, as you will not need any tricks to distinguish between DSA-EG and DSA-RSA keys.

rnpgp / rnp