Re: [openpgp] details of 4880bis work

On 21/04/2015 3:58 am, Werner Koch wrote:

On Mon, 20 Apr 2015 18:49, ben(_at_)adversary(_dot_)org said:

keyblock formats?  Specifically that newly generated keys should *NOT*
consist solely of a primary with SCE or SCEA.  Though as near as I can
tell, this will mainly only affect the Kmail + Kleopatra Kontingent


Sorry, I do not understand this.  I can imagine reasons why you want a
signing and encryption capable key and no subkeys.


Really?  Alright then at least make it so that in each implementation
that's not the default.

What has this to do with Kmail + Kleopatra ?  They use standard GnuPG
and I am pretty sure that they create RSA+RSA keys; after all this is
what gpg4win does which is the standard installer for GnuPG.


No, Kleopatra's default config in gpg4win is to create RSA as SCE
with no subkeys.  Like this:

pub  rsa4096/0xD3..REDACTED..47
     created: 2014-12-29  expires: never       usage: SCE
[ unknown] (1). S**** L***** <REDACTED(_at_)gmail(_dot_)com>

BTW, this is a real key belonging to a prominent Australian political
figure, who has been somewhat vocal on privacy issues (hence using his
personal address and not his other one).  Fortunately for him we'll be
at the same event next week and I can help him fix it, but that's pure
chance and something all the other gpg4win users don't get.

It wouldn't be so bad if GPA was the default GUI, but it isn't,
Kleopatra is the default install with GPA requirong manual selection
when the installer launches.  Instead users get whatever defaults are
set by the Kleopatra team in that product (which seems to be to try to
turn OpenPGP into SMIME).  If there's some function that Kleopatra
performs and GPA doesn't then that sounds like a good reason to draft
some volunteer help in expanding GPA.  Even the little Qt thing the
GPG4USB team came up with would be better than Kleopatra if it could
work with 2.0.  Plus there are numerous reports of a higher frequency
of bad signatures and other errors from people using KMail clients,
very likely linked to other aspects of poor implementation.

The only way for gpg4win users to get a key with subkeys is to either
manually add one after key generation, use GPA instead, use the
command line instead or do ignore those frontends entirely and
generate within Enigmail.  The only thing in gpg4win's favour at this
point is that someone in a country that won't lock them up for
exporting crypto (so that rules me out ... at least once ECC is
involved) can build a version which removes Kleopatra from it
entirely.  At least that process looks pretty simple (a little line
removal in packages/packages.current should do it).

(out of the box) and, maybe, the Bouncy Castle Java devs who continue
to insist on that kind of poor design choice and then inflict them on
unsuspecting end users to the detriment of those users and everyone


In case you refer to a bug report where some Bouncy Castle based
implementation ignored the keyflags [1]: This is clearly a bug in that
implementation.  I actually heard stories at the weekend about
implementations which didn't implement even very basic requirements.  It
is not a problem of Bouncy Castle, though.


I can't off the top of my head right now, but given BC is just the
java libs it might have been one of the other projects which leaned so
heavily on it.  Maybe Portable PGP, but I thought it was more recent
than that particular travesty.  Ah well, maybe it'll come back to me
later, still I guess if people are Hell-bent on breaking something we
can only advise them not to (and then get out of the line of fire).

[1] Which ignored the key flags and encrypted to the primary key which
    happened to be on a smartcard which enforces PKCS#1 for the key so
    that the reporter was not able to decrypt.


Wow, that's just hilariously bad.  I shouldn't laugh at that, but I
just can't help it.  :)


Regards,
Ben

signature.asc
Description: OpenPGP digital signature

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp