Subject: openpgp card and basiccard RNG
Hello, Aparrently the OpenPGP card is based on BasicCard [1] and from the BasicCard FAQ [2] I read: For Enhanced BasicCards, the card has no hardware generator. The Enhanced BasicCards contain a unique manufacturing number which cannot be read from outside the card. The Rnd function uses this number to generate random numbers which are different for each card. For Professional and MultiApplication BasicCards, the random number is generated by use of a hardware random number generator. Does anybody know which version of BasicCard is used for the OpenPGP cards distributed by KernelConcepts.de? If it is the Enhanced version, does the use of a pseudorandom generator pose a security risk? In my opinion a (good) PRNG seeded properly under user control is no problem. If -as the FAQ seems to tell- it is primed during production, beyond user control, this implies that normal users have to fully trust the manufacturer. A malicious manufacturer would be able to completely break privacy based on the Enhanced BasicCard without the user being able to detect this. An instance is created here, deliberately and unnecessarily, which the user has to trust. This pattern smells like a backdoor mechanism to me. I would outrighly reject to use such a card. Cheers Michael Anders ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: making the X.509 infrastructure available for OpenPGP
On Wed, 5 Feb 2014 06:03, d...@fifthhorseman.net said: Werner recently (in message ID 87zjmv127f@vigenere.g10code.de) indicated his acceptance of a notation named extended-us...@gnupg.org with a value that can be set to bitcoin. Maybe the same notation We can do that as soon as gniibe has finihsed hist work. could be used to indicate s/mime-sign or s/mime-encrypt for these No problem. But name it cms-sign and cms-encrypt. CMS is used by S/MIME but can and is used standalone. Same as with OpenPGP and PGP/MIME. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: making the X.509 infrastructure available for OpenPGP
On Wed, 5 Feb 2014 04:15, mailinglis...@hauke-laging.de said: Wow. Does that mean that PGP can verify OpenPGP keys with X.509 certificates (in combination with a related OpenPGP certificate)? Or is this just a theoretical feature? IIRC, the PGP desktop client also integrated an IPsec client and thus they needed key management for IKE. Merging this into the PGP key manager was easier for them. Are there reasons (beside the obvious effort and work budget) for not having implemented this in GnuPG? Checkout GPA, Claws, Kleopatra, GpgOL, or GpgEX - they integrate it. In general it does not make sense to use the same key - there is no advantage. For smartcards this is a different story, though. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Scute and SmartCard insertion/removal in Firefox
Hi, I use the GnuPG card and have installed all the software, including Scute. I configured a server for HTTPS asking for client certificates. When the card is inserted before requesting the page, I get a request for the user PIN for the card, and then the certificate is exchanged with the server as desired, and everything works fine. When the card is not inserted, my web application detects that no certificate has been sent and shows a login-failed message. If I then insert the card and reload the page, the card is not accessed and login still fails. I actually have to terminate and restart Firefox for it to use the card (shift-click on reload does not work either). Ideally, I would like to be logged out when I remove the card and logged in when I insert the card. Mozilla provides an unofficial JavaScript object to detect card insertion/removal (https://developer.mozilla.org/en-US/docs/JavaScript_crypto). The JavaScript code detects successfully insertion and removal of the card. Using mozilla's example script, when I remove the card, the page is reloaded, but displays an error message. I can probably hide the error message by verifying the connection in the background (AJAX) or reloading the page with a delay. However, when I insert the card, the page is still reloaded but the client certificate is not used. Is there a way to reload a page and explicitly request that the SmartCard be accessed? Or do you have any suggestions for a work-around? Sincerely, Urs ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Scute and SmartCard insertion/removal in Firefox
If you have a web server *and* a client where you can control the session cache and initiate a re-negotiation, Firefox will try to look at your token again. At least this was the case a while ago. -- Martin +372 515 6495 On Wed, Feb 5, 2014 at 12:58 PM, Urs Hunkeler u...@gmx.ch wrote: Hi, I use the GnuPG card and have installed all the software, including Scute. I configured a server for HTTPS asking for client certificates. When the card is inserted before requesting the page, I get a request for the user PIN for the card, and then the certificate is exchanged with the server as desired, and everything works fine. When the card is not inserted, my web application detects that no certificate has been sent and shows a login-failed message. If I then insert the card and reload the page, the card is not accessed and login still fails. I actually have to terminate and restart Firefox for it to use the card (shift-click on reload does not work either). Ideally, I would like to be logged out when I remove the card and logged in when I insert the card. Mozilla provides an unofficial JavaScript object to detect card insertion/removal (https://developer.mozilla.org/en-US/docs/JavaScript_crypto). The JavaScript code detects successfully insertion and removal of the card. Using mozilla's example script, when I remove the card, the page is reloaded, but displays an error message. I can probably hide the error message by verifying the connection in the background (AJAX) or reloading the page with a delay. However, when I insert the card, the page is still reloaded but the client certificate is not used. Is there a way to reload a page and explicitly request that the SmartCard be accessed? Or do you have any suggestions for a work-around? Sincerely, Urs ___ 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: Scute and SmartCard insertion/removal in Firefox
Dear Martin, Thanks a lot for your help. It works now! After you pointed out re-negotiation, I first tried to find a way to dynamically request TLS renegotiation from the server (apache tomcat). All I could find is people thinking that this is a bad idea. I still think it makes sense in the given example, but I couldn't figure out how. However, while looking for information I came across a page where somebody had a very similar issue and uses the JavaScript logout function (window.crypto.logout(), not everywhere available but at least it exists in Firefox). This will request the client to forget about sessions and renegotiate the connection, which is exactly what I need. Cheers, Urs On 02/05/2014 04:15 PM, Martin Paljak wrote: If you have a web server *and* a client where you can control the session cache and initiate a re-negotiation, Firefox will try to look at your token again. At least this was the case a while ago. -- Martin +372 515 6495 On Wed, Feb 5, 2014 at 12:58 PM, Urs Hunkeler u...@gmx.ch wrote: Hi, I use the GnuPG card and have installed all the software, including Scute. I configured a server for HTTPS asking for client certificates. When the card is inserted before requesting the page, I get a request for the user PIN for the card, and then the certificate is exchanged with the server as desired, and everything works fine. When the card is not inserted, my web application detects that no certificate has been sent and shows a login-failed message. If I then insert the card and reload the page, the card is not accessed and login still fails. I actually have to terminate and restart Firefox for it to use the card (shift-click on reload does not work either). Ideally, I would like to be logged out when I remove the card and logged in when I insert the card. Mozilla provides an unofficial JavaScript object to detect card insertion/removal (https://developer.mozilla.org/en-US/docs/JavaScript_crypto). The JavaScript code detects successfully insertion and removal of the card. Using mozilla's example script, when I remove the card, the page is reloaded, but displays an error message. I can probably hide the error message by verifying the connection in the background (AJAX) or reloading the page with a delay. However, when I insert the card, the page is still reloaded but the client certificate is not used. Is there a way to reload a page and explicitly request that the SmartCard be accessed? Or do you have any suggestions for a work-around? Sincerely, Urs ___ 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: making the X.509 infrastructure available for OpenPGP
That is not what I suggest. You can assign certification trust to any key. Why should this of all keys not be done with certain CA keys? Ah, I had missed that nuance a bit, sorry. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: making the X.509 infrastructure available for OpenPGP
On 05/02/14 11:23, Werner Koch wrote: In general it does not make sense to use the same key - there is no advantage. I could think of /a/ reason to do it. You could leverage existing X.509 certifications by CAs to verify key validity in the OpenPGP world. An X.509 certification obviously certifies that a certain X.509 certificate belongs to the person or role identified by the Distinguished Name. But seen a bit differently, it certifies that that Distinguished Name has control over the key that is in the certificate. If that same key is used as an OpenPGP key, it follows that that same Distinguished Name has control over that key. So you could create a hybrid model: I assign trust to a specific CA. That CA has issued a certificate with DN XYZ. In my public OpenPGP keyring, there exists a key with a UID XYZ, and that public key has the same raw key material as the certificate. A key manager that manages both types of keys can now in fact infer that UID XYZ is validated by that CA. This approach doesn't change anything about the format of certificates in either X.509 or OpenPGP, it simply matches raw key material and DN's to UID's, and infers a measure of validity from it. Since OpenPGP UID's are usually not in the same format as DN's, people need to explicitly create such a UID to support this kind of validity inference. For a better user experience, it might be useful if frontends could work with the DN format, so such a UID is considered when matching on an e-mail address. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: making the X.509 infrastructure available for OpenPGP
On 02/05/2014 01:04 PM, Peter Lebbing wrote: So you could create a hybrid model: I assign trust to a specific CA. That CA has issued a certificate with DN XYZ. In my public OpenPGP keyring, there exists a key with a UID XYZ, and that public key has the same raw key material as the certificate. A key manager that manages both types of keys can now in fact infer that UID XYZ is validated by that CA. This approach doesn't change anything about the format of certificates in either X.509 or OpenPGP, it simply matches raw key material and DN's to UID's, and infers a measure of validity from it. Since OpenPGP UID's are usually not in the same format as DN's, people need to explicitly create such a UID to support this kind of validity inference. For a better user experience, it might be useful if frontends could work with the DN format, so such a UID is considered when matching on an e-mail address. If you're interested in this sort of hybrid approach, please take a look at the monkeysphere validation agent's msva-perl git repository, which contains a perl script openpgp2x509 : git://git.monkeysphere.info/msva-perl I also have rather half-baked code called 2ca that operates a minimalist dual-stack certificate authority which creates certificates in both OpenPGP and X.509 forms. In particular, it takes an OpenPGP certificate, certifies selected User IDs on it, and then produces an X.509 certificate derived from the relevant key (or subkey) based on the User ID and key usage flags: git://lair.fifthhorseman.net/~dkg/2ca I'd welcome patches or suggestions or fixes. Please don't try to deploy this in any sort of production environment without understanding it fully and thinking it through. If you want to follow up in detail about these projects, and if Werner feels it's off-topic for this list, followup on the Monkeysphere development list would be fine: Monkeysphere Developers monkeysph...@lists.riseup.net Regards, --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: making the X.509 infrastructure available for OpenPGP
On Wed, 5 Feb 2014 19:04, pe...@digitalbrains.com said: An X.509 certification obviously certifies that a certain X.509 certificate belongs to the person or role identified by the Distinguished Name. But seen a Almost all X.509 certification in public use certify only one of two things: - Someone has pushed a few bucks over to the CA. - Someone has convinced the CA to directly or indirectly issue a certificate. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: making the X.509 infrastructure available for OpenPGP
On 02/05/2014 03:06 PM, Werner Koch wrote: Almost all X.509 certification in public use certify only one of two things: - Someone has pushed a few bucks over to the CA. - Someone has convinced the CA to directly or indirectly issue a certificate. To further clarify: Domain Validation (how the overwhelming majority of cartel-issued X.509 certificates are verified today) nominally consists of proving that you can read e-mail sent to any of: * the e-mail addresses associated with the domain in question (as found in whois), or * any of a set of administrator e-mail addresses in the domain, including hostmas...@example.org, webmas...@example.org, ad...@example.org, sslad...@example.org, postmas...@example.org, etc. In practice, this means that any of the following can get a certificate issued: * anyone who can spoof whois to the CA * anyone who can spoof DNS to the CA (changing the MX record) * any mail system administrator who has access to any of the above e-mail addresses * any passive sniffer of outbound e-mail traffic from the CA's MTA if the CA doesn't enforce STARTTLS for outbound SMTP. * if the CA enforces STARTTLS for outbound SMTP, but doesn't check certificates: any active attacker in control of the CA's MTA's network connection (or anywhere between the CA and the receiving MTA) * anyone who knows the password to any of these e-mail accounts and so on... Remember also that (barring certificate pinning or TACK), someone who wants a cert does not have to attack a single CA -- they only have to attack the most sloppily-administered CA in all the public root stores. The bar for regular X.509 certification is much much lower than pretty much any common OpenPGP certification guideline. --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: making the X.509 infrastructure available for OpenPGP
On 05/02/14 21:06, Werner Koch wrote: Almost all X.509 certification in public use certify only one of two things: I never intended my message to say I would trust any CA. Hauke was looking for a way to leverage trust in a CA; I was merely contributing something I thought he might find interesting. By the way, I still think the CA certifies that the certificate belongs to the person or role identified by the DN. The problem is that when someone vouches for the truth of something, that doesn't make it an actual fact. It sometimes means the certifier is simply sloppy or a liar. Certification is a statement, not truth. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: making the X.509 infrastructure available for OpenPGP
Am Mi 05.02.2014, 11:23:24 schrieb Werner Koch: In general it does not make sense to use the same key - there is no advantage. I think that is not correct. It is today but not from the perspective of my proposal. a) If a CA uses the same key in both formats then we can get the advantage which I have explained first: Enabling an X.509 CA to make useful OpenPGP certifications. b) If normal users convert their X.509 certificate to OpenPGP then the respective CA could automatically create a signature for it as Peter has explained. I didn't think of that when starting this thread. Some detail questions arise: Which keys shall be the same? Doesn't make sense to demand that an X.509 key is the same like an OpenPGP offline mainkey. Doesn't make sense to demand avoiding offline mainkeys, too. So the best way would probably be to require just a subkey to be the same. I assume the current conversion tools are not capable of that yet but that would not be a problem for long. In most cases being reachable via both standards is an advantage. That is valid for both current OpenPGP-only users and S/MIME-only users. c) The other way round – an OpenPGP certificate is converted to X.509 – would probably affect less people but would have the analogous advantage like the one above: If somebody uses OpenPGP only and gets a certification by an X.509 CA for it (made possible by (a)) then he could open his communication to the S/MIME world easily if the CA offers to certify the same key in both formats. In the S/MIME world this would have an advantage (for the contacts of this user) over getting an independent certificate because (only) the OpenPGP version probably has more certifications than just the one by the CA so the authenticity becomes more probable. That is a less radical version of dkg's remark: Using OpenPGP's certification capabilities in the S/MIME world. Nobody would be forced to trust any CA. The CA problems would be avoided. But the one single important argument for using S/MIME would be destroyed. I believe that the OpenPGP community must be interested in getting this argument – ease of use (with respect to key verification) – out of the way. More or less the whole official German computer science community at the universities is preaching S/MIME for exactly this reason: a) The DFN offers X.509 service only. b) The Fakultätentag Informatik has published a statement about a crypto culture at the universities after Snowden: http://www.ft-informatik.de/uploads/tx_sbdownloader/Resolution_SicheresNetz.pdf c) The GI (Gesellschaft für Informatik) is preparing a very similar statement. A CS professor at Berlin's biggest university (more or less the biggest one in Germany) has even told me that he doesn't want me to organize OpenPGP courses there! That is the situation. Does anyone here dare claim that we can get the majority of the people to use crypto (read: OpenPGP) without the help of the universities? That we can get the schools teach OpenPGP if the universities manage to make most crypto-using students use S/MIME? From the perspective of spreading OpenPGP it seems quite dangerous to me to ignore the CAs (for political reasons or whyever). Of course, using OpenPGP does not morally oblige someone to help spread it. But I think it would be fair not just to say something like I don't care about CAs but to add I don't care whether OpenPGP or X.509 gets the new crypto users. Of course, someone could both not care about CAs and be interested in spreading OpenPGP but that attitude would rise some very interesting questions. Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
