Re: AD Review Comments: draft-hollenbeck-rfc4934bis-00

Scott,

I agree since the SSL details are typically handled by the toolkit,
language, or SSL provider with no explicit control by the EPP developer.

-- 


JG 

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email protected]
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" <[email protected]>
Date: Tue, 14 Apr 2009 07:14:58 -0400
To: James Gould <[email protected]>, EPP Provreg <[email protected]>
Subject: RE: [ietf-provreg] AD Review Comments:
draft-hollenbeck-rfc4934bis-00

According to this reference:
 
http://download.java.net/jdk7/docs/technotes/guides/security/jsse/JSSERefGui
de.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
> [email protected]
> 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" <[email protected]>
> Date:  Mon, 13 Apr 2009 08:37:25 -0400
> To: EPP Provreg <[email protected]>
> 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-
> 
>