Re: Does JSSE support mutual authentication with PFX files?
Eric, I already answered E. Alaknantha with a code snippet answering his question, sorry I forgot to CC the entire list so everyone would know... It realy would be nice if folks just followed up privately to off topic posts. -rick (cc'ing the list so eveyone knows the way) On 20 Dec 2001, Eric Rescorla wrote: This really isn't the right forum for this question. Surely there is a JSSE mailing list. That said... E Alaknantha [EMAIL PROTECTED] writes: I am working with JSSE for SSL communications. I am facing some problems in doing the mutual authentication with the server certificates exported to the PFX format. I am doing a mutual authentication by intiialising the keystores with the PFX file and the truststores with the DER file all in the PKCS12 type. But only one side authentication is happening. The client does not send its public certificate to the server and hence getting a null certificate received exception. It would be greatly helpful if I could get some suggestions on this fronts. First of all I want to confirm if the PKCS12 form supports mutual authentication. Let's take a step back. PKCS12/PFX is just a carrier for keying material. It doesn't support or not support mutual authentication. If both sides have suitable keying material than mutual authentication is posssible. Otherwise it is not. The way that authentication works with SSL/TLS is that you have required server auth but optional client auth. [0] The server automatically sends its certificate. If the server wants to authenticate the client it sends a CertificateRequest message containing a list of suitable CAs. If the client has a suitable certificate it sends that, otherwise it sends an empty certificate message or an alert indicating that it won't client authenticate. Most SSL implementations do not ask for client authentication by default. Have you set the configuration flag that tells JSSE to do so? -Ekr [0] There are actually anonymous modes where neither server or client authenticates but these are very rarely used. -- [Eric Rescorla [EMAIL PROTECTED]] Author of SSL and TLS: Designing and Building Secure Systems http://www.rtfm.com/
Re: more on IPv6 address space exhaustion
Noel, this stems from the lack of engineers intrest in politics, until its too late. -rick On Sat, 12 Aug 2000, J. Noel Chiappa wrote: PS: One wonders about the wattage level of the people on the commision, but I digress.
Re: Addresses and ports and taxes -- oh my!
Vint, the ASO members don't support ICANN on a per block basis, in fact ICANN's Task Force on Funding (TFF) observed that the IP Address Registries operate on a non-profit business model from member fees and should foot 10% of ICANN's budget. (see http://www.icann.org/tff/final-report-draft-30oct99.htm) If ICANN's budget grows the ASO's responsibility grows proportionally. If the IP Address Registries (ASO Members) are doing cost-recovery then its expected the price for membership will increase or the cost for a delegation will increase. It is reasonable to assume that an address maintance fee will eventually passed along to the consumer just to maintain the 10% ICANN maintance. I don't want to see IP Address space charges, no matter its version, induce a monthly charges on the end-user side. Just this year the ASO's 10% responsibility will amount to $428,000 USD. If you don't think that ICANN's budget will grow under stand tha ARIN's 2000-01 budget is 5.2M and ICANN's budget for 2000-01 is 5.0M If you want to keep ICANN out of your pocket, ensure they stay lean and focused on technical administration of Assigned Names and Numbers and not inflating its own self worth. I would prefer having ICANN set the ASO funding requirements in such a way that it did not encourage ASO members to pass on the ICANN maintance fees in a per assignment basis. In short Manageing ICANN's budget can have the largest impact on the costs of future IP Address Registry operations. I'd be happy to carry this conversation on in another forum, just let me know where that is. thanks, -rick On Thu, 3 Aug 2000, vinton g. cerf wrote: It is a very good question whether one's internet-enabled household appliances will induce a monthly charges - do you suppose there would be a way to have a one-time charge to "pay" for some number of such addresses - perhaps built into the cost of the appliance (and paid by the manufacturer who "burns" an address into the device - at least the low order 64 bits or something to make it end-to-end unique)?
RE: Is WAP mobile Internet??
Vernon, would pacbell filtering all multicast at all CPE equipemt fall into your bucket, where do you draw the line? -rick On Wed, 5 Jul 2000, Vernon Schryver wrote: From: Lloyd Wood [EMAIL PROTECTED] ... my point is not to push sms or whatever. but that by "on the internet" i think we mean having unincumbered availability of the common application protocols, email, http, ftp, ssh, ... that's not quite enough; in the UK we're seeing cable-modem ISPs attempt to restrict services to those applications, or to a subset of those applications (lotsa luck setting up an http server or using ssh.) ... and also like AOL's redirecting proxies for out-bound SMTP? and the port-25 filtering of many ISP's including UUNET? Vernon Schryver[EMAIL PROTECTED]
RE: Cite on DNS-related traffic.
Daryl, I happen to own a iso-3166-2.com domain (ar.com) and a large part of the queries to my name servers are for SLDs under .AR. which is the ccTLD for Argentina. The number of queries for *.com.ar.com., which all fail is significant compared to queries for anything valid under ar.com. I suspect similar behavior for any 2 letter SLD in a gTLD that has a matching iso-3166-2 ccTLD. best regards, -rick On Tue, 30 May 2000, Daryl Bunce wrote: I've often wondered how much of the overload is due to browsers looking for XYZ.com, then looking for www.XYZ.com... Just one of those things thought about in the wee hours.
Re: Back to the drawing board, was Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
randy, the RFC is what will be used, RRP version 1.1.0 is in the OTE (test environemnt) slated to be put into general availability on Jan 15th. The current version in production is RRP 1.0.6 -rick On Wed, 5 Jan 2000, Randy Bush wrote: 2. The proposed RFC is not what should be used: this is not relevant to the publication of *this* rfc, the intent of which is to document what IS used not what SHOULD BE used. randy
Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
IESG: I hate to add a "me too" but I must. I believe that the RAB minutes would be very useful if they were published. Having participated with many Registrars and participated in changes and suggestions to the RRP protocol through the ICANN Testbed process I welcome Ed's comments. I am glad that NSI has published the I-D for their protocol, now does it need to go beyond that and become an RFC, IMHO, no. The IETF does not need to publish broken implementations of one companies view of the shared gTLD registration process. Having an AD that sat on the RAB promote the I-D and offer no reasoning as to why it *should be* published as an Informational RFC reminds me of the bad taste left by the IAHC and all the processes related. I would request that the IESG let this draft expire and create a WG to tackle the problem. I would be interested in hearing just why the IESG thinks this document should be published. The document exists as an I-D, the cat is out of the bag, why should it be an RFC? Its broken and of bad design we don't need that kind of thing published any further than it has been. regards, -rick On Tue, 4 Jan 2000, Ed Gerck wrote: Patrik Fältström wrote: So, you are talking about (like we did in the RAB) the quality of the protocol, while I now as AD and member of the IESG is asking whether this document is correctly describing what is in use. I ask you Ed, and all others, to please differentiate between those two issues, and come with comments on the correctness of the document. Comments on the protocol can be sent directly to NSI. IMO you are following a very slippery slope here. You seem now to be moving into "explanation mode" in order to say that the protocol's effectiveness is not important, just its perfunctory functions. In other words, you as AD and member of the IESG are saying that protocols are to be published as RFCs even if knowingly technically wrong, inefficient, outdated and insecure -- provided they are "in use". Well, I may be a little less pragmatic than you and I question exactly the correctness of the document, as well as its effectiveness. And, since our names are still in NSI's page for the Registry Advisory Board (RAB) and we were involved with it, I also think that the IETF should know that the SRP being proposed by NSI as an RFC and being followed through IETF under yours (a former member of the RAB) apparent approval is not what the RAB discussed and formally requested to change as documented in the RAB minutes locked under NDA. The RAB in Ammendment 11 has thus become a mock review process locked under NDA, even though the RAB was officially called by the USG to "review, participate, and advise in testing of the technology aspects of the Shared Registration System, and to suggest improvements to Network Solutions to better meet the mandates of Amendment 11." The least I suggest is to make the RAB Metting Minutes, together with its Action Plan, public -- before furthering this RFC in the IETF. Why should other people need to reinvent the same comments again? The hope that some will not be reinvented is IMO ill-founded as security experience shows all the time -- obscurity is not a basis for security. Now, of course, if NSI wants to keep the protocol private then I have no further comments. Cheers, Ed Gerck
Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
Paul, In short you are suggesting that the I-D be published to document a bad but current practice? It seems counter-intutative but I am certainly not "in the know" as to how these things work. think the IESG could at least put a "bad bad protocol" sitcker on it when they its published, or better yet give it a negative RFC number starting with negative RFC numbers would at least put it firmly into the minds of readers that the RFc should *not* be followed. I doubt I'd implement RFC -1 ;-) regards, -rick On Tue, 4 Jan 2000, Paul Hoffman / IMC wrote: At 03:05 PM 1/4/00 -0800, Rick H Wesson wrote: The IETF does not need to publish broken implementations of one companies view of the shared gTLD registration process. True. They don't need to do anything. They have the *option* of continuing the tradition of approving publication of Informational RFCs that document interesting (for some value of interesting) protocols that were not developed in the IETF but are of interest to the Internet community. In my mind NSI's RRP certainly qualifies. As long as the protocol does not directly harm the Internet on a technical level (not a political level; they all do that), the IESG might want to see it published.
Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
David, I appologise if you found my comments offensive, they were not intend to be. I'm gald you encouraged NSI to publish RRP, I'm gald they published it. I also needed to discuss with the RAB issues about RRP durring the testbed but was prevented by NSI by NDA. Remember in Berlin I asked if I could talk to the RAB and that the testbed registrars have some problems with RRP? We all know that the entire development of rrp was sub-optimal and yes Informational does not implay Endorsement but that is a fact that most of the world does not understand and is an entirely different thread. I have atempted as have others to outline many issues we have had with the RRP protocol and its developemnt. I realy can't do more than that. -rick On Tue, 4 Jan 2000, David R. Conrad wrote: I find this offensive. I was among those who encouraged NSI to publish the RRP as an informational RFC as I felt it would be in the best interests of everybody to have the RRP protocol publically examined and I feel NSI should be commended for documenting their protocol. However, INFORMATIONAL RFCS DO NOT IMPLY ENDORSEMENT. The draft is a representation of an existing, in use proprietary protocol. No further justification should be necessary for documenting it as an informational RFC.
RRP Protocol
NSOL has made an I-D of their RRP Protocol it is available at http://www.ietf.cnri.reston.va.us/internet-drafts/draft-hollenbeck-rrp-00.txt -rick
RE: whois?
Martin, don't expect things to get better about UCE, your registration information is now available for sale. all registrars are required to sell their whois databases for a maximum of $10K, per the latest ICANN/DOC/NSI agreements. -rick On Tue, 14 Dec 1999, Martin Essenburg wrote: I think it is a good idea because companies are using the whois info as a mailing database for there products. I get a ton of snail mail from this MJE Martin Essenburg MCI WorldCom - Global Accounts East 727-431-5907 Vnet: 977-5907 Pager: 1-888-270-9268 (2way) mailto:[EMAIL PROTECTED] http://sts-east.mcit.com -Original Message- From: Robert G. Ferrell [mailto:[EMAIL PROTECTED]] Sent: Monday, December 13, 1999 1:14 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: whois? I'm just wondering -- my whois command doesn't turn up contact information for domains anymore. What's going on? I get a registrar's name instead NSI changed WHOIS servers on 1 December. Use whois -h whois.networksolutions.com Robert G. Ferrell Internet Technologist National Business Center, US DoI [EMAIL PROTECTED]
