Re: PGP kerserver infrastructure
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 30 Jun 2000, Michael Helm wrote:
"L. Sassaman" writes:
X.509 is a much older and cruftier standard. PGP is recognised by most to be the superior method for handling email and file encryption and signing. X.509 is designed to satisfy situations where there is a complex heirarchy in an X.500 setting.
I don't know about the first claim; PGP certainly developed partly in response to PEM, which was based on hierarchies. Which standard is better I think is up to customers to decide.
I think customers *have* decided. Where is PEM now? (And Phil Z. wasn't aware of the existance of PEM until very shortly before he released PGP, btw.) - --Len. __ L. Sassaman System Administrator | Technology Consultant | "Common sense is wrong." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Practical C Programming -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5XcDFPYrxsgmsCmoRAgEYAJ9Lhxvy2v1Pm6BWMqOEdCz04shIswCg8nBT A7xQbEKRW8/ZFr3vGc/I5Qs= =RJ5B -----END PGP SIGNATURE-----
L. Sassaman Sent: Saturday, July 01, 2000 2:58 AM
On Fri, 30 Jun 2000, Michael Helm wrote:
"L. Sassaman" writes:
X.509 is a much older and cruftier standard. PGP is
I think is up to customers to decide.
I think customers *have* decided. Where is PEM now?
PEM is being used on every ecommerce site site now, to implement SSL. Where have you been? Show me a site being secured with PGP, please. These same certs can, and are, used to protect email content, it's called S/MIME. Please show where this doesn't work. There is a working PKI for X.509 that operates at commercial production levels. Further, third-party online auth, via TLS, is also built into the system (PGP doesn't do that). It works and lives now. As far as customer acceptance goes, they don't want to deal with two dfferent encryption systems when one will do the job. They already are used to SSL via their ecommerce activity. Getting the same type of encryption for their email reduces their pain. Ergo, your statement doesn't float. Please provide evidence to the contrary. You should know that I've been trying to get PGP accepted for years. I've given up. That dog won't hunt. Customers couldn't grasp the difference between client-side SSL certs (SecureWebMail [TM MHSC]) and PGP, for the exact same email over POP3. Everyone of them demanded to be able to use the same cert for both. 2000 users out of 3500 all said the same thing here. This is from our SecureWebMail beta, last year. This gets even worse when doing SSL/POP3. Using a different cert (X.509) for the SSL auth and encrypting the content (PGP) is both useless and stupid. It also makes key management unbelieveably complex. Since I can't get PGP to work with SSL and I CAN get X.509 to encrypt message content, guess which drops out the door. In case you haven't figured it out yet, it's an integration issue, not strictly a technnical one.
2000-07-01-11:37:00 Roeland M.J. Meyer:
PEM is being used on every ecommerce site site now, to implement SSL.
Huh? X.509 certs and SSL are used, but certainly not PEM or S/MIME. I've never, as far as I know of, seen a working PEM implementation, or piece of PEM traffic. It's so lost in the noise I really thought it was completely dead until this thread popped up. PGP is used all over the place. TLS (nee SSL) has its uses, that's sure, and once the RSA patent expires I expect to be using it a lot more, but TLS has nothing to do with PEM, nothing even in common other than a cert format, and reformatting certs is no biggie. The real difference between the two is that S/MIME is based on the model of creating and subsidizing an artificial monopoly for the CAs, while PGP is not. Unless you're a CA, it's an easy choice:-). -Bennett
Bennett Todd: Saturday, July 01, 2000 11:51 AM
2000-07-01-11:37:00 Roeland M.J. Meyer:
PEM is being used on every ecommerce site site now, to implement SSL.
Huh? X.509 certs and SSL are used, but certainly not PEM or S/MIME.
I've never, as far as I know of, seen a working PEM implementation, or piece of PEM traffic. It's so lost in the noise I really
Uhmmm, >disconnect<, I was talking about the certs, not the protocol. thought
it was completely dead until this thread popped up.
PGP is used all over the place.
TLS (nee SSL) has its uses, that's sure, and once the RSA
So is S/MIME. Every Outlook MUA does it. There's a whole lot more outlook running out there than most anything else, except Netscape Messenger. patent
expires I expect to be using it a lot more, but TLS has nothing to do with PEM, nothing even in common other than a cert format, and reformatting certs is no biggie.
The real difference between the two is that S/MIME is based on
model of creating and subsidizing an artificial monopoly for
As I said above, I was discussing the cert format. After all PGP is not a protocol and SSL is. Using the same certs for both simplifies life. BTW, there are only a few months left on the RSA patent. Ergo, it's as good as not there, for current planning purposes. IOW, irrelevent. the the
CAs, while PGP is not. Unless you're a CA, it's an easy choice:-).
Patently not true. Anyone can instantiate a CA. No one is telling you that you can't. In fact, most of MHSC clients instantiate their own internal CA (at our urging), rather than use the commercial CAs. It's not much of a monopoly when you can do that. OpenCA opens the doors for that sort of thing, even further. Also, subsidy implies some sort of cash flow, where is it? Did you know that every copy of MS-IIS includes free working CA software? That doesn't do the CA "monopoly" much good, does it? It's right there, in the options pack for WinNTserver4SP5. Please forgive my response, I see this type of mis-use of the "monopoly" and "subsidy" emotive buttons all the time, on the domain policy lists. Usually by reactionaries that try to win the emotional argument over the substantive one. I wasn't expecting it here. It irritates me.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 1 Jul 2000, Bennett Todd wrote:
The real difference between the two is that S/MIME is based on the model of creating and subsidizing an artificial monopoly for the CAs, while PGP is not. Unless you're a CA, it's an easy choice:-).
And to expound upon this a little, CAs have artificially set PGP up as a competitor to their existance. CAs could easily embrace PGP and offer PGP services along with S/MIME and TLS. They choose not to, since PGP makes CAs optional (not obsolute, however). - --Len. __ L. Sassaman System Administrator | Technology Consultant | "Common sense is wrong." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Practical C Programming -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5XmYePYrxsgmsCmoRAp6XAKDxrD/7+PtsJ5Rl052e950ANzsJSQCfSdDd MlOz4dvqcSfG/BUtyjdbHMg= =5Oy7 -----END PGP SIGNATURE-----
L. Sassaman: Saturday, July 01, 2000 2:44 PM
On Sat, 1 Jul 2000, Bennett Todd wrote:
The real difference between the two is that S/MIME is based on the model of creating and subsidizing an artificial monopoly for the CAs, while PGP is not. Unless you're a CA, it's an easy choice:-).
And to expound upon this a little, CAs have artificially set PGP up as a competitor to their existance. CAs could easily embrace PGP and offer PGP services along with S/MIME and TLS. They choose not to, since PGP makes CAs optional (not obsolute, however).
First, I should state that I am NOT a Verisign fan. Quite the opposite. However, commercial CAs don't have a lock on being CAs. Ergo, monopoly issues do not apply here. In fact, most uses of a CA, within an organization, are in the line of validating that the user belongs to that organization, or is associated somehow (ie. extra net access). There is no need for such an org to pay for a commercial cert as they can be their own CA. This is much like what randy is proposing for NANOG folks. NANOG, actually merit, could fire up such a CA and NANOG folk could use it. A common key format would allow certs to be issued for SSL as well as S/MIME uses. OpenSSL actually allows you to generate a key/CRL/etc that works both for S/MIME and SSL. The CA software is also open-sourced via OpenCA. Now there may be issues of taste, with not wanting to run a CA based on perl scripts. But the fact of the matter is that the population of NANOG would not stress such a system, even on a 486 Linux box. There is even a perl compiler that works with mod_perl.
On Sat, Jul 01, 2000 at 02:43:51PM -0700, L. Sassaman wrote:
And to expound upon this a little, CAs have artificially set PGP up as a competitor to their existance. CAs could easily embrace PGP and offer PGP services along with S/MIME and TLS. They choose not to, since PGP makes CAs optional (not obsolute, however).
Thawte, in fact, does. They only support RSA, however.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 1 Jul 2000, Shawn McMahon wrote:
On Sat, Jul 01, 2000 at 02:43:51PM -0700, L. Sassaman wrote:
And to expound upon this a little, CAs have artificially set PGP up as a competitor to their existance. CAs could easily embrace PGP and offer PGP services along with S/MIME and TLS. They choose not to, since PGP makes CAs optional (not obsolute, however).
Thawte, in fact, does. They only support RSA, however.
Thawte does not support PGP in any context other than their Freemail "Web of Trust" program, and they have implemented PGP support incredibly poorly (to the point that their signatures mean absolutely nothing and are completely untrustworthy). Check the UKCrypto archives from Jan/Feb this year for a conversation I had with Mark Shuttleworth regarding this. Also, ask yourself... do you really think that Verisign is going to have Thawte continue with the PGP support, now that it owns them? __ L. Sassaman System Administrator | Technology Consultant | "Common sense is wrong." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Practical C Programming -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5YOihPYrxsgmsCmoRAgSgAKCDGFjK1rkWwdy19WyiSg1VjC8vKwCcCjXj 5TmE1b0QRnaTm2hoNuJmkPs= =E3Rq -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 1 Jul 2000, Roeland M.J. Meyer wrote:
L. Sassaman Sent: Saturday, July 01, 2000 2:58 AM
On Fri, 30 Jun 2000, Michael Helm wrote:
"L. Sassaman" writes:
X.509 is a much older and cruftier standard. PGP is
I think is up to customers to decide.
I think customers *have* decided. Where is PEM now?
PEM is being used on every ecommerce site site now, to implement
Privacy Enhanced Mail != Secure Socket Layer. And this discussion is becoming absurd... I regret getting baited into a flame war, and will not continue down this line of discussion. __ L. Sassaman System Administrator | Technology Consultant | "Common sense is wrong." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Practical C Programming -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5XmDhPYrxsgmsCmoRAgUwAKDuBDWIiX7mEAhpQx4Or2ytPLw1cgCg2Xug ycrobrrhkw0sWJaZTmv7MRk= =7fuO -----END PGP SIGNATURE-----
L. Sassaman : Saturday, July 01, 2000 2:22 PM
On Sat, 1 Jul 2000, Roeland M.J. Meyer wrote:
L. Sassaman Sent: Saturday, July 01, 2000 2:58 AM
On Fri, 30 Jun 2000, Michael Helm wrote:
"L. Sassaman" writes:
X.509 is a much older and cruftier standard. PGP is
I think is up to customers to decide.
I think customers *have* decided. Where is PEM now?
PEM is being used on every ecommerce site site now, to implement
Privacy Enhanced Mail != Secure Socket Layer. And this discussion is becoming absurd... I regret getting baited into a flame war, and will not continue down this line of discussion.
I am talking about PEM formatted keys and certs (*.pem files), as formatted by OpenSSL. I don't recogise your definition of the acronym. Me may have a case of operator over-loading here. I'm also sorry that you feel that this has become a flame-war. Maybe it is good that we terminate it.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 1 Jul 2000, Roeland M.J. Meyer wrote:
I am talking about PEM formatted keys and certs (*.pem files), as formatted by OpenSSL. I don't recogise your definition of the acronym.
PEM (RFC 1421-1424, I believe) was a *really sucky* attempt at a secure email standard. It was based on X.509, and did things like not allow encrypted but not signed messages, messages were encrypted, then signed, and the signer could not conceal his identity... and a whole bunch of other stupid things. (My apologies to some of my coworkers, who were involved with the PEM project). I don't think it ever was used outside of government and a few big corporations. Sort of like S/MIME, though S/MIME fixes a lot of the obvious flaws that PEM had.
Me may have a case of operator over-loading here. I'm also sorry that you feel that this has become a flame-war. Maybe it is good that we terminate it.
Well, a PEM vs. PGP debate might have interested me in 1992, but it's over with. PGP won, by the consensus of the users. Likewise, I suspect S/MIME will fail, due to lack of usage. S/MIME might be supported by every email client out there (though I do hear that compatability is nearly impossible between vendors), but if people don't use it, then it is just code bloat and should be excised. But this is a topic that people will get very religious about, and won't result in any constructive outcome... so I am content to stop ranting now and let natural selection take its course. __ L. Sassaman System Administrator | Technology Consultant | "Common sense is wrong." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Practical C Programming -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5XmmwPYrxsgmsCmoRAkiWAKDMV/bgKyvLtGyYX4KKlSb6HcdYgACgqea/ xMFrD8Q6vVbZkix7xrCjR1Y= =FM7m -----END PGP SIGNATURE-----
L. Sassaman: Saturday, July 01, 2000 2:59 PM
On Sat, 1 Jul 2000, Roeland M.J. Meyer wrote:
I am talking about PEM formatted keys and certs (*.pem files), as formatted by OpenSSL. I don't recogise your definition of the acronym.
PEM (RFC 1421-1424, I believe) was a *really sucky* attempt at a secure email standard. It was based on X.509, and did things like not allow
Ah yes, now I remember. I agree with your value-judgement.
Me may have a case of operator over-loading here. I'm also sorry that you feel that this has become a flame-war. Maybe it is good that we terminate it.
Well, a PEM vs. PGP debate might have interested me in 1992, but it's over with. PGP won, by the consensus of the users.
Likewise, I suspect S/MIME will fail, due to lack of usage. S/MIME might be supported by every email client out there (though I do hear
Even in 1992, I wouldn't have been interested in that debate. PEM obviously doesn't fit the requirements. that
compatability is nearly impossible between vendors), but if people don't use it, then it is just code bloat and should be excised.
The thing is that folks ARE using it. Just, not in public.
But this is a topic that people will get very religious about, and won't result in any constructive outcome... so I am content to stop ranting now and let natural selection take its course.
That may or may not be true. Letting things sink to common terms, we have been discussing S/MIME vs PGP, via PKI debate. What sort of PKI would be most useful for NANOG participants? My contention is for OpenSSL style CA that issues certs usable for both S/MIME and SSL. In addition, I have a project that would let SSH use *.pem files from OpenSSL, issued by OpenCA. What we would have then is a single Key/Cert that would work with SSH, S/MIME, and SSL. I can't see a way to get PGP to cover the same ground.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 1 Jul 2000, Roeland M.J. Meyer wrote:
The thing is that folks ARE using it. Just, not in public.
Well, that's understandable. If I were an S/MIME user, I wouldn't want the public to know! ;) "Hi, my name's Len, and I'm an S/MIME abuser." "Hi, Len!"
That may or may not be true. Letting things sink to common terms, we have been discussing S/MIME vs PGP, via PKI debate. What sort of PKI would be most useful for NANOG participants? My contention is for OpenSSL style CA that issues certs usable for both S/MIME and SSL. In addition, I have a project that would let SSH use *.pem files from OpenSSL, issued by OpenCA. What we would have then is a single Key/Cert that would work with SSH, S/MIME, and SSL. I can't see a way to get PGP to cover the same ground.
PGP works with newer versions of SSH. I see no need for S/MIME to exist. And I don't see SSL incompatability as a barier to using PGP with email. (For the record, there is an Internet draft on using PGP with TLS, and Apache can easily be modified to use PGP keys... the problem is browser support, and not a limitation in PGP.) __ L. Sassaman System Administrator | Technology Consultant | "Common sense is wrong." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Practical C Programming -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5XnCDPYrxsgmsCmoRAgXoAJ4jx7zWlER8B65g/RSqj5gYU1c7QQCg4B/x Fr6uYHFWYRMqpOhRsh42PkQ= =uhCk -----END PGP SIGNATURE-----
L. Sassaman: Saturday, July 01, 2000 3:28 PM
On Sat, 1 Jul 2000, Roeland M.J. Meyer wrote:
The thing is that folks ARE using it. Just, not in public.
Well, that's understandable. If I were an S/MIME user, I wouldn't want the public to know!
;)
I understand the ;) but my point was that much S/MIME traffic goes over intra-nets and VPNs, with maybe a short hop over the Internet.
That may or may not be true. Letting things sink to common terms, we have been discussing S/MIME vs PGP, via PKI debate. What sort of PKI would be most useful for NANOG participants? My contention is for OpenSSL style CA that issues certs usable for both S/MIME and SSL. In addition, I have a project that would let SSH use *.pem files from OpenSSL, issued by OpenCA. What we would have then is a single Key/Cert that would work with SSH, S/MIME, and SSL. I can't see a way to get PGP to cover the same ground.
PGP works with newer versions of SSH. I see no need for S/MIME to exist. And I don't see SSL incompatability as a barier to using PGP with email.
How about viewing web-based mail and list archives? The S/MIME cert is also a client-side cert and can be used in lieu of user/passwd.
(For the record, there is an Internet draft on using PGP with TLS, and Apache can easily be modified to use PGP keys... the problem is browser support, and not a limitation in PGP.)
If the browsers do not support it then it is a PGP problem because the users cannot use it. Where can I get the links to the Apache/PGP effort? I don't find them at apache.org. Also, what is the W3C position?
On Sat, Jul 01, 2000 at 08:37:00AM -0700, Roeland M.J. Meyer wrote:
makes key management unbelieveably complex. Since I can't get PGP to work with SSL and I CAN get X.509 to encrypt message content, guess which drops out the door.
In case you haven't figured it out yet, it's an integration issue, not strictly a technnical one.
Yet another reason why nobody's bothered to make a robust PGP keyserving network. We are geeks; we aren't indicative of what the general public uses or will use.
participants (4)
-
Bennett Todd -
L. Sassaman -
Roeland M.J. Meyer -
Shawn McMahon