RE: [ietf-provreg] AD Review Comments: draft-hollenbeck-rfc4934bis-00

"Hollenbeck, Scott" <shollenbeck@verisign.com> Tue, 14 April 2009 11:34 UTC

Return-Path: <owner-ietf-provreg@cafax.se>
X-Original-To: ietfarch-provreg-archive@core3.amsl.com
Delivered-To: ietfarch-provreg-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A94EA3A6840 for <ietfarch-provreg-archive@core3.amsl.com>; Tue, 14 Apr 2009 04:34:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.485
X-Spam-Level:
X-Spam-Status: No, score=-1.485 tagged_above=-999 required=5 tests=[AWL=-0.726, BAYES_05=-1.11, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFkFjFhqIDcz for <ietfarch-provreg-archive@core3.amsl.com>; Tue, 14 Apr 2009 04:34:30 -0700 (PDT)
Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id B38123A6D3E for <provreg-archive@ietf.org>; Tue, 14 Apr 2009 04:34:29 -0700 (PDT)
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n3EBF1rX021913 for <ietf-provreg-outgoing@nic.cafax.se>; Tue, 14 Apr 2009 13:15:01 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n3EBF039027840 for ietf-provreg-outgoing; Tue, 14 Apr 2009 13:15:01 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f
Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n3EBExdn016573 for <ietf-provreg@cafax.se>; Tue, 14 Apr 2009 13:15:00 +0200 (MEST)
Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id n3EB6i9G030044 for <ietf-provreg@cafax.se>; Tue, 14 Apr 2009 07:06:44 -0400
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Apr 2009 07:14:59 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BCF2.3F1B6534"
Subject: RE: [ietf-provreg] AD Review Comments: draft-hollenbeck-rfc4934bis-00
Date: Tue, 14 Apr 2009 07:14:58 -0400
Message-ID: <046F43A8D79C794FA4733814869CDF07029FD729@dul1wnexmb01.vcorp.ad.vrsn.com>
In-Reply-To: <C6092A3A.31E91%jgould@verisign.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [ietf-provreg] AD Review Comments: draft-hollenbeck-rfc4934bis-00
Thread-Index: Acm8NJmzYO33/ZvpQjq+pbJCVGlx1QATEQdWABw02xA=
References: <046F43A8D79C794FA4733814869CDF07029FD625@dul1wnexmb01.vcorp.ad.vrsn.com> <C6092A3A.31E91%jgould@verisign.com>
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "Gould, James" <JGould@verisign.com>, EPP Provreg <ietf-provreg@cafax.se>
X-OriginalArrivalTime: 14 Apr 2009 11:14:59.0229 (UTC) FILETIME=[3F9F6CD0:01C9BCF2]
Sender: owner-ietf-provreg@cafax.se
Precedence: bulk

According to this reference:
 
http://download.java.net/jdk7/docs/technotes/guides/security/jsse/JSSERe
fGuide.html
 
it should, but I can't confirm that it does.  I'm reasonably certain
that this is behavior that's typically buried in a toolkit instead of
being implemented by an EPP developer, so perhaps that new text should
be removed from the document.

-Scott- 

 


________________________________

	From: Gould, James 
	Sent: Monday, April 13, 2009 5:43 PM
	To: Hollenbeck, Scott; EPP Provreg
	Subject: Re: [ietf-provreg] AD Review Comments:
draft-hollenbeck-rfc4934bis-00
	
	
	Scott,
	
	We're implementing SSL using JSSE in our Java EPP SDK, but I'm
not sure if JSSE sends a TLS_close_notify alert before the connection is
closed.   
	
	-- 
	
	
	JG 
	
	-------------------------------------------------------
	James F. Gould
	Principal Software Engineer
	VeriSign Naming Services
	jgould@verisign.com
	Direct: 703.948.3271
	Mobile: 703.628.7063
	
	 
	21345 Ridgetop Circle
	LS2-2-1
	Dulles, VA 20166
	
	Notice to Recipient:  This e-mail contains confidential,
proprietary and/or Registry  Sensitive information intended solely for
the recipient and, thus may not be  retransmitted, reproduced or
disclosed without the prior written consent of  VeriSign Naming and
Directory Services.  If you have received  this e-mail message in error,
please notify the sender immediately by  telephone or reply e-mail and
destroy the original message without making a  copy.  Thank you.
	
	
	
________________________________

	From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
	Date: Mon, 13 Apr 2009 08:37:25 -0400
	To: EPP Provreg <ietf-provreg@cafax.se>
	Subject: [ietf-provreg] AD Review Comments:
draft-hollenbeck-rfc4934bis-00
	
	Some feedback from Alexey on the new TLS Usage Profile text in
4934bis.
	I now need implementer feedback.
	
	>>  A client MUST close the associated TLS connection if the
connection
	>>  is not expected to deliver any EPP messages later.  It MUST
send a
	>>  TLS close_notify alert before closing the connection.
	>>
	> As an implementor I remain skeptical that existing
implementations do
	> that. At least I doubt many IMAP or SMTP servers do that. So
maybe you
	
	> should check how existing EPP implementations handle
connection
	closure.
	
	What are you implementers doing?
	
	> I think the text about how to extract and verify domain
information
	from
	> X.509 certificates is still missing from your draft. I think
that what
	
	> Chris wanted you to do and I am in agreement with him on this.
	> I see some text on this in Section 8, but I think it is a bit
too
	short.
	> Check section 2.2.1 of draft-ietf-sieve-managesieve-09.txt. It
	probably
	> contains 80% of what EPP should use.
	
	Comments, please.  I've sent a note to Alexey pushing back on
this
	because (in my opinion) this puts mandates on client and server
	certificate validation behavior that don't affect EPP
interoperability.
	If I'm wrong, I'd prefer to cite an existing mature reference
instead of
	cloning text from an unapproved I-D.  Does anybody know of one?
	
	-Scott-