View Issue Details

IDProjectCategoryView StatusLast Update
0000447Main CAcert WebsiteGPG/PGPpublic2013-01-14 21:44
Reporterpc Assigned ToSourcerer  
Status closedResolutionfixed 
Fixed in Version2007 
Summary0000447: You can have any arbitrary userid signed with the cacert root key
DescriptionThe underlying problem is that gpg.php checks only the first userid of each submitted key against the username + email addresses, but signs all contained userids in one go.

(Btw, I think the code for parsing the "gpg --with-colons" output is really horrible and needs a complete rewrite. Hint: don't rely on () and <> to identify comments and email addresses.)

This may be related to bug ids 0000258 + 0000246.
Additional InformationPoC:

Version: GnuPG v1.4.5 (GNU/Linux)



1. Create an ordinary key with gpg --gen-key and your real name + email address
2. use "gpg --edit-key keyid" to add one or more arbitrary userids
3. gpg -a --export keyid >key.asc
4. Check that "gpg --with-colons <key.asc" lists your real name + email as the first userid
4.1 If not, use "gpg --edit-key keyid" to delete + add userids and go back to step 3
5. Submit key.asc to to have it signed
6. Import the resulting signatures
7. Use "gpg --edit-key keyid" to remove the userid containing your real name
TagsNo tags attached.
Attached Files
gpgcheck.php (2,844 bytes)
gpgcheck2.php (2,847 bytes)
gpgcheck3.php (7,551 bytes)
Reviewed by
Test Instructions


related to 0000460 closedSourcerer Please disable GPG signing until we have a production-quality system 
related to 0000455 closed GPG key without E-mail address cannot be signed 
related to 0000258 closedSourcerer signs uids with unverified email addresses 



2007-09-27 18:34

reporter   ~0000889

For clarity, here's the output of gpg --list-sigs --with-colons for the above PoC key:

pub:e:1024:17:B653EF1DA2756B22:2007-07-20:2007-07-21::-:Harry Potter <>::sc:
sig:::17:B653EF1DA2756B22:2007-07-20::::Harry Potter <>:13x:
sig:::17:D2BB0D0165D0FD58:2007-07-20:2007-07-21:::CA Cert Signing Authority (Root CA) <>:10x:


2007-10-06 12:16

reporter   ~0000891

I've written a script that's supposed to check if and by whom the issue has been exploited. It must be put into the cacert/www directory (alongside gpg.php). I wasn't able to do much testing, because I didn't manage to set up a working cacert site on my machine.

My script constructs regular expressions from the user's name and email addresses for checking GPG user ids. I think that is a much simpler and cleaner approach than what gpg.php does.


2007-10-07 16:50

administrator   ~0000892

The script seems to miss the fact that the middle name is optional:
Firstname Lastname
Firstname Middlename Lastname
are both valid options.
Can you update that please?


2007-10-08 10:42

reporter   ~0000893

Modified the script to allow email-only uids


2007-10-18 14:12

reporter   ~0000894

Last edited: 2007-10-18 17:25

Please take a look at my report: Only UIDs with an email is not a solution but even unwanted as Philipp G├╝hring from the Cacert support team explained to me.

Edit: Clarified a bit - of course I meant email plus name.


2007-10-18 15:27

reporter   ~0000895

I talked to Philipp about that on IRC two weeks ago. I don't think email-only uids are a good idea, either, but the current implementation does allow them. The current implementation also requires an email address.

Part of the problem seems to be that there is no official documented (GPG-)keysigning policy of cacert.


2007-10-29 13:31

reporter   ~0000931

Why is the GPG-key signing feature disabled at the moment? When will it be re-enabled?


2007-10-29 13:51

developer   ~0000932

janst: See bug 460 (reasons why I requested GPG shutdown). It will be reenabled when there is favourable code audit, that the system presents no threat to the CAcert community.


2007-10-29 16:26

reporter   ~0000933

"Access denied" :-(


2007-11-12 15:55

reporter   ~0000946

Any news on the issue?


2007-11-17 13:57

administrator   ~0000948

The problem has been fixed. Please test and close the bug.


2007-11-22 13:20

reporter   ~0000959

Part of the problem is that the current code tries to parse the UID into name, comment and email address. However, that distinction is apparently only enforced by the gnupg executable. The openpgp specification defines the UID simply as UTF-8 encoded text. See RFC-4880

5.11. User ID Packet (Tag 13)

   A User ID packet consists of UTF-8 text that is intended to represent
   the name and email address of the key holder. By convention, it
   includes an RFC 2822 [RFC2822] mail name-addr, but there are no
   restrictions on its content. The packet length in the header
   specifies the length of the User ID.


2007-11-25 14:23

administrator   ~0000962

The security issue has been fixed, by changing the policy that only one email address is allowed per UID. Still we should try to sort out the question of allowing comments in the UID.


2007-11-30 08:09

reporter   ~0000963

I have improved the gpgcheck script in several ways:
- it treats GPG uids properly by unescaping UTF-8 characters
- it converts users' names and email addresses to UTF-8 before comparing it with the uids
- it replaces users' names and email addresses in uids with placeholders
- it applies simple transformations on non-ascii characters in users' names (using iconv + handmade replacements for german umlauts)
- it tries to match names and addresses case-sensitively first, then case-insensitively (requires php >= 5.2.0, activate by invoking gpgcheck3.php?case=1)
- it includes matching for initials (middle name, firstname, lastname)
- anything that doesn't match (fname( mname)? lname( suffix))?( \(.*\))?<?email>? plus non-empty comments, initials, mixed case and transcodings are reported as problematic
- results are presented as a UTF-8 encoded CSV file (columns are ID, problem codes, anonymized uid, original uid, names, email addresses)

I have tested the code with php 5.0.2 with mb_strings and iconv installed. This is my first attempt at handling multibyte strings with php, so please be gentle. :-)

Issue History

Date Modified Username Field Change
2007-07-20 18:17 pc New Issue
2007-09-27 18:34 pc Note Added: 0000889
2007-10-06 12:10 pc File Added: gpgcheck.php
2007-10-06 12:16 pc Note Added: 0000891
2007-10-07 16:50 Sourcerer Note Added: 0000892
2007-10-08 10:41 pc File Added: gpgcheck2.php
2007-10-08 10:42 pc Note Added: 0000893
2007-10-18 14:12 janst Note Added: 0000894
2007-10-18 15:18 pc Relationship added related to 0000455
2007-10-18 15:19 pc Relationship added related to 0000258
2007-10-18 15:21 pc Relationship added related to 0000246
2007-10-18 15:27 pc Note Added: 0000895
2007-10-18 17:25 janst Note Edited: 0000894
2007-10-24 04:15 evaldo Priority normal => high
2007-10-24 04:15 evaldo Severity block => major
2007-10-24 04:15 evaldo Status new => confirmed
2007-10-24 04:15 evaldo Projection none => minor fix
2007-10-24 04:15 evaldo View Status public => private
2007-10-24 05:16 evaldo Relationship added related to 0000460
2007-10-28 00:04 homer View Status private => public
2007-10-29 13:31 janst Note Added: 0000931
2007-10-29 13:51 evaldo Note Added: 0000932
2007-10-29 16:26 janst Note Added: 0000933
2007-11-04 17:41 Sourcerer Relationship deleted related to 0000246
2007-11-12 15:55 janst Note Added: 0000946
2007-11-17 13:57 Sourcerer Status confirmed => solved?
2007-11-17 13:57 Sourcerer Fixed in Version => production
2007-11-17 13:57 Sourcerer Resolution open => fixed
2007-11-17 13:57 Sourcerer Assigned To => Sourcerer
2007-11-17 13:57 Sourcerer Note Added: 0000948
2007-11-20 10:24 pc Status solved? => needs feedback
2007-11-20 10:24 pc Resolution fixed => reopened
2007-11-22 13:20 pc Note Added: 0000959
2007-11-25 14:23 Sourcerer Status needs feedback => solved?
2007-11-25 14:23 Sourcerer Resolution reopened => fixed
2007-11-25 14:23 Sourcerer Note Added: 0000962
2007-11-30 07:52 pc File Added: gpgcheck3.php
2007-11-30 08:09 pc Note Added: 0000963
2009-04-09 19:38 Sourcerer Status solved? => closed
2013-01-14 21:44 Werner Dworak Fixed in Version => 2007