Re: keys require a user-id

2020-05-20 Thread Mark 
Did a bit more experimenting with it.  You can have something only in
the first name field but it has to be a minimum of 5 characters and the
first one must be a letter. .. 

On 5/20/2020 3:16 PM, Mark wrote:
> It must be... With all the talk of "anonymous" keys I wanted to see if I
> could create one with Kleopatra, especially since it says optional for
> name.
>
> On 5/20/2020 12:27 AM, Andrew Gallagher wrote:
>>> On 20 May 2020, at 06:32, Mark  wrote:
>>>
>>> Just to test this out I tried creating a new key in Kleopatra with no
>>> name and then with just a single name and it would not let me do it. It
>>> had to have a first and at least a last initial.
>> This must be a Kleopatra limitation. I have successfully created IDs 
>> consisting of a single word using the gpg command line.
>>
>> Such a limitation would be user-hostile, as there are people in some 
>> cultures who have only one name, the Indonesian dictator Suharto being one 
>> famous example.
>>
>> A
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keys require a user-id

2020-05-20 Thread Mark 
It must be... With all the talk of "anonymous" keys I wanted to see if I
could create one with Kleopatra, especially since it says optional for
name.

On 5/20/2020 12:27 AM, Andrew Gallagher wrote:
>> On 20 May 2020, at 06:32, Mark  wrote:
>>
>> Just to test this out I tried creating a new key in Kleopatra with no
>> name and then with just a single name and it would not let me do it. It
>> had to have a first and at least a last initial.
> This must be a Kleopatra limitation. I have successfully created IDs 
> consisting of a single word using the gpg command line.
>
> Such a limitation would be user-hostile, as there are people in some cultures 
> who have only one name, the Indonesian dictator Suharto being one famous 
> example.
>
> A

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: "just invent something..."

2020-05-20 Thread LisToFacTor via Gnupg-users 

On 5/20/20 6:52 PM, Andrew Gallagher wrote:



On 20 May 2020, at 18:51, LisToFacTor via Gnupg-users  
wrote:

Demanding a piece of information from someone who would prefer not
to give it is equally user-hostile, especially so if he who demands
it does so only because it is required by some internal mechanics
of the system he constructed


“Demand” is a strong word that I don’t believe is justified here, and only 
serves to inflame the debate.

Most implementations of email require that you enter a “real name” of some 
kind. OpenPGP/GPG strongly encourage you to use the same real name on your key 
as you use on your email profile - this is for the benefit of your 
correspondents, since using different IDs will likely cause confusion. You are 
free to ignore this recommendation but I don’t think the documentation should 
encourage novices to do so.

English is not my native tongue, and the word I've chosen is based
on my interpretation of the dialog presented by the program when
generating the key:


GnuPG needs to construct a user ID to identify your key.
that the Old Guard (somebody

used the term in one of the previous posts) just can't even

Real name: 

upon entering an empty string, the response is:
...
gpg: [internal]: no User-ID specified 

(and the program quits with no further explanation)

To me, this appears to qualify as a demand for user's "Real name".

It is not up to a program designer to decide that it is mandatory for
a user to provide a piece of personally identifiable information
because "this is for the benefit of your correspondents, since using 
different IDs will likely cause confusion."  User is the one to decide 
what personally identifiable information to provide, when and to whom.


And if the is demand for such information is refused, and the service
is summarily denied, (as outlined above) then it is not okay for the
program designer to wash his hands with "...so why didn't you just
invent something...".

Of course, it would be a one-minute job to change the prompt to
"enter a “real name” of some kind..." (or something to that effect,
better formulated). But with that, the whole "Web of Trust" structure
would collapse, and that is something to horrible to even
contemplate.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Comparison of RSA vs elliptical keys

2020-05-20 Thread Ryan McGinnis via Gnupg-users 
Interestingly enough, this breaks the Thunderbird/Protonmail integration, so 
your message just shows up as the raw PGP blob that Protonmail is pushing to 
the Protonmail client.  It returns the error 


" Decryption error
Decryption of this message's encrypted content failed.

openpgp: unsupported feature: nested signatures
"


-Ryan McGinnis
http://www.bigstormpicture.com
Sent via ProtonMail

‐‐‐ Original Message ‐‐‐
On Wednesday, May 20, 2020 12:18 PM, MFPA via Gnupg-users 
 wrote:

> Hi
> 

> On Saturday 16 May 2020 at 9:49:55 PM, in
> mid:20200516224955.5826@300baud.de, Stefan Claas wrote:-
> 

> > out of curiosity, you signed the reply with two sub
> > keys,
> 

> The RSA signature is for the benefit of recipients who can't handle
> ECC keys/signatures. Probably not needed anymore.
> 

> > the hash algo
> > used?
> 

> I'm hopefully using SHA512.
> 

> --
> 

> Best regards
> 

> MFPA mailto:2017-r3sgs86x8e-lists-gro...@riseup.net
> 

> Ballerinas are always on their toes. We need taller ballerinas!



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

FW: gpg-agent connection errors

2020-05-20 Thread Kent A. Larsen 
Werner,

If that's the case, then why do we continue to intermittently get the following 
messages when issuing a command to sign+encrypt (or decrypt) a file?

gpg: can't connect to the agent: IPC connect call failed
gpg: keydb_search failed: No agent running
gpg: skipped "0x8A811544": No agent running
gpg: 
//neofs1/Userdata/IT/FileRetrieval/Chase/PositivePay/Positive_Pay_LifePRO.txt: 
sign+encrypt failed: No agent running

I've adding logging to our gpg-agent.conf file, and when these errors occur the 
gpg-agent log file has the following error:

2020-05-18 09:36:07 gpg-agent[3800] error binding socket to 
'\\Neofs1\Userapps\Apps\GnuPG\Keys\S.gpg-agent': Unknown error

Have had three of these just this week already.

What could be causing this, and what can we do to prevent it?

Thanks.

Kent A. Larsen, FLMI
Systems Analyst
New Era/Philadelphia American Life Insurance Companies
klar...@neweralife.com
Direct: (402) 905-2179

Reply

No.  Fruther, gpg-agent and all other background processes are always
started on demand.


Shalom-Salam,

   Werner

--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

-Original Message-
From: Kent A. Larsen
Sent: Tuesday, May 05, 2020 7:10 AM
To: gnupg-users@gnupg.org
Subject: gpg-agent connection errors

As part of a server upgrade, we recently replaced a GnuPG 1.4.x installation 
with GnuPG 2.2.19, from the Gpg4win package (3.1.11). The server is running 
Windows Server 2016.

We have an un-attended application that runs on that same server that needs to 
sign+encrypt  a file (4 to 6 distinct files each weekday)for transfer to an 
external client.

Since the upgrade, invoking gpg to sign+encypt a file periodically fails with 
the message "gpg: can't connect to the agent: IPC call failed" followed by 
messages indicating "No agent running". The failure appears to occur on the 
first file processed (in a group of 3 or more files), and the remaining files 
are processed without error.

We are relying on gpg to automatically start gpg-agent (as needed). Does 
gpg-agent auto-terminate after a certain period of inactivity?

Would appreciate any help you can provide that would allow us to eliminate 
these errors. Thanks.

Kent A. Larsen, FLMI
Systems Analyst
New Era/Philadelphia American Life Insurance Companies
klar...@neweralife.com
Direct: (402) 905-2179



HIPAA requires covered entities to safeguard Protected Health Information (PHI) 
related to a person's health care. Information in this email may include PHI 
that has been provided after appropriate authorization from the patient or 
under certain circumstances that do not require the patient's authorization. 
You, the recipient, are obligated to maintain PHI in a safe and secure manner. 
You may not use or disclose this email without additional patient consent 
unless required by law. Unauthorized use or disclosure of or failure to 
safeguard PHI could subject you to penalties under state and/or federal law. 
The information contained in this email and any attachments is also 
confidential and may be subject to copyright or other intellectual property 
protection. If you are not the intended recipient or the employee or agent 
responsible to deliver it to the intended recipient, please notify us 
immediately and delete this email from your email system. Please also shred any 
hard copy of this email and attachments, if any. If you have received this 
email in error, please notify our Privacy Officer immediately at (281)368-7200 
(in Houston) or toll free at (800)552-7879.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: "just invent something..."

2020-05-20 Thread Andrew Gallagher 

> On 20 May 2020, at 18:51, LisToFacTor via Gnupg-users  
> wrote:
> 
> Demanding a piece of information from someone who would prefer not
> to give it is equally user-hostile, especially so if he who demands
> it does so only because it is required by some internal mechanics
> of the system he constructed

“Demand” is a strong word that I don’t believe is justified here, and only 
serves to inflame the debate. 

Most implementations of email require that you enter a “real name” of some 
kind. OpenPGP/GPG strongly encourage you to use the same real name on your key 
as you use on your email profile - this is for the benefit of your 
correspondents, since using different IDs will likely cause confusion. You are 
free to ignore this recommendation but I don’t think the documentation should 
encourage novices to do so. 

A
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keys require a user-id

2020-05-20 Thread Stefan Claas 
Stefan Claas wrote:

> I ask, because don't you think that this could not have an impact on
> the spread and usage of GnuPG in the EU for business purposes etc. 

With that I mean the acceptance of GnuPG Signatures, compared to costly
eIDAS solutions.

Best regards
Stefan

> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users



-- 
Signal (Desktop) +4915172173279
https://keybase.io/stefan_claas
   

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

"just invent something..."

2020-05-20 Thread LisToFacTor via Gnupg-users 

On 5/20/20 7:27 AM, Andrew Gallagher wrote:


Such a limitation would be user-hostile, as there are people in some cultures 
who have only one name, the Indonesian dictator Suharto being one famous 
example.


Demanding a piece of information from someone who would prefer not
to give it is equally user-hostile, especially so if he who demands
it does so only because it is required by some internal mechanics
of the system he constructed. Answering user's objection to such
request by telling him: "well, if you don't want to give me this
information, just invent something..." is wrong on so many levels
that I feel no need to get into.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Comparison of RSA vs elliptical keys

2020-05-20 Thread MFPA via Gnupg-users 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi


On Saturday 16 May 2020 at 9:49:55 PM, in
, Stefan Claas wrote:-


> out of curiosity, you signed the reply with two sub
> keys,

The RSA signature is for the benefit of recipients who can't handle
ECC keys/signatures. Probably not needed anymore.



> the hash algo
> used?

I'm hopefully using SHA512.

- --
Best regards

MFPA  

Ballerinas are always on their toes.  We need taller ballerinas!
-BEGIN PGP SIGNATURE-

iQ8RBAEWCg65FiEElgyGKNWS/4zei7C/4OLe4dbI7voFAl7FZlpfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk2
MEM4NjI4RDU5MkZGOENERThCQjBCRkUwRTJERUUxRDZDOEVFRkHNeiYAmQINBFmF
3poBEACjmnBUOd79vOc6sywdw7d85ItYQDeSh5WhTguXkt84+8C+oLXYbWelVmyj
tZ+vOsZSXb44tE2zNCWouNK/wcE16JmmIV3VVn9I/EpMTK/iFx3e/SGk6C56uopg
sQFlDjbYRZ6bPc+ImsEdfaj3DyYrWJO3dCEBEEOv4/u7UZ/ulBJOEW4pCJjgk7es
mT9LmG0AvSSUZhZQqqMo5wvrfz07uDbJ6MFjPXgBIThtJPjKSpTXCaaCs2GJZVkK
agR1rexytIgsEU3OYHAl+qYfHqcFqa1xbrdEjC8RDFIU0vJc3aGpRufGEVlnDw/L
fWN6qX4NE9IC/QyKFXEQOybP9UEl9ti/dE6FUSHT+g/M4zCdSL1RFMkz91/Unjgr
ZAboMoKgBZqYLpawjYIyVMYTdIerDQYiymCdD+Ifkgc3FwgTsfSFnFJXwLL2hqJG
oZSz6jHKKiDDKathLQqWEvAbCo6FP5VsqILi2Tu+6IWOeLp07YXzDiDNR7/yqDGO
CavYmwN3mt5TwdNeOd22LFWHLBcsDc5gIB2EkJoMpemG1TJi60FX9P2WI8K7ICBm
FzwnvH9i2xBln+4+YDHyod7clC1I0wE2BbO6ttNaUR/6Xczm8gjx0zzKsvOZZDTX
jXtO8ss41j7Rg0TS3C4+QWMcmHCJCiu8tD4GS5du/V5xw8TJ8QARAQABtBIweEFD
RTU2OTcxRDU1NURBQTWJAl4EEwEKAEgCGwECHgECF4ACGQELCw0JCAwHAwsKBAIG
FQoJCAsDBRYDAgEAFiEEeRDEX4n8jMLL0kqwrOVpcdVV2qUFAl6wGFwFCQnQtEIA
CgkQrOVpcdVV2qU6AQ/9EaAae++qSxy9iM2a3Jfbqr5kEV+mJ//r6SIoDJPVANfb
5oHF/KZtF0a+SXR+cPPBMVKsppZ0Qr80FkjAUOH5YuUbTq2B+YvqMo5DLqBa2QiC
ax6x11udSI0IM2CL7I5vMcRuY+Z/P3FZ9RI+C7ALL+EgJ6xtFyYHOcVVYd/a0O/O
TH9KOVwcdtDChrRZBOC46+5hlcFxd3nwMUmXpRD1PE5+20vUbmyz2uKjHn93fOh2
MNMLhoO9qci+kKliawuU7UQ42VTO6FtUSoUpgPh37sVMImezC4jYm/1d3AFPCxpA
jP7mHgKxOwP6fw+hIEWoybv0Ws3BEhM4TInobQUs0wdsWLQ83x5L9IvEcL643mkL
bxCA48Fiw2YTWyuEdhIeSOtLTrM2k5xDVX5kPASGqG7rTP/exBo5Vg2UZWhPJuiE
fYaJR7PAl0i+318yQShIWg0Zt1Ob3K7/3yqvHDFzaAaKOlN9CZR5XVEcyq9G6M2u
u5cOZ0LQJTn/UFHYOK8D9/T33Zfac8tIjiIn916i1YvqYIzS14GKS8oqISy3FkD3
2tQf8ok/8PvnXe1xQPTAtIj3UqpiQf0L8xt96hLJHKphmR/ksKYBDdZFWRD/U0Na
kXjnepP0ek68fR3wO4lbYKG9x94YDM/7pQ1BpfZZMLrp+3xvTBxmgQCtAuUiJem5
Ag0EWYXwgAEQAO+wh3g3SgeBWkzLaIHo3p7Z92CyEnssgvZnfaWNBowuv1INtprq
a15yRpaIr8eFlchlVqCiQ2FN54tWkND5qlallwi2YSUW+nkEXCvyUR1S///MmwI5
qos0A+Sil3uPsuBQtRezCaNEghM5a83Lfvv9kYqzfa9D6gCYUCv6NtbH/yeshOuR
hT2P3jFK0+kIObyPO26XsbfdbocutYA3c/27TAsE8VJvu4yqL5CUvz5H+EzGAdmr
XVYD/VFxMrbIkKjmb7I0Tnl8RF3IUsL3SK/AKWYPOI4mMp5dv4yO/gYVoWX5Fd4d
v6EQmvHMfiIvsxP8EBOTNVEtj/rac4P7Trdsc7CWsL5zzpofxIFQibo3JVNTRs/P
PIlVmPROYLbXaolufgAmi+E8BCer780yc4nkmWOEcepuk3cQCM3l6OrgI8aWQyrc
f4uW4Jtn98AldJ21PhtN4A0d5PF0YvX/OrXoi3XBROUVLY6IF5QbkSMeOvqJWzgk
txvULI53Q3jtZvgtmF2dZ5rFgJCy3PjuXRBi2ZTz47eW94E7xDr04euhFnyMaiDM
KS0XAj978kyCUrtDsssWp83j1IZt5Bd7JmtohThlEZCQ3Y0u3Gjmj9Nkv18qmF8O
21Qe0LzG8Ad9HPTbQd9Rk+GQz57WxlcsjK2bC0WG7f6R5BHq1YmuoD8nABEBAAGJ
AjwEGAEKACYCGwwWIQR5EMRfifyMwsvSSrCs5Wlx1VXapQUCXrAY4QUJBrb74QAK
CRCs5Wlx1VXapXcrD/9ktCowTIi5PtKUCjuttsaZzVRnAeTee3WvPJwbrFR7L3Jk
x3OM1KeSni+YsAfBrLi7xag4IIt8alQ6cYww2/q1aFPrs6opl2ou6NLxM4ynxkV8
Gb2kqiwUVlf5QFUVJOoNeVwoiNelklUj5jGq3KZGqhq4OSC5fkcCtOsjOffWWD1Y
ACZL4aHrxUM/njHq8k+WBNocYtdmbFH8Iujzf27tsV8b0yIKGs6L5jjkFpSDQo+/
jiGafLVsddu9TeZr9Jm7OGo/u6q8ozCxaTg/G7fLF9DGrj1+AakN9sujxRgXkccI
znci5qPW0dzOzhVUcaVPDdhfv/O3RXbky2qMSk+uxB5drqJ7LbOkPVTbDadspla8
2oJw3OoWuR0uC0aK7eibuFlurms6CcG/UQYQv9cjS4wGVe44S6/wiUBjfJXT3ITo
rl38PcBigpF0XYWk2FAdE40xPN3REKv2Byulmjnc3ia2R+zBWuPg30LsQtFWgiwN
tYJ5n/J08Ek+gqA6lNX9pRKT8lq6RQgQrvir7d/9Zw+RGaaVB1EnBUJi49O0Sfqs
voFLstR1XnlhQubkhk5jhZ582Pug6K2H3b9sgU5ycTaWSEBr1B0AbvIetF5qO+pJ
Y/vT452Br2g6CKXSpS2y6wwcqC0e/dkB31uFl1s4fRUmGxmBXnK4GFu/ufjNzrgz
BFmF9HQWCSsGAQQB2kcPAQEHQIvVCKWPutMpY7ED7YDL8qev9tgCb5RSXPkzirJJ
WjDZiQKzBBgBCgAmAhsCFiEEeRDEX4n8jMLL0kqwrOVpcdVV2qUFAl6wGK8FCQhD
yzoAgXYgBBkWCAAdFiEElgyGKNWS/4zei7C/4OLe4dbI7voFAlmF9HQACgkQ4OLe
4dbI7vpdcAEA2GBaDiUbWapujHFGfh/a3MH1mXU/7Vrf+6aCBSoqwlABAOlljw5f
6gCnD6b8LjBIsS2W/U5jTtAt1aouzFDvhioICRCs5Wlx1VXapcvPD/0bteHRI4dW
3r4XqFKKVbKsc6gRaQRfUOZq3L0Pcadx0BoJorjnzCRY1KytAqyAjYH2ossd10Fm
MLL5RTkNBvdcWTD6ZKIJQICEu0o2BJcPzKXVB2pJNsHJSMQyhAqbgUKfnePJza+4
p80PL6eBWttufKcNtJwYgkTJhchKoa+Se2h2mt53v6jdIusKwM91dW+0U5E6Jkom
v3CKsSSsWIh8F5OpPJVz7/+2lThO2NOzLth762cV+yqsPGr9Dr9zsCkiIhRfr7hj
2L4AxO0ljYzd6FuR17WSvqHx3x2Sz8D2B5HxNQ0o6wxlnH3AlEti6/zSTtc0+AOx
nOTZwj/CPQrly4MP8fNbhjOVNoLcfyq4u2/HB843/IWv+S7rob6qHF3rJ49Ltl8+
nsUJ2JKBUue9L5RnEPgIHuuFwDXp9XRXoj0+s2W2N0IScpYFj0HRW9/0NV3pn+t3
C2L5aCiCFSX9Ueg42RoPQR8szYyrhpmLVdNkuTSX5l86RLVMNw8ncuhpHvClOoRM
REjLwYgf9g7T3kygf97LzAjlPSVcAw98HkdEV+h5V6AqOJkHNXfRHPiCLglF0S24
ePGprxeIN8ufmOdkdkpH91RhQRybVOtyQdrgIPnpBFBaFMfV0sDb+DcSx7hvYgHW
kJqXDu2iDN2W3ZySYVrR/yLkuuawf9Lpcbg4BFmF99oSCisGAQQBl1UBBQEBB0CC
RNDhUo58xjQ/zW1Kebdb8evrP6QU27xuMfpj0WRRfwMBCAeJAjwEGAEKACYCGwwW
IQR5EMRfifyMwsvSSrCs5Wlx1VXapQUCXrAY4QUJBrb0hwAKCRCs5Wlx1VXapSc0

Re: keys require a user-id

2020-05-20 Thread Stefan Claas 
Werner Koch via Gnupg-users wrote:
 
> On Tue, 19 May 2020 10:29, Robert J. Hansen said:
> 
> > * PII-free UIDs are possible today
> 
> Well, according to European law this is not that easy because a public
> key is in most cases an attribute which identifies a natural person.

Curious as I am, did Mr Schönbohm never asked you why your public
keyblock is not signed by Governikus?

I ask, because don't you think that this could not have an impact on
the spread and usage of GnuPG in the EU for business purposes etc. and
for example if you would accept UID-less public keyblocks, privacy
concerned parents could for example allow their minors to use GnuPG,
while mom, dad or their teacher could sign their public keyblock?

Best regards
Stefan

--
Signal (Desktop) +4915172173279
https://keybase.io/stefan_claas
   

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Comparison of RSA vs elliptical keys

2020-05-20 Thread MFPA via Gnupg-users 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi


On Monday 18 May 2020 at 7:33:47 AM, in
, Werner Koch via
Gnupg-users wrote:-


> You are using --include-key-block; this is intended
> to be used by MUAs
> to send the encryption key along with a signature to
> allow for immediate
> encrypted reply.

I forgot I had added that to my gpg.conf file.

If the recipient has --auto-key-import set, they auto-import my key
after signature verification. But my choice to not include my email
address in my UID means they would not easily locate my key to send me
an encrypted reply.


> Or use it only with ECC keys.

Does (or will) --include-key-block have an argument that can be set to
tell it to only include ECC keyblocks, or to set a maximum keyblock
size?


- --
Best regards

MFPA  

Volvo, Video, Velcro. (I came, I saw, I stuck around.)
-BEGIN PGP SIGNATURE-

iQ8RBAEWCg65FiEElgyGKNWS/4zei7C/4OLe4dbI7voFAl7FY6hfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk2
MEM4NjI4RDU5MkZGOENERThCQjBCRkUwRTJERUUxRDZDOEVFRkHNeiYAmQINBFmF
3poBEACjmnBUOd79vOc6sywdw7d85ItYQDeSh5WhTguXkt84+8C+oLXYbWelVmyj
tZ+vOsZSXb44tE2zNCWouNK/wcE16JmmIV3VVn9I/EpMTK/iFx3e/SGk6C56uopg
sQFlDjbYRZ6bPc+ImsEdfaj3DyYrWJO3dCEBEEOv4/u7UZ/ulBJOEW4pCJjgk7es
mT9LmG0AvSSUZhZQqqMo5wvrfz07uDbJ6MFjPXgBIThtJPjKSpTXCaaCs2GJZVkK
agR1rexytIgsEU3OYHAl+qYfHqcFqa1xbrdEjC8RDFIU0vJc3aGpRufGEVlnDw/L
fWN6qX4NE9IC/QyKFXEQOybP9UEl9ti/dE6FUSHT+g/M4zCdSL1RFMkz91/Unjgr
ZAboMoKgBZqYLpawjYIyVMYTdIerDQYiymCdD+Ifkgc3FwgTsfSFnFJXwLL2hqJG
oZSz6jHKKiDDKathLQqWEvAbCo6FP5VsqILi2Tu+6IWOeLp07YXzDiDNR7/yqDGO
CavYmwN3mt5TwdNeOd22LFWHLBcsDc5gIB2EkJoMpemG1TJi60FX9P2WI8K7ICBm
FzwnvH9i2xBln+4+YDHyod7clC1I0wE2BbO6ttNaUR/6Xczm8gjx0zzKsvOZZDTX
jXtO8ss41j7Rg0TS3C4+QWMcmHCJCiu8tD4GS5du/V5xw8TJ8QARAQABtBIweEFD
RTU2OTcxRDU1NURBQTWJAl4EEwEKAEgCGwECHgECF4ACGQELCw0JCAwHAwsKBAIG
FQoJCAsDBRYDAgEAFiEEeRDEX4n8jMLL0kqwrOVpcdVV2qUFAl6wGFwFCQnQtEIA
CgkQrOVpcdVV2qU6AQ/9EaAae++qSxy9iM2a3Jfbqr5kEV+mJ//r6SIoDJPVANfb
5oHF/KZtF0a+SXR+cPPBMVKsppZ0Qr80FkjAUOH5YuUbTq2B+YvqMo5DLqBa2QiC
ax6x11udSI0IM2CL7I5vMcRuY+Z/P3FZ9RI+C7ALL+EgJ6xtFyYHOcVVYd/a0O/O
TH9KOVwcdtDChrRZBOC46+5hlcFxd3nwMUmXpRD1PE5+20vUbmyz2uKjHn93fOh2
MNMLhoO9qci+kKliawuU7UQ42VTO6FtUSoUpgPh37sVMImezC4jYm/1d3AFPCxpA
jP7mHgKxOwP6fw+hIEWoybv0Ws3BEhM4TInobQUs0wdsWLQ83x5L9IvEcL643mkL
bxCA48Fiw2YTWyuEdhIeSOtLTrM2k5xDVX5kPASGqG7rTP/exBo5Vg2UZWhPJuiE
fYaJR7PAl0i+318yQShIWg0Zt1Ob3K7/3yqvHDFzaAaKOlN9CZR5XVEcyq9G6M2u
u5cOZ0LQJTn/UFHYOK8D9/T33Zfac8tIjiIn916i1YvqYIzS14GKS8oqISy3FkD3
2tQf8ok/8PvnXe1xQPTAtIj3UqpiQf0L8xt96hLJHKphmR/ksKYBDdZFWRD/U0Na
kXjnepP0ek68fR3wO4lbYKG9x94YDM/7pQ1BpfZZMLrp+3xvTBxmgQCtAuUiJem5
Ag0EWYXwgAEQAO+wh3g3SgeBWkzLaIHo3p7Z92CyEnssgvZnfaWNBowuv1INtprq
a15yRpaIr8eFlchlVqCiQ2FN54tWkND5qlallwi2YSUW+nkEXCvyUR1S///MmwI5
qos0A+Sil3uPsuBQtRezCaNEghM5a83Lfvv9kYqzfa9D6gCYUCv6NtbH/yeshOuR
hT2P3jFK0+kIObyPO26XsbfdbocutYA3c/27TAsE8VJvu4yqL5CUvz5H+EzGAdmr
XVYD/VFxMrbIkKjmb7I0Tnl8RF3IUsL3SK/AKWYPOI4mMp5dv4yO/gYVoWX5Fd4d
v6EQmvHMfiIvsxP8EBOTNVEtj/rac4P7Trdsc7CWsL5zzpofxIFQibo3JVNTRs/P
PIlVmPROYLbXaolufgAmi+E8BCer780yc4nkmWOEcepuk3cQCM3l6OrgI8aWQyrc
f4uW4Jtn98AldJ21PhtN4A0d5PF0YvX/OrXoi3XBROUVLY6IF5QbkSMeOvqJWzgk
txvULI53Q3jtZvgtmF2dZ5rFgJCy3PjuXRBi2ZTz47eW94E7xDr04euhFnyMaiDM
KS0XAj978kyCUrtDsssWp83j1IZt5Bd7JmtohThlEZCQ3Y0u3Gjmj9Nkv18qmF8O
21Qe0LzG8Ad9HPTbQd9Rk+GQz57WxlcsjK2bC0WG7f6R5BHq1YmuoD8nABEBAAGJ
AjwEGAEKACYCGwwWIQR5EMRfifyMwsvSSrCs5Wlx1VXapQUCXrAY4QUJBrb74QAK
CRCs5Wlx1VXapXcrD/9ktCowTIi5PtKUCjuttsaZzVRnAeTee3WvPJwbrFR7L3Jk
x3OM1KeSni+YsAfBrLi7xag4IIt8alQ6cYww2/q1aFPrs6opl2ou6NLxM4ynxkV8
Gb2kqiwUVlf5QFUVJOoNeVwoiNelklUj5jGq3KZGqhq4OSC5fkcCtOsjOffWWD1Y
ACZL4aHrxUM/njHq8k+WBNocYtdmbFH8Iujzf27tsV8b0yIKGs6L5jjkFpSDQo+/
jiGafLVsddu9TeZr9Jm7OGo/u6q8ozCxaTg/G7fLF9DGrj1+AakN9sujxRgXkccI
znci5qPW0dzOzhVUcaVPDdhfv/O3RXbky2qMSk+uxB5drqJ7LbOkPVTbDadspla8
2oJw3OoWuR0uC0aK7eibuFlurms6CcG/UQYQv9cjS4wGVe44S6/wiUBjfJXT3ITo
rl38PcBigpF0XYWk2FAdE40xPN3REKv2Byulmjnc3ia2R+zBWuPg30LsQtFWgiwN
tYJ5n/J08Ek+gqA6lNX9pRKT8lq6RQgQrvir7d/9Zw+RGaaVB1EnBUJi49O0Sfqs
voFLstR1XnlhQubkhk5jhZ582Pug6K2H3b9sgU5ycTaWSEBr1B0AbvIetF5qO+pJ
Y/vT452Br2g6CKXSpS2y6wwcqC0e/dkB31uFl1s4fRUmGxmBXnK4GFu/ufjNzrgz
BFmF9HQWCSsGAQQB2kcPAQEHQIvVCKWPutMpY7ED7YDL8qev9tgCb5RSXPkzirJJ
WjDZiQKzBBgBCgAmAhsCFiEEeRDEX4n8jMLL0kqwrOVpcdVV2qUFAl6wGK8FCQhD
yzoAgXYgBBkWCAAdFiEElgyGKNWS/4zei7C/4OLe4dbI7voFAlmF9HQACgkQ4OLe
4dbI7vpdcAEA2GBaDiUbWapujHFGfh/a3MH1mXU/7Vrf+6aCBSoqwlABAOlljw5f
6gCnD6b8LjBIsS2W/U5jTtAt1aouzFDvhioICRCs5Wlx1VXapcvPD/0bteHRI4dW
3r4XqFKKVbKsc6gRaQRfUOZq3L0Pcadx0BoJorjnzCRY1KytAqyAjYH2ossd10Fm
MLL5RTkNBvdcWTD6ZKIJQICEu0o2BJcPzKXVB2pJNsHJSMQyhAqbgUKfnePJza+4
p80PL6eBWttufKcNtJwYgkTJhchKoa+Se2h2mt53v6jdIusKwM91dW+0U5E6Jkom
v3CKsSSsWIh8F5OpPJVz7/+2lThO2NOzLth762cV+yqsPGr9Dr9zsCkiIhRfr7hj
2L4AxO0ljYzd6FuR17WSvqHx3x2Sz8D2B5HxNQ0o6wxlnH3AlEti6/zSTtc0+AOx
nOTZwj/CPQrly4MP8fNbhjOVNoLcfyq4u2/HB843/IWv+S7rob6qHF3rJ49Ltl8+
nsUJ2JKBUue9L5RnEPgIHuuFwDXp9XRXoj0+s2W2N0IScpYFj0HRW9/0NV3pn+t3

Re: keys require a user-id

2020-05-20 Thread Werner Koch via Gnupg-users 
On Tue, 19 May 2020 10:29, Robert J. Hansen said:

> * PII-free UIDs are possible today

Well, according to European law this is not that easy because a public
key is in most cases an attribute which identifies a natural person.
This is the same as with phone numbers and mail addresses.  In Germany
even dynamically assigned IP addresses are attributes which can be used
to identify a person and thus are subject to GDPR.

OTOH, the GDPR does not forbid the use of this data, there are just
rules on how they can be used.  WP describes the basic rules as:

  Unless a data subject has provided informed consent to data processing
  for one or more purposes, personal data may not be processed unless
  there is at least one legal basis to do so. Article 6 states the
  lawful purposes are:

  (a) If the data subject has given consent to the processing of his or
  her personal data;

  (b) To fulfill contractual obligations with a data subject, or for
  tasks at the request of a data subject who is in the process of
  entering into a contract;

  (c) To comply with a data controller's legal obligations;
  
  (d) To protect the vital interests of a data subject or another
  individual;

  (e) To perform a task in the public interest or in official authority;

  (f) For the legitimate interests of a data controller or a third
  party, unless these interests are overridden by interests of the
  data subject or her or his rights according to the Charter of
  Fundamental Rights (especially in the case of children).

IMHO, point d covers the case of distributing and using a public key for
the purpose of securing the communication with the data subject.  The
key may of course not be used for any other purpose (i.e. tracking
behaviour etc).  Hacker be aware, the lay is not a machine, it works
different than we tend to assume.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keys require a user-id

2020-05-20 Thread Andrew Gallagher 
On 18/05/2020 07:14, Werner Koch via Gnupg-users wrote:
> Go readup on the failures and impracticalities of CRLs and OCSP.

While I agree that revocation is a Very Hard Problem, I'm not convinced
that its abandonment is warranted. Letsencrypt have sidestepped the
issue by issuing short-expiration certs and requiring users to
continually refresh. This is practical for servers under X509 (where
automation is easy and the trust model is centralised) but not for
hyper-distributed PGP. So while revocation cannot be entirely relied
upon, it's still better than nothing and I think we should continue to
support it as best we can.

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keys require a user-id

2020-05-20 Thread Andrew Gallagher 


> On 20 May 2020, at 06:32, Mark  wrote:
> 
> Just to test this out I tried creating a new key in Kleopatra with no
> name and then with just a single name and it would not let me do it. It
> had to have a first and at least a last initial.

This must be a Kleopatra limitation. I have successfully created IDs consisting 
of a single word using the gpg command line. 

Such a limitation would be user-hostile, as there are people in some cultures 
who have only one name, the Indonesian dictator Suharto being one famous 
example. 

A
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users