- Test - lists.nanog.org

San Bruno cable fire half repaired/BART claim forms
by Sean Donelan 05 Jul '00

05 Jul '00

Pacific Bell announced passing the half-way point splicing cables damaged by a cable fire caused by BART construction near the San Francisco airport San Bruno. 12,000 lines still need to be repaired. Pacific Bell hopes to complete repairs by Friday. BART officials have begun accepting claim forms from those affected by the accident. Forms can be obtained by calling (650) 689-8357, or (650) 689-8358.

1 0

RE: PGP kerserver infrastructure
by L. Sassaman 04 Jul '00

04 Jul '00

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 3 Jul 2000, Dave Del Torto wrote: > >Unlike an X.500 directory, it is very difficult to segment PGP keys > >into directories. How would one do this? Using DNS? > > Right. DNSsec defines KEY and SIG records, so you could > theoretically have a key associated with every IP address. DNS is extremely ill-suited to serving as a key distribution method. This has been discussed multiple times, and the people who have actually worked on keyservers all generally agree that there must be better means for doing this. > >Which domain would one choose to use for cataloging the keys? (ex.: > >My key has multiple email addresses, including quickie.net and > >pgp.com. Which domain would it be under?) ... > > Both. Availability is a primary design criteria. How about keys like the PGP Employee Certification Key, which has no email address? What if quickie.net was an ISP that did not want to run a keyserver? Have you ever actually tried to use bind to serve keys? (I think not, or else you would not be suggesting it.) > >Multiple servers only exist for redundancy and performance benefits. > >... > > They also provide rapid access for local users. It's the same as when > I plug a new device onto my network and it's IP and FQDN get sucked > into the DNS, then someone can do a DNS "DIG" for the machine's > address based on some protocol need. > > Draw the analog in key management to DHCP, and build that. Again, trying to shoehorn PGP key serving into an existing technology might be a good thing, but only if that existing technology will be suitable. DNS is not. __ 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. iD8DBQE5YU0nPYrxsgmsCmoRAu/TAKCfUtg4Mv+4tq39VAINQRyEtoHCrACg8EHt MvxJ5QSrjxHZazWZn6IsGmE= =q9eF -----END PGP SIGNATURE-----

1 0

Re: PGP kerserver infrastructure
by L. Sassaman 03 Jul '00

03 Jul '00

-----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-----

4 14

RE: PGP kerserver infrastructure
by Randy Bush 03 Jul '00

03 Jul '00

> Eric and Randy's excellent contributions notwithstanding, I think the > problem is even simpler from a user's perspective: > 4) "Given my grandson's email address, send this email to him privately." > Even if the PGP key format soon expands to include attributes of many > types, it's clear that all human interaction is based on > correspondence of some kind nope. i, and many others, use pgp to encrypt files on disk should one's system be cracked, a laptop be lost, ... > SRVs are the way to go, if they enable the rapid adoption and > scaling of (1) and (2) and make (4) easier for Grandma. to use srv you have to know the domain. you have just recursed and made no progress. randy

1 0

Re: PEM(?)
by L. Sassaman 02 Jul '00

02 Jul '00

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 1 Jul 2000, J C Lawrence wrote: > I have watched and read this thread with interest. In the end the > validity or personal preferences on the various standards is moot. > Compared to what is needed and wanted by the NANOG membership it > really just doesn't matter no matter how much you might think that > PEM/SSL/PGP/whatever are evil/great/flawed/brilliant. You're > looking to roll out a service and a basic point seems to have been > lost: actually doing something. Wouldn't it be a bit more useful to > get the thread onto the questions of: > > -- What *functionally* would be most useful to the NANOG > membership in terms of a networked key server? Do they want > SSL keys, PGP keys, SSH keys, all of them, some of them, what? > Ask! Good point. And so the question is asked... > -- What resources would be required to implement that and are > there systems already available that can be leverages to do > this or is a new development effort required? This depends on the first answer, of course. > -- Who will devote resources (machines, bandwidth, admin, > development time etc)? I have had numerous companies contact me about machines, bandwidth, and admin time for the PGP keyserver network, so that is promising. - --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. iD8DBQE5X6IwPYrxsgmsCmoRApBJAKDjFPUeADMh7SJo8cFuGwHEEZiicwCfTMu8 +rtSHzqfMJM/CC7OMACs2kU= =81aT -----END PGP SIGNATURE-----

1 0

RE: PGP kerserver infrastructure
by Roeland M.J. Meyer 01 Jul '00

01 Jul '00

> From: Albert Levi: Saturday, July 01, 2000 10:04 AM > Please have a look at your wallet and see how many pieces of ID/cards > you have. I have at least 20. And they are needed for different > purposes. I cannot use my driver's license to make a payment > and cannot > use my credit card as a passport. Not only is this argument by analogy, the connections are tenuous. I hold my credit cards and Keys physically in my hand. That is much different that having a bunch of random numbers that are too long to remember. Even so, I never carry more than 3-4, of >20, credit cards, nor do I carry all my keys. In fact, I try to reduce the number of each as much as possible, even if this means consolidating combinations/numbers/keys. Granted, this didn't connect with me either, until my users started complaining. In key management, there quickly comes a point where the management itself becomes a security risk. > Similarly a user can get several > certificates for different applications. And this is necessary for > authorization purposes. Although I aggree that it is not so easy to > describe the fact of several cert necessity for SSL and PGP/PEM/S/MIME > to a non-technical person, I believe that anyone can get the > philosophy > behind the analogic difference between the car key (to get to home - > SSL) and the home key (to enter the home - PGP/PEM/...). > You'd certainly > want your kids enter home but not use your car. I'm an empty-nester, my kids don't have access. You may explain it to them, but they will only grudgingly agree. Then only because they don't know any better and you don't give them a choice. You will lose them to the first one that gives them that choice. Users don't want to know the difference between SSL POP Auth and message content encryption. To them, it is all the same. Technically, there is no reason that you can't use the same key for both. Neither to they understand the difference between Webmail and POP email, after all, the content is the same. "why do I have to have three different certs to read the same email message?" is exactly what they asked me. To be honest, I couldn't answer that satisfactorily, because there was no non-ideological answer. Technically, X.509 would indeed give it to them, PGP wont.

1 0

NSI to make (simple) change to domain-change procedures effective 8Jul00.
by rdobbins＠netmore.net 01 Jul '00

01 Jul '00

It's better than nothing, I guess. Too bad they can't seem to get PGP working. http://www.securityfocus.com/templates/article.html?id=54 ----------------------------------------------------------- Roland Dobbins <rdobbins(a)netmore.net> // 818.535.5024 voice

2 1

RE: PGP kerserver infrastructure
by Roeland M.J. Meyer 30 Jun '00

30 Jun '00

> From: Albert Levi: Thursday, June 29, 2000 7:35 PM > > "Roeland M.J. Meyer" wrote: > > > Most modern mailers support X.509 certs for encryption. PGP is > > considerd, by many, to be the older technology. Building PKI > > around X.509 is much easier and meets actual existing standards. > > Well, X.509 is as old as PGP (rf. PEM which was X.509 based). I agree > that X.509 based PKIs are easier to built, but easiness does not mean > usability. The trust structures embedded in X.509 certs are not > acceptable for a large number of PGP users. > > I think the large number of PGP users and the current grow rate > determine whether it is old or not. Maybe it is not the > "standard", but > that many PGP users could not be wrong ! It is not an issue of right/wrong. Rather, it is an issue of what is most usable to the most people. SSL certs are certainly more usable to many. PGP works with ancient CLI mailers and older GUI mailers. All modern GUI mailers support X.509 keys for message encryption and even let you use the same cert for SSL protected POP3. PGP, OTOH, only encrypts the message body, this is why it's popularity is reducing. In addition, even you agree that an X.509 PKI is easier to build. Maybe because of the reasons I give here.

6 12

PGP kerserver infrastructure
by Shawn McMahon 30 Jun '00

30 Jun '00

If you guys are serious about being the latest cast and crew to pursue this, here's a resource you might want to be aware of: http://www.imc.org/ietf-openpgp/ You also might want to look at this message from their mailing list archive: http://www.imc.org/ietf-openpgp/mail-archive/msg02132.html They have a pgp-directory mailing list, and all of this has been discussed before, so perhaps it can save you some research.

13 27

RE: Experience with Cybex
by James Smith 30 Jun '00

30 Jun '00

Oops, social faux pas! :) Here are my finds: Our criteria are the following: - A KVM switch system. - Must support PCs, SUNs, and any serial devices. (We have several Cisco's and APC's) - Must be expandable to large number of devices, for investment protection. (We have 17 devices to start off with, and who knows where we'll end up in the future.) - Must support multiple users. I started looking at Cybex, since we have a little 4 port Cybex already. The 4040 model looked like it would suit our needs. We need 6 PC connections with PS/2, 3 Sun connections with video, and 8 serial connections (2 Suns, 4 Ciscos and 2 APCs). Since there are 17 devices, we needed two of the 4040 models, with a communications card in between. Then, with some help from this list, I identified other competitors. I looked at Rose Electronics (www.rosel.com) Their stuff looked good, but I couldn't find anything on support for serial devices. I didn't look at them further after that. I also looked at Apex (www.apex.com) but again I didn't see anything for serial support. (Besides, their press releases said something about just finishing a merger with Cybex.) Raritan has a similar offering to Cybex, with their MX4. We priced out a similar configuration and the price of the Raritan was the same as the Cybex. (About $12,000 CDN). The deciding factor was that since we are expanding, and most of our new systems are Suns and Ciscos with serial ports, we chose the Cybex. -- James Smith, CCNA Chief Network/System Administrator DXSTORM.COM http://www.dxstorm.com/ DXSTORM Inc. 2395 Speakman Drive, Suite 2200 Mississauga, ON, L5K 1B3 CANADA Tel: 905-822-1957 (email preferred) Fax: 905-822-0680 1-877-DXSTORM (1-877-397-8676) "Feeling 'connected' with carbon-based dolts holds all the joy of being handcuffed to a dead zebra - it sounds special, but it can get old fast." - The Dilbert Principle - Engineers, Scientists, Programmers and Other Odd People On Fri, 30 Jun 2000, Jamie Rishaw wrote: > Usually in situations like this when you solicit replies privately from a > list, you post your findings/reply summary to the list. :) > > I'm interested in what you found out. > > -jamie > > > | -----Original Message----- > | From: James Smith [mailto:jsmith@dxstorm.com] > | Sent: Thursday, June 29, 2000 10:20 PM > | To: 'nanog(a)merit.edu' > | Subject: Re: Experience with Cybex > | > | > | > | Thank you everyone for all the responses about the Cybex > | products! :) It > | been a lot of help in justifying the purchase. > | > | > | -- > | James Smith, CCNA > | Chief Network/System Administrator > | DXSTORM.COM > | > | http://www.dxstorm.com/ > | > | DXSTORM Inc. > | 2395 Speakman Drive, Suite 2200 > | Mississauga, ON, L5K 1B3 CANADA > | Tel: 905-822-1957 (email preferred) > | Fax: 905-822-0680 > | 1-877-DXSTORM (1-877-397-8676) > | > | "Feeling 'connected' with carbon-based dolts holds all the > | joy of being > | handcuffed to a dead zebra - it sounds special, but it can get old > | fast." > | > | - The Dilbert Principle > | - Engineers, Scientists, Programmers and Other Odd People > | > | > | On Wed, 28 Jun 2000, James Smith wrote: > | > | > > | > I'm look at purchasing a Cybex KVM switch system (XP4040) and was > | > wondering if anyone had any good or bad experiences to > | share, or opinions > | > about other similar products. Is Cybex widely used in NOCs? > | > > | > > | > -- > | > James Smith, CCNA > | > Chief Network/System Administrator > | > DXSTORM.COM > | > > | > http://www.dxstorm.com/ > | > > | > DXSTORM Inc. > | > 2395 Speakman Drive, Suite 2200 > | > Mississauga, ON, L5K 1B3 CANADA > | > Tel: 905-822-1957 (email preferred) > | > Fax: 905-822-0680 > | > 1-877-DXSTORM (1-877-397-8676) > | > > | > "Feeling 'connected' with carbon-based dolts holds all the > | joy of being > | > handcuffed to a dead zebra - it sounds special, but it can get old > | > fast." > | > > | > - The Dilbert Principle > | > - Engineers, Scientists, Programmers and Other Odd People > | > > | > > | > > | > > | > | >

1 0