From aegypten-issues at intevation.de Tue Feb 1 17:05:10 2005 From: aegypten-issues at intevation.de (Bernhard Herzog) Date: Tue Feb 1 17:01:17 2005 Subject: [issue298] document how to add root certificates to /etc/skel Message-ID: <1107273910.49.0.187108964617.issue298@intevation.de> New submission from Bernhard Herzog : The documentation of gnupg 1.9 is missing information on how to add root certificats to /etc/skel and how to add them to the truslist.txt there. The documentation mentions addgnupghome which can be used to copy /etc/skel/.gnupg to a user's home directory but doesn't say how to modify /etc/skel/.gnupg in the first place. ---------- assignedto: werner messages: 1919 nosy: bh, werner priority: bug status: unread title: document how to add root certificates to /etc/skel topic: gpgsm ______________________________________________________ Aegypten issue tracker ______________________________________________________ From aegypten-issues at intevation.de Thu Feb 3 20:54:57 2005 From: aegypten-issues at intevation.de (Ivo) Date: Thu Feb 3 20:51:05 2005 Subject: [issue300] failing to parse a certificate from ldap server Message-ID: <1107460497.16.0.181368220382.issue300@intevation.de> New submission from Ivo : I'm using ldap server: x500.gov.si base dn: o=state-institutions,c=si after searching (for example "Ivo List") i get the following error: 6 - 2005-02-03 20:53:39 dirmngr[7648]: DBG: cmd_lookup: returning one cert 6 - 2005-02-03 20:53:39 dirmngr[7648.0x8080290] DBG: -> D {ASN} 3082058e30820476a00302010202043b3d25e3300d06092a864886f70d0101050500303d310b3009060355040613027369311b3019060355040a131273746174652d696e737469747574696f6e733111300f060355040b1308736967656e2d6361301e170d3032313033303133353032345a170d3037313033303134323032345a307c310b3009060355040613027369311b3019060355040a131273746174652d696e737469747574696f6e733111300f060355040b1308736967656e2d636131143012060355040b130b696e646976696475616c733127300f0603550403130849564f204c49535430140603550405130d3234353639343135313230313230819f300d06092a864886f70d010101050003818d0030818902818100cd2ced8c11f86cea151cc14ebccea20b6a0ca7eee776d3475cbbfdfff50a583426b666e5f990868c4b3e4c3cff4edfeaa334fa142f4dae1de5afbc940536942785a7a4d9c0491ddced5607545261ac8862ce0766e6b9ce4e673d693a0d9f154bdcd0483bd46152558c95996ce903aa074c7d4d964f9ac533c0983c96313a95510203010001a38202d9308202d5300b0603551d0f0404030205a0302b0603551d1004243022800f32303032313033303133353032345a810f32303037313033303134323032345a301106096086480186f842010 6 - 2005-02-03 20:53:39 dirmngr[7648.0x8080290] DBG: -> D 10404030205a0302f06096086480186f84201020422162068747470733a2f2f7777772e736967656e2d63612e73692f6364612d6367692f304406096086480186f842010304371635636c69656e746367693f616374696f6e3d636865636b5265766f636174696f6e262643524c3d636e3d43524c332673657269616c3d305106096086480186f842010d0444164253706c65746e6f206b76616c696669636972616e6f206469676974616c6e6f20706f747264696c6f207a612066697a69636e65206f7365626520534947454e2d434130400603551d20043930373035060a2b06010401af590202023027302506082b060105050702011619687474703a2f2f7777772e676f762e73692f63612f6370732f30220603551d11041b3019811769766f2e6c6973744067756573742e61726e65732e73693081ef0603551d1f0481e73081e43054a052a050a44e304c310b3009060355040613027369311b3019060355040a131273746174652d696e737469747574696f6e733111300f060355040b1308736967656e2d6361310d300b0603550403130443524c33305da05ba05986576c6461703a2f2f783530302e676f762e73692f6f753d736967656e2d63612c6f3d73746174652d696e737469747574696f6e732c633d73693f63657274696669636174655265766f636174696f6e4c6 6 - 2005-02-03 20:53:39 dirmngr[7648.0x8080290] DBG: -> D 973743f62617365302da02ba0298627687474703a2f2f7777772e736967656e2d63612e73692f63726c2f736967656e2d63612e63726c301f0603551d23041830168014717b8a061f310555ab60127747201e038818ec89301d0603551d0e041604144fdd9ad79f669fc95ff4fd436fe69b83585b6e4f30090603551d1304023000301906092a864886f67d074100040c300a1b0456352e30030203a8300d06092a864886f70d010105050003820101005ee7f3eb7b3668faf0f96b58f7a5f56bc3a584059fa17771fefcf1fb830c6c62f9e417fd8fb3fa2e73ec64a3cb9bb0a0fd97563886ef04b65ad763527f515b546b5746d57a50b2558f06cd564ce6aef64fec6a765261a8d25f65baea250c744e084f21d346b3e4485e29173841428721dcf7f0efea13971a59c4af4cd3385876a34b8f47e3a3168c1a844d28806d7475e1d1a6ad854213e7a3c70809dcad24465b6ada28b269844bac31091486a3c830ab24193077ceca63edaf368f01f4faa31689496f666c17a60cc91f25c7af23e3cc7268ef3baf5f1a2b134033d48502eb6d1179e2af8ed4845c17da2aa46df0b2c685d6ac001331de9f710f1e2c8d007f00 6 - 2005-02-03 20:53:39 dirmngr[7648.0x8080290] DBG: -> END 4 - 2005-02-03 20:53:39 gpgsm[7647]: failed to parse a certificate: BER error The certificates are fetched from the server, but I can't idetify what the problem that follows is. It is possible that this ldap server uses somewhat strange form of certificates. ---------- messages: 1938 nosy: List priority: bug status: unread title: failing to parse a certificate from ldap server ______________________________________________________ Aegypten issue tracker ______________________________________________________ From wk at gnupg.org Thu Feb 3 21:18:39 2005 From: wk at gnupg.org (Werner Koch) Date: Thu Feb 3 21:15:43 2005 Subject: Patch for userSMIMECertificate In-Reply-To: <200501281249.04428.neil.dunbar@hp.com> (Neil Dunbar's message of "Fri, 28 Jan 2005 12:48:54 +0000") References: <200501281249.04428.neil.dunbar@hp.com> Message-ID: <87hdktbdnk.fsf@wheatstone.g10code.de> On Fri, 28 Jan 2005 12:48:54 +0000, Neil Dunbar said: > The dirmngr component doesn't attempt to fetch or parse userSMIMECertificate > attributes within entries while fetching from LDAP, so I've attached a diff > against 0.9.0 which adds the capability [Our directory stores > userSMIMECertificates to distinguish from our web client certificates]. I have started to work on it but didn't finished it due to other bugs I needed to track down first. As of now Libksba from CVS is able to parse your data. dirmngr/src/ldap.c has not yet enabled and finished code to handle userSMIMECertificates. Will continue work next week. Werner From aegypten-issues at intevation.de Sat Feb 5 12:56:23 2005 From: aegypten-issues at intevation.de (Errol Fuller) Date: Sat Feb 5 12:52:32 2005 Subject: [issue301] PIAGET CARTIER - Just Like the Real Thing - Louis Vuitton Omega Logines - 891790 Message-ID: <20530606390316.GK5386@enoch.org> New submission from Errol Fuller : u198A577 CARTIER PIAGET - Expensive Look Not Expensive Price - Logines Louis Vuitton Omega - 273624 Ya got to see this - http://downslope.icfbingknd.com/?btdJJgIEfMOjGbbnapoleon no more - http://awkward.akefbahj.com/dessert?NzjjjmieRSopghhaudubon H501i785 ---------- messages: 1941 nosy: freegis-list-request, great-er-bugs, patch, silke.reimer status: unread title: PIAGET CARTIER - Just Like the Real Thing - Louis Vuitton Omega Logines - 891790 ______________________________________________________ Aegypten issue tracker ______________________________________________________ From cludwig at cdc.informatik.tu-darmstadt.de Tue Feb 15 18:46:58 2005 From: cludwig at cdc.informatik.tu-darmstadt.de (Christoph Ludwig) Date: Tue Feb 15 19:41:19 2005 Subject: problems with mutt's gpgme setup In-Reply-To: <871xbianub.fsf@wheatstone.g10code.de> References: <20050126115002.GH4589@raktajino.does-not-exist.org> <20050127175406.GA4715@amelie.frognet.net> <20050127224021.GD4140@lap200.cdc.informatik.tu-darmstadt.de> <87y8ed51yd.fsf@wheatstone.g10code.de> <20050128131019.GC3505@lap200.cdc.informatik.tu-darmstadt.de> <20050211200127.GA20165@lap200.cdc.informatik.tu-darmstadt.de> <87vf8vea52.fsf@wheatstone.g10code.de> <20050214160810.GA11279@lap200.cdc.informatik.tu-darmstadt.de> <871xbianub.fsf@wheatstone.g10code.de> Message-ID: <20050215174657.GB2721@lap200.cdc.informatik.tu-darmstadt.de> This discussion started at the mutt-dev mailing list . I am taking it here since most of the problems I am dealing with right now seem to be GnuPG specific. > On Mon, 14 Feb 2005 17:08:11 +0100, Christoph Ludwig said [amended in order > to provide context]: > > If I instruct gpgsm to ignore CRLs then I get senseful signature information, > > all right. But I still have one Email where mutt shows me contradicting > > information: > > > > The signature information shows '*BAD* signature claimed to be from: > > [...]'. IIUC the corresponding root CA has no validity dates whence gpgsm ] > > rejects the certificate and - in consequence - the signature. (That behaviour > > is ok IMHO but I'd prefer if the signature information would tell me the > > reason of the rejection.) However, in mutt's status line I read 'S/MIME On Mon, Feb 14, 2005 at 09:27:56PM +0100, Werner Koch wrote: > We discussed this during kmail development over and over and the > outcome is that kmail has a buttun do check the certificates then. > Something similar should be done in Mutt too. Anyway, we won't be > able to present all things in detail and in a way understandable for > the average user - thus many situations may only be examined using the > log files. I appreciate your argument and I understand that you don't want to bury the important information underneath details most users are not interested in. But there should be an easy way from within the MUA to get to a log why the verification failed. Anyway, that issue is not that important for me. If I do not understand why gpgsm rejects a mail then I have the tools and knowledge to verify the signature step by step. I brought it up because it is IMO a usability issue for the average user. > > signature successfully verified'. That's confusing! > > Yes, it is. We are working on that. Note that there might even be > some messages it can't parse - please report those; we are going to > fix them. I have one such fix in CVS (for libksba) so with the next > gnupg 1.9 version more bugs will get squished out. OK, I will try it after its release. > > I don't want to leave the CRL checks disabled whence I need to figure out the > > problem with dirmngr. The only information I find in the log when verifying a > > good signature corresponding to a non revoked cert is > > Pleae update to dirmngr 0.9.1 - I fixed a bug which looks like yours. > > > Must the distribution point in the certificate be given in any particular > > format? (I am going to sign this message so anyone interested can have a look > > Well, LDAP and HHTP are supported. https is not really supported but > we try simply http instead, which surprisingly often works. > > > at the URI.) Or how can I find out *why* the ldap lookup failed? > > Add > > debug 2 > > to dirmngr.conf I installed dirmngr 0.9.1. Unfortunately, the problem persists. (I am going to attach a log to this mail.) dirmngr complains `no hostname in URL or query failed', even though the URI clearly contains a fully qualfied host. I already doublechecked that my iptables script does not block ldap requests. My coworkers confirmed that the ldap server is running. So I am a mystified why dirmngr cannot download the CRL. Has anyone here an idea what's wrong? > > I try to actually sign a message with the new key then I get an error that the > > secret key file was not found. The log does not show anything... :-( > > Sure that the public key is available and all certificates up to the > root? Try: > > gpgsm -k --with-validation user_ID_of_new_key > > The user Id is best specified using the fingerprint or the keyid > (last 8 hex digits); see README. You were right, there was indeed a problem with the certificate chain. There were two reasons why I didn't realize the problem: a) When I imported the PKCS#12 file I assumed my key / certificate pair was imported. But gpgsm imported the private key only. Is there a good reason why it ignores the certificates? I had to extract the certificate with openssl into a PEM file and import the certificate from the PEM file. I cannot imagine that you expect Joe Average User to do this. b) When I selected the certificate for the signature I was presented with the following choice: 1 x 1023/0x19442EB3 RSA es 2 x 1024/0xC1D60643 RSA es I happened to know that 0x19442EB3 was my old certificate. Since I just had imported the PKCS#12 file with my new key I erroneously assumed 0xC1D60643 to designate my new certificate. (In fact, it designates an old, long expired certificate that I had forgotten.) So I selected the latter certificate and wondered about the resulting error message. Because of (b) I have two requests: 1) I'd like to associate a string with each certificate that is printed in addition to the certificate ID. Then I could assign each certificate a meaningful label. 2) I want to be given a choice among *valid* certificates only when selecting a certificate for a signature. Over time, the expired / revoked certificates will accumulate. I cannot expunge them from the key / certificate store because I still need to be able to decrypt my old mails and verify old signatures. Do you have any objections? Are these requests feasible? Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg.log.gz Type: application/x-gunzip Size: 4705 bytes Desc: not available Url : /pipermail/attachments/20050215/b1a376b3/gnupg.log-0001.bin