Subkey Usage, Expire Date and Preferences problem
Hello, When I create unattended key with cv25519 or ed25519 as subkeys, GnuPG doesn't apply 'encrypt' usage, expire date and preferences. There is no problem with RSA. Regards. (PS : My example key numbers were padded with X and Y) $ gpg --batch --gen-key Key-Type: ecdsa Key-Curve: ed25519 Key-Usage: sign auth Subkey-Type: ecdh Subkey-Curve: cv25519 Subkey-Usage: encrypt Passphrase: Name-Real: Yan Fiz Expire-Date: 1y Preferences: twofish sha512 zlib $ gpg --edit-key showpref quit gpg (GnuPG) 2.2.5; Copyright (C) 2018 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. gpg: key : 2 bad signatures gpg: key : Warning: errors found and only checked self-signatures, run 'check' to check all signatures. Secret key is available. sec ed25519/ created: 2018-02-24 expires: never usage: SCA trust: ultimate validity: ultimate ssb cv25519/ created: 2018-02-24 expires: never usage: [ultimate] (1). Yan Fiz [ultimate] (1). Yan Fiz Cipher: 3DES Digest: SHA1 Compression: ZIP, Uncompressed Features: Keyserver no-modify ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Subkey Usage, Expire Date and Preferences problem
Hello, When I create unattended key with cv25519 or ed25519 as subkeys, GnuPG doesn't apply 'encrypt' usage, expire date and preferences. There is no problem with RSA. Regards. (PS : My example key numbers were padded with X and Y) $ gpg --batch --gen-key Key-Type: ecdsa Key-Curve: ed25519 Key-Usage: sign auth Subkey-Type: ecdh Subkey-Curve: cv25519 Subkey-Usage: encrypt Passphrase: Name-Real: Yan Fiz Expire-Date: 1y Preferences: twofish sha512 zlib $ gpg --edit-key showpref quit gpg (GnuPG) 2.2.5; Copyright (C) 2018 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. gpg: key : 2 bad signatures gpg: key : Warning: errors found and only checked self-signatures, run 'check' to check all signatures. Secret key is available. sec ed25519/ created: 2018-02-24 expires: never usage: SCA trust: ultimate validity: ultimate ssb cv25519/ created: 2018-02-24 expires: never usage: [ultimate] (1). Yan Fiz [ultimate] (1). Yan Fiz Cipher: 3DES Digest: SHA1 Compression: ZIP, Uncompressed Features: Keyserver no-modify ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Removing expired keys
Kleopatra Version 3.0.2-gpg4win-3.0.3 Running the command from Kleopatra on a Windows 10 PRO amd64 machine, displays numerous expired certificates. The complete output is available here: https://seibercom.net/GPG-Expired-Keys.txt Is there any command that I can run from either Kleopatra or the Windows' command line that will remove all of these expired certificates? I would really love to clean up system and removed expired or revoked certificates. Also, how do I deal with "signatures not checked due to missing keys" warnings? Thanks! -- Jerry ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Issuing non self-signed certificate without having the private key in gpgsm keyring
Hi everyone, (please CC on reply, as I am not yet subscribed) I am currently using gpgsm as somekind of PKI CA. It allows me to keep the CA private key stored on a smartcard, and create/sign different X.509 end-entity certs through the --gen-key --batch mode. ATM (with gpgsm (GnuPG) 2.2.4) , due to [1], gpgsm cannot sign certificate for which a public key has been imported but without an associated private key to it (disregarding the self-signing situation): [--gen-key --batch] gpgsm: line 1: error getting key by keygrip 'D3513A1E...48E0BDB6D35': No such file or directory gpgsm: error creating certificate request: No such file or directory unable to load certificate Typical X.509 PKI setups do not require the CA to have access to the entity private key for issuing a corresponding X.509 certificate. I still manage to fake that around by creating a corresponding private key file with the correct keygrip under private-keys-v1.d/ , but this is at best a really dirty hack. Would it make sense to relax the test in [1] and allow certificate creation when we are not issuing a self-sign cert? Thanks, [1] https://github.com/gpg/gnupg/blob/master/sm/certreqgen.c#L712 -- Jean-Yves Migeon ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
