RE: [isdf] RE: Palladium (TCP/MS)
Title: RE: [isdf] RE: Palladium (TCP/MS) I agree with you, I found many more applications that do not support s/mime cf SSL-Certificates HOWTO on www.tldp.org. However, you can sign messages in s/mime clear text, which works the same as PGP by encapsulating the message in clear inside a signature... but some systems will still not be able to handle properly this mime signature... Note that you can set your exchange server to convert s/mime messages automatically... On my exchange 5.5 in the Internet connector there is an option that says clients support s/mime. If it is enabled, the s/mime message is send as it to the client, if it is not enabled then the signature is removed (but the user does not know he has received a signed message). s/mime still need more work, on the implementation level... We are in chicken-egg situation, that will be solved with a global PKI (my opinion)... Cheers. Original Message-From: Cirillo CWO2 Michael R [mailto:[EMAIL PROTECTED]]Sent: Friday, 25 October 2002 12:27 To: 'Franck Martin '; ''Gary Lawrence Murphy' 'Cc: ''TOMSON ERIC' '; ''[EMAIL PROTECTED]' '; ''[EMAIL PROTECTED]' 'Subject: RE: [isdf] RE: Palladium (TCP/MS) MS promises S/MIME support in their next release, which would be Dec or Mar or Jun or... Currently, Outlook Web Access doesn't "know" S/MIME, so certificate use is not possible. It is possible to read a signed email and to retrieve the attachment, but it requires Notepad or reconfig of the app to which the PKCS #7 is associated. Not hard. Encrypted emails are unreadable period.
Re: http://www.ietf.org//mail-archive/ietf/Current/msg17924.html
Microsoft's application protocols (e.g. CIFS aka NetBIOS, Kerberos) are certainly problematic, but I've heard no complaints about their IP stack in several years. Let me rephrase... The text above is what lead me to ask questions about Active Directory but maybe I wasn't clear enough. I wanted to know how well Microsoft products such as Active Directory comply with industry standards (RFCs, etc.) I was especially interested in finding out if Microsoft Active Directory could co-exist with other third party products that can be more standards-compliant then Microsoft's versions of DNS, DHCP, Kerberos, etc. For example, you can run BIND with Active Directory instead of Microsoft DNS. Can you run MIT Kerberos with Active Directory without using Microsoft's Kerberos or did they make Active Directory rely on their non-standard version of Microsoft Kerberos? How well does Active Directory comply with current LDAP standards and how well would it integrate with third party LDAP products? Where and how did Microsoft deviate with standards? If Microsoft takes RFCs seriously then where is the documentation to support it? This is basically what I'm looking for... information/documentation that substantiates Microsoft's compliance with standards when it comes to protoc! ols like DNS, DHCP, Kerberos, IP, etc. So you can see, it's somewhat related to the thread(s) going around about Microsoft protocols. Brian B.
Proposed Agenda for ENUM WG IETF 55 Atlanta GA.
OK ..this is what I have so far but it is subject to daily revisions... keep those notes to the list coming ... sarcasm ### MONDAY, November 18, 2002 1130-1300 Break 1300-1500 Afternoon Sessions I TSV enumTelephone Number Mapping WG Chair(s): Patrik Faltstrom [EMAIL PROTECTED] Richard Shockey [EMAIL PROTECTED] Transport Area Advisor: Scott Bradner [EMAIL PROTECTED] Mailing Lists: General Discussion:[EMAIL PROTECTED] To Subscribe: [EMAIL PROTECTED] In Body: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/ AGENDA BASHING (5 min) Scribe Introduction I am looking for a scribe ? VOLUNTEERS WANTED ASAP !!! It is my sad duty to report that our long standing scribe Jay Hilton is no longer with Telcordia and will not be attending IETF Atlanta. 1. RFC2916bis -0x REV - Faltstrom/Mealing (45 Min) ### 2. J.Peterson (20min) Enumservice registration for SIP Addresses-of Record - Using ENUM for SIP applicationsNot yet posted to ID editors. ### 3.R.Bradner Co [20 Min ???] We definitely need to come to some consensus on how to work this issue. Title : 'A compendium of enumservice registrations' Author(s) : R. Brandner et al. Filename: draft-brandner-enumservices-compendium-00.txt Pages : 0 Date: 2002-9-16 This document includes a basic set of enumservice descriptions that are intended for use in deployments of ENUM. These descriptions form a set of enumservice registration requests, as laid out in section 3 of draft-ietf-enum-rfc2916bis-01.txt. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brandner-enumservices-compendium-00.txt 3. The 'enum' URI(L. Conroy 15 min) We discussed this some in Yokohama but did not come to a definitive conclusion whether this URI was appropriate or some extension to the TEL URL was sufficient. http://www.ietf.org/internet-drafts/draft-brandner-enum-uri-00.txt 4. Open Discussion ... A. The Reverse ENUM issue I'd like to hear some more views on this. Does this need to be standardized? It seems to come up on the list with some regularity. Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 mailto:richard;shockey.us or mailto:richard.shockey;neustar.biz http://www.neustar.biz ; http://www.enum.org
RE: [isdf] RE: Palladium (TCP/MS)
Title: Message As this thread is becoming more and more technical, may I suggest to limit it from now on to the IETF list and then to stop cc:ing the ISDF list... -Original Message-From: Franck Martin [mailto:[EMAIL PROTECTED]] I agree with you, I found many more applications that do not support s/mime cf SSL-Certificates HOWTO on www.tldp.org. However, you can sign messages in s/mime clear text, which works the same as PGP by encapsulating the message in clear inside a signature... but some systems will still not be able to handle properly this mime signature... Note that you can set your exchange server to convert s/mime messages automatically... On my exchange 5.5 in the Internet connector there is an option that says clients support s/mime. If it is enabled, the s/mime message is send as it to the client, if it is not enabled then the signature is removed (but the user does not know he has received a signed message). s/mime still need more work, on the implementation level... We are in chicken-egg situation, that will be solved with a global PKI (my opinion)... Cheers. Original Message-From: Cirillo CWO2 Michael R [mailto:[EMAIL PROTECTED]] MS promises S/MIME support in their next release, which would be Dec or Mar or Jun or... Currently, Outlook Web Access doesn't "know" S/MIME, so certificate use is not possible. It is possible to read a signed email and to retrieve the attachment, but it requires Notepad or reconfig of the app to which the PKCS #7 is associated. Not hard. Encrypted emails are unreadable period.
Re: [isdf] RE: Palladium (TCP/MS)
F == Franck Martin [EMAIL PROTECTED] writes: F ...Anyone who sends me e-mail can be identified. Anything I F send can be traced to me. People wouldn't be forced to F participate, but if they remain anonymous, I might choose to F block them. I certainly wouldn't accept file attachments from F them. I know you hate this idea, but I think the Internet needs F a fingerprint. Isn't that PGP? -- Gary Lawrence Murphy - [EMAIL PROTECTED] - TeleDynamics Communications - blog: http://www.teledyn.com/mt/ - biz: http://teledyn.com/ - Computers are useless. They can only give you answers. (Picasso)
Re: [isdf] RE: Palladium (TCP/MS)
On Fri, 25 Oct 2002 13:17:29 +1200, Franck Martin said: Note that you can set your exchange server to convert s/mime messages automatically... On my exchange 5.5 in the Internet connector there is an This is, of course, assuming you are willing or able to use an exchange server. Not all the world uses the same proprietary package (which happens to be what originally STARTED this thread). We are in chicken-egg situation, that will be solved with a global PKI (my opinion)... You might want to stop, take a deep breath, and ask yourself exactly what problems a global PKI will solve (you might want to go read the chapter on PKI in Schneier's Secrets and Lies if you haven't already). Now let's see: If it's within my organization, a cert signed by my local CA is fine. I trust the guys upstairs from me to sign my organization's user's certs more than I trust some top-level CA to sign a certificate-signing-cert for some group I've never heard of. If it's an organization that we've got ongoing business with, it's easy enough to exchange certs and cross-sign them (a la PGP). Now we get to the hard case - initiating contact with a group I've never been in contact with before. Now, if all you care about is establishing an encrypted tunnel, a self-signed cert works *just fine*. So there's only two cases to worry about here: 1) A PKI *does* allow you to (somewhat) verify that the server at the other end is who it claims to be, and that you haven't been redirected by nefarious means (DNS cache poisoning, domain hijacking, etc) and that the server you are talking to really *IS* the www.example.com that you wanted. Note that the most popular application that uses SSL is IE, and that (A) IE is well-known for a lot of ways to hijack things (and that if you've been redirected via Javascript XSS, and you THINK you're talking to foo1.com, but really talking to foo2.com, then a cert for foo2.com will show no problems unless you actually click on the check cert details button and see it's issued to foo2.com. (B) few users seem to actually care. 2) Even if you've successfully connected to www.joes-junkyard-parts.com, and the certificate checks out, and all that, it tells you *NOTHING* about their business other than the fact that they qualified for a cert from some CA. It doesn't tell you if they're just in it for the credit card fraud, or if they will actually ship the parts, or whether they are in the habit of leaving all the credit cards out for anonymous FTP I suspect that the *real* reason there's no PKI yet is because there's no really motivating reason to have anything other than a cert for the company webserver (in most cases). And I suspect that this is unlikely to change until the legal climate regarding digital signatures has changed a lot. Not only does there need to be some legislation about it, but *also* some case law testing what the legislation does and doesn't mean - the biggest challenge will be defining the liability of a company if a private key is hacked/stolen and used to sign things without permission. As Schneier points out, the fact that it's signed *ONLY* proves that the data and the private key were at the same place at the same time, and says nothing about whether it's an *authorized* signature -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg09183/pgp0.pgp Description: PGP signature
RE: [isdf] RE: Palladium (TCP/MS)
Don't forget that the web-of-trust of OpenPGP is really a citizen approach and you don't have to rely on a specific entity. ISOC should organize more keysigning party ;-) (ok some at IETF) adulau On Fri, 25 Oct 2002, Franck Martin wrote: This is called PGP and S/MIME. Both are valid IETF RFC. From an industry point of view, S/MIME seems to be the one that will survive in the long run, because it is implemented in nearly all mail clients and follows the certificates used in SSL/TLS which is widely adopted (IPSec to name only one). However, none of them is widely implemented for e-mail purposes because of problems to build a global PKI (in short). I still haven't found a company that will give/sell me a certificate that allows me to sign my organisational e-mails certificates. ISOC is working on it... Cheers. -Original Message- From: Gary Lawrence Murphy [mailto:garym;canada.com] Sent: Friday, 25 October 2002 11:19 To: Franck Martin Cc: 'TOMSON ERIC'; '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Subject: Re: [isdf] RE: Palladium (TCP/MS) Isn't that PGP? ___ Isdf mailing list [EMAIL PROTECTED] http://www.isoc.org/mailman/listinfo/isdf -- --Alexandre Dulaunoy -- http://www.foo.be/ -- http://pgp.ael.be:11371/pks/lookup?op=getsearch=0x44E6CBCD People who fight may lose.People who do not fight have already lost. Bertolt Brecht
