Re: changing the default for --keyid-format
On Tue, May 29, 2012 at 10:03:57PM -0400, Robert J. Hansen wrote: There may be a use case for contextualization in certificates, but if so I haven't found it yet. :) You may wnat to lookup up all certificates that signed a certificate. Or just get all your certificates displayed. Or all certificates that have been signed with your keys. But this is not to say that a tabular representation helps for these use cases :) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: changing the default for --keyid-format
On 05/30/2012 09:40 AM, Mark H. Wood wrote: Oh, how many times have I wondered why GPA has no search tool. Taking a look at GPA, it seems that 0.9.0 no longer compiles on a modern UNIX -- it expects libassuan-1.x, apparently, and libassuan's now in a version 2. I wasn't able to get the git checkout to work, either, due to a gettext infrastructure mismatch. The Makefile.in.in came from 0.17, but the autoconf macros on my system are from 0.18. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: changing the default for --keyid-format
On Wed, 30 May 2012 16:16, r...@sixdemonbag.org said: On 05/30/2012 09:40 AM, Mark H. Wood wrote: Oh, how many times have I wondered why GPA has no search tool. Taking a look at GPA, it seems that 0.9.0 no longer compiles on a modern UNIX -- it expects libassuan-1.x, apparently, and libassuan's now in a version 2. There is a new release: Noteworthy changes in version 0.9.2 (2012-05-02) * Adjust server mode to modern Libassuan. * Add options --enable-logging for W32. * Add options --gpg-binary, --gpgsm-binary and --debug-edit-fsm. * Properly process CMS data in the clipboard and with the server's VERIFY_FILES and DECRYPT_FILES commands. * Minor code cleanups. Noteworthy changes in version 0.9.1 (2012-04-18) * The key selection dialogs for encryption and signing do not anymore list expired, revoked or otherwise invalid keys. * If no recipients are given to the server, a generic key selection dialog is now used. * Now works with Libassuan 2.x. * The card manager now displays the ATR for an unknown card. 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: changing the default for --keyid-format [was: Re: getting an encrypted file to show what public key was used]
Am Di 29.05.2012, 11:51:06 schrieb Daniel Kahn Gillmor: I think switching the default to long would be on balance a Good Thing. A smaller change which should solve most of these problems could be to change the error message. If gpg is operating with the short format then a respective hint could be added: gpg is currently operation with short ID format. This prevents short ID collisions from being easily detected. You may want to run gpg with the option '--keyid-format long' to check the long IDs. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 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
Re: changing the default for --keyid-format [was: Re: getting an encrypted file to show what public key was used]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2012-05-29 17:51, Daniel Kahn Gillmor wrote: On 05/29/2012 11:35 AM, Werner Koch wrote: ... I think switching the default to long would be on balance a Good Thing. I agree, and don't see much of a reason not to use a long KeyID rather than a short one. However, please note that search for subkeys using the long keyID format is only supported in SKS since version 1.1.3 announced 11 April 2012 (lookup for parent/regular public keys is supported before that), so before implementing such a change I'd like to consider setting the minimum requirement for the SKS pool[0] to 1.1.3. Technically that is a rather easy change, however, it'd currently reduce the number of available servers to about 15 from 61 in the pool with min version requrement of 1.1.0 (current). So might have to give the keyserver administrators some time to upgrade before that. (cross posting to sks-devel) [0] http://sks-keyservers.net/status/ - -- - Kristian Fiskerstrand http://www.sumptuouscapital.com Twitter: @krifisk - Corruptissima re publica plurimæ leges The greater the degeneration of the republic, the more of its laws - This email was digitally signed using the OpenPGP standard. If you want to read more about this The book: Sending Emails - The Safe Way: An introduction to OpenPGP security is now available in both Amazon Kindle and Paperback format at http://www.amazon.com/dp/B006RSG1S4/ - Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJPxPWcAAoJEBbgz41rC5UIzLIQAIoftDYMBEl4N3MRO2ucrNt2 qG2t3xMTQlRv3hmf5mqqIYmK6zRvmKmjBdw7WPdIo83xY0+WBRiOSQEkSOM86Ed3 WhgYOlaNFNaPHrYB6v1yL6C9PkqXkv1IxFP8x12CjsfgnV5AWpQWDJIXHquD2C1K lbwX0+c/VnsN9LltBRvNqdrO/Le/HhVZyeMd6CoJYkp7aHdPCnmxsXi3DHqr78Bw FFP4ABWllE9RgAJN8ekvM7j8CedktwPXtkjGjoQw7+13p2xP3qd6E5ggTfFaHAQ5 HibxKBFZZmkcO3JSOmO7SF+63IKYPptu2uJ/p28ZFnExO+8HelU8m5iga+OXQqFC bw/qKbiWLcQxGMD2R+5ZyXOOCaJeg0vNwyt3YAGo09WJ7OJWYGne1A2h2vB/lxNS V09xjkNEbLQqQ1Kt1cLLZ5p/vxwrZ/136uyGhgmxX8gFVN9GBG31VymeV7pVqG11 21i0wqCW1KvW70b+D6vgQIxzTxUE1twc5suRi01bjDnAn0Kkl3mtZjPEI9kRRyfB W6+6zGtJgAr9AMPakAxhey39fTu8bS+dsRYS2ztrhhC/XfaxdreOrKpdKKqaUbEF zKddYjo+XarW27vubpCkIS3hnWd8nn/jBRuAwkKUC/qiSwvKKsvV8Y2FJt0FjLqI suwhmsLwpD1I5U0uMH6D =2Hk4 -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: changing the default for --keyid-format [was: Re: getting an encrypted file to show what public key was used]
On 5/29/12 11:51 AM, Daniel Kahn Gillmor wrote: Perhaps GnuPG should change the default of --keyid-format from short to long? Hurts interoperability. Once someone learns the process on PGP or BouncyCastle or [insert OpenPGP implementation here], they're going to want to take those same skills over to GnuPG. Those other implementations overwhelmingly display short key IDs; if they come to GnuPG expecting short key IDs and see long ones, we'll see a sea of questions of why did my key ID change when I imported it from PGP to GnuPG? (Hmm. Interoperability might be the wrong word, but there's not a good term for skill portability.) Anyway, it's not that I think this change is _a priori_ bad, but in order to diminish the skill portability issues (both in moving from other implementations to GnuPG and from GnuPG to other implementations) I think this change should not be implemented without some coordination with the other major implementations. Honestly, this seems like something to bring up to the IETF WG. The RFC already has a plethora of implementation recommendations: adding an implementation recommendation of use long key IDs when possible seems to be an entirely reasonable addition. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: changing the default for --keyid-format
On Tue, 29 May 2012 18:31, r...@sixdemonbag.org said: Honestly, this seems like something to bring up to the IETF WG. The RFC already has a plethora of implementation recommendations: adding an implementation recommendation of use long key IDs when possible seems I bet that this will immediately start a discussion on a v5 key format to fix this problem for “all” time. And obviously the suggestion will then be to show the full, then, SHA-256 fingerprint. Frontends should handle this problem. For example they could show all matching keys after a decryption problem. Hiding the keyID from the user would even be better - the mail address should be sufficient for 99% of all users. For the experts, a “Details” button can show all the glory details of the key. 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
Re: changing the default for --keyid-format
On 5/29/2012 10:18 AM, Werner Koch wrote: Hiding the keyID from the user would even be better - the mail address should be sufficient for 99% of all users. I use the e-mail address for almost all of my command-line work, FWIW. -- If you're never wrong, you're not trying hard enough ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: changing the default for --keyid-format
On 5/29/12 1:18 PM, Werner Koch wrote: Frontends should handle this problem. The problem is that most people developing front ends are making them pretty darn user-hostile. A few years ago while taking some HCI courses, I did a usability study on the most common certificate interface -- the tabular widget. It turned out to be just beyond-Godawful. rant follows Tabular data is the Right Thing To Do in two major use cases. The first is when you have a noninteractive display of identical field(s) for multiple pieces of data. Consider a printed almanac: if it wants to convey a list of countries and populations, the best way to do it is with a table. Different records (countries), identical fields (population), and since the paper is noninteractive, the table is a win. Now consider if instead of an almanac you have Wolfram Alpha. Typing population of Switzerland immediately yields *just* the data you want, and you don't get confused by your eye accidentally jumping a row and reading the population of Sweden instead. A table widget is more prone to misreadings. The second Big Win for tables is when data must be contextualized by other data. Consider a spreadsheet showing profits and losses for different divisions of a business: if all you know is that a given division made $X, you don't know if that's your most profitable division, your least profitable division, or what-have-you. The other data is necessary to put the data you're interested in into a larger context. Now consider the tabular widget as used in PGPkeys, GPA, the Enigmail key manager, etcetera. The certificates don't need to be contextualized: all the data necessary to evaluate a certificate is present in the same record as the certificate. And since it's a graphical application the interface can be interactive, which means the other major use-case isn't applicable here. Enigmail tries to have its cake and eat it too by prominently featuring a large search box at the top of the window. But this isn't a very good solution. In terms of screen real estate, about five-sixths of the screen is taken up by the tabular widget. The search box takes up a relatively small portion. The human eye tends to view large things as more important than small things -- so the center of attention is naturally drawn to the tabular widget, not the search box. Further, the human eye tends to view complex things as more important than simple things -- so the eye is drawn to the tabular widget again, not the search box. I'm grateful Enigmail has a search box in the certificate manager, but I doubt if new users even notice it. According to Google's HCI guys [2], 90% of the U.S. internet-using population doesn't know how to use Control-F to find a word in a document or a page. That's the level of skill most people have with user interfaces -- awful. And if you count up the number of widgets on the screen in your average certificate manager, you'll find that there's more visual complexity there than in Microsoft Word. /rant over Anyway. If people are interested in what I found out about effective user-interface design with respect to certificate managers, say the word. Otherwise I'll crawl back under my rock and leave the subject alone for another couple of years. :) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: changing the default for --keyid-format [was: Re: getting an encrypted file to show what public key was used]
On May 29, 2012, at 11:51 AM, Daniel Kahn Gillmor wrote: On 05/29/2012 11:35 AM, Werner Koch wrote: Use gpg --keyid-format long --decrypt sensitive_file.gpg to see the non-abbreviated key ID as stored in the file. Use this to find the key on a server, etc. i've seen a lot of these mistakes where people seem to think that 32-bit keyids are somehow collision-resistant. For example: https://lists.ubuntu.com/archives/uds-announce/2012-May/000234.html Perhaps GnuPG should change the default of --keyid-format from short to long? certainly, the 64-bit keyID itself is not as collision-resistant as the full fingerprint, but it does raise the bar for an attacker (and discourages users from just parrotting the 32-bit keyid if they don't understand what they're looking at). I think switching the default to long would be on balance a Good Thing. What do other people think? I think that it would bring more confusion than benefit, unfortunately. There is a significant amount of documentation (and even code) that uses OpenPGP in terms of 32-bit key IDs, and if that if we were to change, we'd cause all sorts of problems. Defaults should be conservative. That doesn't mean we can't start encouraging people to use 64-bit IDs, but I don't expect it to be a quick process. What is your concern here, though - accidental or intentional collision? David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: changing the default for --keyid-format
On May 29, 2012, at 1:18 PM, Werner Koch wrote: On Tue, 29 May 2012 18:31, r...@sixdemonbag.org said: Honestly, this seems like something to bring up to the IETF WG. The RFC already has a plethora of implementation recommendations: adding an implementation recommendation of use long key IDs when possible seems I bet that this will immediately start a discussion on a v5 key format to fix this problem for “all” time. And obviously the suggestion will then be to show the full, then, SHA-256 fingerprint. No doubt. V5 is a rather nice way to handle the problem: if a new key format came about, it's reasonable that the handle used to refer to it is different. Just like when things went from v3 to v4 and the fingerprint format changed, people understood that these were two different key types and accepted that they would appear different in a UI. I daresay that designing a V5 key format might even be accomplished sooner than rooting out all the (now-incorrect) FAQs and general knowledge of people using OpenPGP to get them to use 64-bit key IDs instead of 32. ;) David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: changing the default for --keyid-format [was: Re: getting an encrypted file to show what public key was used]
On Tue, May 29, 2012 at 1:47 PM, David Shaw ds...@jabberwocky.com wrote: On May 29, 2012, at 11:51 AM, Daniel Kahn Gillmor wrote: What is your concern here, though - accidental or intentional collision? Certainly both; while accidental collision isn't probable, 32-bit IDs aren't exactly collision resistant either. This, coupled with the fact that a nice GPGPU is now relatively inexpensive makes brute forcing collisions not only possible, but relatively easy for a determined attacker. —Sam -- Sam Whited pub 4096R/FB39BCF7EC2C9934 SamWhited.com s...@samwhited.com 404.492.6008 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: changing the default for --keyid-format [was: Re: getting an encrypted file to show what public key was used]
On May 29, 2012, at 2:05 PM, Sam Whited wrote: On Tue, May 29, 2012 at 1:47 PM, David Shaw ds...@jabberwocky.com wrote: On May 29, 2012, at 11:51 AM, Daniel Kahn Gillmor wrote: What is your concern here, though - accidental or intentional collision? Certainly both; while accidental collision isn't probable, 32-bit IDs aren't exactly collision resistant either. This, coupled with the fact that a nice GPGPU is now relatively inexpensive makes brute forcing collisions not only possible, but relatively easy for a determined attacker. The reason I bring it up is that using the v3 key attack, 64-bit key IDs have no particular benefit over 32-bit IDs for intentional collisions (i.e. an attacker generating a key with the same key ID as the victim in order to confuse matters and/or steal traffic). It's just as easy to forge 64 bits as it is to forge 32… David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: changing the default for --keyid-format
On Tue, 29 May 2012 19:44, r...@sixdemonbag.org said: Anyway. If people are interested in what I found out about effective user-interface design with respect to certificate managers, say the word. Otherwise I'll crawl back under my rock and leave the subject GPA has many different ways to show keys. IMHO the selection box which pops up in GPA, if run as a UI-server, can't figure out the key to use. I have always thought that this is better than the the standard GPA frontpage, which shows all keys; despite that the most common operation then is trying to locate the right key. A search box would make much more sense here. However, changing such a common UI might result in a lot of negative comments - people love what they once learned. Yes, I am interested in your findings. 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
Re: changing the default for --keyid-format [was: Re: getting an encrypted file to show what public key was used]
On 05/29/2012 02:18 PM, David Shaw wrote: The reason I bring it up is that using the v3 key attack, 64-bit key IDs have no particular benefit over 32-bit IDs for intentional collisions (i.e. an attacker generating a key with the same key ID as the victim in order to confuse matters and/or steal traffic). It's just as easy to forge 64 bits as it is to forge 32… Right, which is why gpg should default to not processing/accepting v3 keys either, frankly. The window for v3 being deprecated started long ago. If we expect people to rely on gpg for any sort of key management, it ought to have reasonably safe and sane defaults. dropping v3 unless explicitly overridden, and defaulting to displaying 64-bit keyids in the places where it must show keyids seems like it would be a reasonable choice. Yes, it might break compatibility with some existing docs. Those docs are likely to be out-of-date, and many of them may well encourage bad practices anyway to someone who doesn't understand what they're seeing. fwiw, i agree with Werner that we should avoid displaying keyids to users wherever we can -- they're not human-friendly identifiers. But if we're going to expose them, we should be exposing them in ways that at least make them somewhat collision-resistant. --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: changing the default for --keyid-format
On 5/29/12 3:23 PM, Werner Koch wrote: However, changing such a common UI might result in a lot of negative comments - people love what they once learned. Absolutely. The good news, though, is that (at least in the Free Software world) the 'market' is fragmented. No one particular key manager holds a dominant position. Off the top of my head there's Seahorse, Kgpg, GPA, the Enigmail key manager, and more. It's possible for a new entry to exist without offending the users who are already happy with the existing/dominant certificate management UI. They just won't use the new thing, that's all -- but new users may decide to use the better-designed interface. Yes, I am interested in your findings. The code we put together was a fairly straightforward UI mockup. One version was in Java (in a vain, misguided attempt at cross-platform support); after that I put together one in Python that directly targeted GNOME 2. It would need some work to overhaul it for GNOME 3 (and possibly a lot of work, given PyGTK has been deprecated in favor of a different kind of binding). That said, if you'll forgive me not having a mockup ready -- 1. The window was almost comically blank: ._. | Search for: | | +-+ | (room for a line of text, begins blank) | +-+ | (checkbox for 'Show all matches') | +-+ | | | | | (completely blank | | tabular widget)| | | +-+ In usability tests, people who already had experience with conventional key managers absolutely hated this arrangement. They wanted to see all the information at once. People who were new to OpenPGP were a little confused: they weren't accustomed to windows that were mostly blank, but they had no difficulty understanding that they needed to interact with the search box first. An early version of this allowed users to view all 1000+ certificates on the keyring by clicking the 'Show all matches' checkbox immediately. This turned out to be a negative experience for some users, who immediately felt overwhelmed by data. For this reason, the checkbox was originally set as insensitive: only once data was entered in the search box and the number of matches ranged between 1 and 50 did the checkbox become active. 2. As users typed things into the searchbox, the line of text would update. For instance, if the user typed 'T' the text would say something like, 55 certificates contain 'T'. At this point the user could click on the checkbox if he/she wished. People seemed to understand that they should keep typing, though. Once enough letters were entered to reduce the matches to under seven certs, the checkbox selected itself and the matching UIDs populated in the widget. And, of course, as soon as the matches went 50 the user could manually select the checkbox. 3. Typing 'RSA', 'DSA' and/or 'ELG' would further restrict keys. Nobody cared about this feature: it was completely unused. Likewise with = and/or = to restrict by key length. Nobody cared. In hindsight, this was a horrible misfeature -- what if someone's name contained 'rsa', 'dsa' or 'elg'? For instance, one of my classmates' email addresses was @thetiredsaint.com; had we used his certificate as one of our tests, I suspect people would have been driven up the wall by this misfeature (note the dsa in thetiredsaint). 4. Searching by a hex string was supported, so long as it was prefixed with 0x. 5. Multiple search terms were treated as logical-ANDs, not logical-ORs. People didn't want/use ORs: nobody wanted UIDs matching 'John' or 'Smith', they wanted UIDs matching 'John' and 'Smith' -- e.g., Bob Smith would match the first but not the second. 6. Once the tabular widget was displaying UIDs, clicking on a row in the UID would populate its key ID field. This further reduced the cognitive load on people: rather than see 10 UIDs and 10 key IDs (a widget count of 20 spread across two columns), there was a single column of 10 UIDs and, *if a row was selected*, a single key ID shown -- a widget count of 11. Some people liked this, some people absolutely hated it. The ones who hated it tended to be the more experienced computer users. 7. Upon clicking a UID, not only would the key ID field populate, but the line of text would instruct the user Double-click to view or edit this certificate. Upon double-clicking, congratulations, the mock-up ended -- the mock-up was only meant to test the ease of finding and selecting the desired certificate. Our testing was pretty rough. We had seven test subjects (a very small sample), one of whom was very
Re: changing the default for --keyid-format [was: Re: getting an encrypted file to show what public key was used]
On May 29, 2012, at 3:34 PM, Daniel Kahn Gillmor wrote: On 05/29/2012 02:18 PM, David Shaw wrote: The reason I bring it up is that using the v3 key attack, 64-bit key IDs have no particular benefit over 32-bit IDs for intentional collisions (i.e. an attacker generating a key with the same key ID as the victim in order to confuse matters and/or steal traffic). It's just as easy to forge 64 bits as it is to forge 32… Right, which is why gpg should default to not processing/accepting v3 keys either, frankly. The window for v3 being deprecated started long ago. If we expect people to rely on gpg for any sort of key management, it ought to have reasonably safe and sane defaults. While I don't think the world is ready for a change in default visibility from 32 to 64 bit key IDs, I am in favor of this by default. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: changing the default for --keyid-format
On Tue, 29 May 2012, Robert J. Hansen wrote: . . . Tabular data is the Right Thing To Do in two major use cases. The first is when you have a noninteractive display of identical field(s) for multiple pieces of data. Consider a printed almanac: if it wants to convey a list of countries and populations, the best way to do it is with a table. Different records (countries), identical fields (population), and since the paper is noninteractive, the table is a win. . . . The second Big Win for tables is when data must be contextualized by other data. Consider a spreadsheet showing profits and losses for different divisions of a business: if all you know is that a given division made $X, you don't know if that's your most profitable division, your least profitable division, or what-have-you. The other data is necessary to put the data you're interested in into a larger context. . . . In general, being able to examine variation of content within uniformity of structure is also a way to legitimate the specific content of interest. If someone feeds you just one answer Special, just for you!, you may feel happy and relaxed, but you missed the chance to see if the result you got makes sense compared to other results. The question of legitimation is actually a broad and significant issue. Referring to RJH's later long description of his work, might this kind of consideration be one possible factor in experts' liking tabular display more than newbies did? Context would mean more to people who know how to evaluate it. Eg seeing tabular output, they are always a little verifying the current correctness of how the server is working, and so on. If I understand RJH's description corectly, it seemed to me that the interface he described was presenting a combination of context and focus, including some user control over extent of context (possibly not effectively clued control, but that is not unusual for a pilot version of anything). ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: changing the default for --keyid-format
On 5/29/12 9:57 PM, reynt0 wrote: In general, being able to examine variation of content within uniformity of structure is also a way to legitimate the specific content of interest. As I said, it's useful when data must be contextualized. For a spreadsheet, the information in one row must be put in the context of information in other rows. This isn't the case for a certificate manager, though: each certificate is its own self-contained entity. Whether I have 500 RSA keys or 1 RSA key doesn't matter to me in the slightest: I just want to look at this *one particular* RSA key, etc. There may be a use case for contextualization in certificates, but if so I haven't found it yet. :) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
